Visual Studio - managing locally registered dll publication from homologation and production environment
I'm working with a banco Itaú Dll (itauCripto.dll ), the documentation requires it to be registered locally on the machine running the application. So I put the Dll inside the {[3] folder]}
% systemroot% \ SysWoW64\
And I registered her by CMD as administrator using
% systemroot% \ SysWoW64 \ regsvr32 itaucripto.dll
I added her reference within my project in Visual Studio 2017 as with Reference and used it normally within the project.
The fact is that on my machine is running correctly without any problem, but when I apply this change on the production server the application does not find the Dll.
The registration part I did exactly the same thing I described above on the production server but when I publish the project and game on the production server it does not find the reference.
I noticed that although when I select the Dll in the add reference panel it is pointing to the folder %systemroot%\SysWoW64 in my project the reference is pointing to the bin folder of the Project (WebApplication\obj\Debug\Interop.Itaucripto.dll ).
I don't know if when visual studio publishes the project it is getting lost in this way.
Can anyone say what is wrong or how can I make this path relative?
2 answers
In some cases, when you add a reference to a COM dll compiled to native code (in the case Itaucripto.dll), Visual Studio generates an intermediate Dll to speed up communication between your program (which is bytecode .NET, i.e. is not native) and the native Dll (in this case Interop .Itaucripto.dll).
Possible reasons for your program not finding the native dll:
- the program is being run by a different user than the user who registered the Dll. The DLL must be registered by an admin user, running regsvr32 as administrator, so that it is visible to all users or the program must be run by the same user who registered the Dll. (Note: programs running on IIS are typically run by the IIS user unless they are configured to use another user.)
- the program is running as a 64-bit process, but the native DLL is 32-bit. In this case it is necessary to configure the program to run as 32 bits. This can be done in the settings of the main project (the .exe or the website) or in the IIS settings (if it is a website).
Actually the problem was related to the DLL platform and the Application Pool.
I registered the DLL in the folder system32 instead of SysWoW64
Changed the Pool to allow 32-bit applications
But I also changed the reference property in the project to Embed Interop Types = False.
This caused the Copy local property to change to True and thus the Dll be published together with the project.
Worked perfectly.