I have compiled a c natives 32bit DLL with Dev-C++, create the reference on my asp.net project, write a dllImport directives and use my new DLL. When launch my DEBUG session all work very well but when deploy my project on Web Server the runtime not load my DLL.
Asked
Active
Viewed 1,239 times
0
-
I have already set to true the Enable 32-bit Applications setting for my Application pool under IIS 7.0 on my server. Someone know the reason for this problem?? I have try everything :-( Help me!! – Daniele Notte Nov 21 '14 at 18:49
-
Is the dll deployed to the GAC properly? – Piyush Parashar Nov 21 '14 at 18:50
-
did you do a copy local = true for that reference? – Rex Nov 21 '14 at 19:02
-
How can i deploy dll on the GAC properly? Yes i have l'area du set copy local to true – Daniele Notte Nov 22 '14 at 09:07
2 Answers
0
My IIS 7.0 w3wp.exe runs as a 64 bit process (to check if your process running as a 32 bit process under WOW64, open the task manager's Process tab and see if the process name contains "*32").
I believe that a 64 bit process can only load 64 bit native DLLs (and managed DLLs built for "Any CPU" or "X64"). Perhaps your debug session is a 32 bit session? If this is the cause, take a look at Using a 32bit or 64bit dll in C# DllImport .
-
nothing...i have recompiled dll for 64bit natives dll but the situation is the same, vero strange....someone have another suggestion! Thanks – Daniele Notte Nov 25 '14 at 00:55
-
I think you need to determine the actual error that dllimport reports, otherwise we're just guessing the cause. The cause might be that the dll is the wrong bit-ness or it cannot be found where the IIS expects it or something else. – sevzas Nov 25 '14 at 13:02
-
@DanieleNotte, Please see my answer... it could help you with your 32-bit Dll ;) – AlexLaforge Mar 27 '18 at 20:41
0
For those of you who still cannot find a proper way to use a 32-bit DLL under a 64-bit IIS Application Pool, either by tweaking the registry, or by trying how to deal with the "COM+ Components Services", I have found a perfectly working solution : "Encapsulating" the 32-bit component into a new COM object as described on this page did the job perfectly, and I think that a lot of you will be interested to solve the problem this way ;) http://www.chestysoft.com/component-services.asp
In my case, that allowed me to use the "XStandard.Zip" free Component from XStandard, which is sadly only available as a 32-bit ASP component, and that have an "InProcServer32" Key in the registry apparently preventing it to work by tweaking the registry, as described here : https://techtalk.gfi.com/32bit-object-64bit-environment/
In this post, a lot of comments reported that "InProcServer32-IDs are not reflected because Microsoft assumes that these are only InProc-Calls and not Out-Of-Proc-Calls". And that was my case too, leading me to the situation where the registry tweaking solution described in the previous post was not working in my case, as other users.
Hoping having saved some days... or nights !
AlexLaforge
- 499
- 3
- 19