Visual Studio - Managing Locally Registered Dll Publication of Homologation and Production Environment

Asked

Viewed 248 times

1

I am working with a Dll from Itaú bank(itauCripto.dll), the documentation requires it to be registered locally on the machine running the application. So I put the Dll inside the folder

%systemroot% Syswow64\

and registered it by CMD as administrator using

%systemroot% Syswow64 regsvr32 itaucripto.dll

I added her reference within my project in Visual Studio 2017 as COM 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 to the production server the application does not find the Dll.

The part of the record 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 the visual studio publishes the project it is getting lost in this way.

Can anyone say what is wrong or how I can make that path relative?

c# assembly dll visual-studio-2017 publish
  • 1

    Your IIS application pool is running at 64bits tbm?

  • This in 64bits, was disabled to run in 32bits, I changed now to true the configuration and I will test, because I’m almost sure that the dll is 32 bits. As I am using iis express on my machine I believe it is not a problem, but as on the server the settings are different can be a way.

  • 1

    If it is 32bit, there is a difference in the record... It would have to be done by the directory %systemroot%\System32.

  • @Bruno I think the problem was actually related to the platform. I changed the pool to allow 32bits, but also changed the property of the project reference to Embed Interop Types = False. This caused the Dll to be published along with the project. It worked perfectly, I will publish the full answer to help anyone who needs it.

2 answers

2

Actually the problem was related to Dll platform and the Application Pool.

I registered the Dll in the folder system32 instead of Syswow64

I changed the Pool to allow 32-bit applications

inserir a descrição da imagem aqui

But I also changed the property of the project reference to Embed Interop Types = False.

inserir a descrição da imagem aqui

This caused the Copy Local property to change to True and thus the Dll to be published along with the project.

Worked perfectly.

  • A dll, being copied together with the project the system would be using the dll of the System’s own folder, is not that?

  • 1

    I thought this tbm, but when I undo the dll record in the System32 folder the application throws an error as the dll is not registered. I tried otherwise tbm, without putting the dll in the package and tbm gives error as the dll is not found in that case, hehehe

1


In some cases, when you add a reference to a native code-compiled COM Dll (in the case of Itaucripto.dll), Visual Studio generates an intermediate Dll to speed up communication between your program (which is bytecode . Net, ie, is not native) and the native Dll (in this case Interop.Itaucripto.dll).

Possible reasons your program can’t find the native dll:

  • The program is running by a user other 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 that run on IIS are typically executed 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 main project settings (the . exe or the website) or in the IIS settings (if it is a website).

  • Legal didn’t know exactly what happened when VS compiled this Dll.

  • Legal didn’t know exactly what would happen when VS compiled this Dll. Regarding the platform the project is configured to run on both platforms, but as the hosting server is 64b I registered the Dll in the Syswow64 folder. Regarding the users I have admin permission on the server, I do not know if I need to provide specific permission for the IIS in that Dll, I will look into this.

  • @Ricardocardoso. Despite the names, the Syswow64 folder is where Windows stores the 32-bit versions of the 64-bit dlls that are in the System32 folder. This allows it to run 32-bit programs, even though the system is 64-bit.

  • If the . dll is native and has been compiled in 32 bits, no matter which folder you registered in, the . dll remains 32 bits.

  • @Ricardocardoso if you thought the answer was good, please give a positive vote (flirty up in the top left corner of the answer).

  • 1

    I think the problem was actually related to the platform. I changed the pool to allow 32bits, but also changed the property of the project reference to Embed Interop Types = False. This caused the Dll to be published along with the project. It worked perfectly, I will publish the full answer to help anyone who needs it.

Show 1 more comment

Browser other questions tagged c# assembly dll visual-studio-2017 publish

You are not signed in. Login or sign up in order to post.