2

I have a .Net 4.5 project which has been built to a 64-bit DLL that needs to be included in my Web API project. The Web API project is also built to 64-bit. No matter what I try, I keep getting the exception "Could not load file or assembly '*.DLL' or one of its dependencies. The specified module could not be found.". This DLL is created from a mixed-mode project which contains an unmanaged C++ project and a C++/CLI wrapper compiled with /clr.

I have used DependencyWalker to check and make sure all the dependencies DLL are in the same folder as the Web API project as well as the bin folder. I also checked bitness to make sure they are all 64-bit. I then created a C# console project which loads this DLL along with its dependencies and everything worked just fine.

My Web API project uses local IIS 6.2 server and the application pool is using the default identity (ApplicationPoolIdentity). Even if I changed the identity to NetworkService it still failed. At this point I'm out of ideas on how to debug further. I have used Process Monitor before to nail down the missing DLL but not sure how to use it with Web API. Any suggestions on how to proceed with this issue would be appreciated.

Edit - here's the Fusion log:

The operation was successful. Bind result: hr = 0x0. The operation completed successfully.

Assembly manager loaded from: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll Running under executable c:\windows\system32\inetsrv\w3wp.exe --- A detailed error log follows.

=== Pre-bind state information === LOG: DisplayName = TestBridge (Partial) WRN: Partial binding information was supplied for an assembly: WRN: Assembly Name: TestBridge | Domain ID: 12 WRN: A partial bind occurs when only part of the assembly display name is provided. WRN: This might result in the binder loading an incorrect assembly. WRN: It is recommended to provide a fully specified textual identity for the assembly, WRN: that consists of the simple name, version, culture, and public key token. WRN: See whitepaper http://go.microsoft.com/fwlink/?LinkId=109270 for more information and common solutions to this issue. LOG: Appbase = file:///D:/build/MSVC/ImageSearchService/ LOG: Initial PrivatePath = D:\build\MSVC\ImageSearchService\bin LOG: Dynamic Base = C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\imagesearchservice\d0503829 LOG: Cache Base = C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\imagesearchservice\d0503829 LOG: AppName = 7ee35914 Calling assembly : (Unknown). === LOG: This bind starts in default load context. LOG: Using application configuration file: D:\build\MSVC\ImageSearchService\web.config LOG: Using host configuration file: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\aspnet.config LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework64\v4.0.30319\config\machine.config. LOG: Policy not being applied to reference at this time (private, custom, partial, or location-based assembly bind). LOG: Attempting download of new URL file:///C:/Windows/Microsoft.NET/Framework64/v4.0.30319/Temporary ASP.NET Files/imagesearchservice/d0503829/7ee35914/TestBridge.DLL. LOG: Attempting download of new URL file:///C:/Windows/Microsoft.NET/Framework64/v4.0.30319/Temporary ASP.NET Files/imagesearchservice/d0503829/7ee35914/TestBridge/TestBridge.DLL. LOG: Attempting download of new URL file:///D:/build/MSVC/ImageSearchService/bin/TestBridge.DLL. LOG: Assembly download was successful. Attempting setup of file: D:\build\MSVC\ImageSearchService\bin\TestBridge.dll LOG: Entering download cache setup phase. LOG: Assembly Name is: TestBridge, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null LOG: A partially-specified assembly bind succeeded from the application directory. Need to re-apply policy. LOG: Using application configuration file: D:\build\MSVC\ImageSearchService\web.config LOG: Using host configuration file: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\aspnet.config LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework64\v4.0.30319\config\machine.config. LOG: Policy not being applied to reference at this time (private, custom, partial, or location-based assembly bind). LOG: Binding succeeds. Returns assembly from C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\imagesearchservice\d0503829\7ee35914\assembly\dl3\584c8f8c\64f0e4b3_4a53cf01\TestBridge.dll. LOG: Assembly is loaded in default load context.

user1715925
  • 607
  • 9
  • 26

2 Answers2

5

You may need to enable 64 bit IIS Express support as part of VS 2013 / 2015 / 2017:

Tools -> Options -> Projects and Solutions -> Web Projects -> Use the 64 bit version of IIS Express

Credit to the response in this question

Community
  • 1
  • 1
Denis Pitcher
  • 3,080
  • 1
  • 27
  • 19
3

Try the following:

  1. Fusion Log for better error message: http://msdn.microsoft.com/en-us/library/e74a18c4(v=vs.110).aspx
  2. Ensure App Pool is 4.0
  3. Go to App Pool Settings in IIS and check if 'Enable 32 bit applications' is true
  4. If Fusion Log shows that everything is peachy, then it might be a problem with a dependent module which is unmanaged.. use SysInternal's ProcMon utility to see if that reports any issues.
  5. another issue is checking the VC++ 11 runtime on the machine.. some machines have it installed and some don't.
  6. Check the CPU (any cpu, x86 vs 64 again) just to be sure.
Raja Nadar
  • 9,409
  • 2
  • 32
  • 41
  • I checked all of your suggestions and they seem correct. Also, using Fusion log I don't see any failures, it shows the bind operation completed successfully. I edited my original answer with the full log. – user1715925 Apr 08 '14 at 19:28
  • 1
    Thanks, your new edit raised a point I forgot to make. My DLL is created from a mixed-mode project which contains an unmanaged C++ project and a C++/CLI wrapper. I will check ProcMon to see if that leads to anything. – user1715925 Apr 08 '14 at 19:40
  • had a similar issue with a friend working on managed wrappers for unmanaged code and the vc++ runtime was the issue. – Raja Nadar Apr 08 '14 at 19:52
  • 1
    Found my issue this time through ProcMon. Turns out one of my DLLs was not loaded for 2 reasons: The path to the DLL wasn't on the PATH variable, and IIS didn't have access to that path either. For now I'm forcing the apppool to run under my own local account to get it to work, but in the future I can copy them to a better location. – user1715925 Apr 08 '14 at 21:08