I have a Windows Server 2008 Standard 64-bit box on which I run a test web site under IIS7.
My hosting provider has the same configuration than me yet my precious custom DLL is not honored?
Calls to my DLL (plain vanilla _CDECL Export Functions) are, well. "ignored".
No error message. Nothing. Zilch. I press the button in the middle of the page that should trigger the calls but nothing happens.
The DLL is located in C:\Windows\SysWOW64 on both machines.
That's the path used in my DllImport declaration.
The site is setup with ASP.NET v4 with Integrated Pipeline mode.
I checked for pesky dependencies and this DLL makes calls to Kernel32.dll and NTdll.dll, both of which who are sitting in C:\Windows\SysWOW64 next to my dear DLL.
No, I didn't have to register this DLL on my machine.
Any ideas would be appreciated.
Related
While using a native dll dependency on a asp.net web project and debugging in VS2015 with IIS express I'm getting the dreaded:
Could not load file or assembly 'XXX.DLL' or one of its dependencies. The specified module could not be found.
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.
Exception Details: System.IO.FileNotFoundException: Could not load file or assembly 'XXX.DLL' or one of its dependencies. The specified module could not be found.
HOWEVER the same dependency works fine in a simple forms app on the same machine - hence I assume all the dependencies and co-dependencies are present
maybe you have some clues, how can this be?
What I already tried:
putting all the potential dependencies in the web project output folder
putting all the potential dependencies in the /system32/ path
putting all the potential dependencies in the /system32/inetsrv and /sysWOW64/inetsrv
installing c++ redistributables (2010, 2012, 2013)
I 'unblocked' the dlls as they "came from another computer" (CASpol)
dependency walker did not give any clear results
process monitor did not give any clear results
some details:
VS2015 Community, running on an Azure VM with Windows Server 2012 (test system), clean install
the app uses CGAL and BOOST libraries (c++).
'Dependency tree' is as follows: C# wrapper references a CLR C++ project which in turn references the native C++ (only this one uses CGAL/Boost);
The C# wrapper is then used in the forms app (works) or the asp.net web app (doesn't work);
Putting Cgal dlls (around 6 files) into the bin output folder was enough to run the forms app.
PS: of course on my 2 dev machines (Win 7, Win 10) the asp.net project works swimmingly - but these contain dedicated installs of the huge c++ references.
PPS: I currently really prefer to use iis express due to external reasons. I have to simulate deploying the app on a clean-ish Win10 laptop, in a dev environment, with minimal external installations
PPPS it seems the win10 dev machine isn't working after all - edit: this was the key clue, see my answer below and Ho do I reference native files in IIS express?
I'm a bit stuck right now, thanks.
Solution: on Win 10 I copied the dll output (\bin folder) into the Program Files (x86)\IIS Express folder (as I am using the 32-bit version).
Apparently, this wasn't needed on Win7 - I will have to investigate why
I found this solution in:
Ho do I reference native files in IIS express?
EDIT: another, more elegant (?) solution is to disable shadow-copying in web.config as in http://faithlife.codes/blog/2013/05/using-native-dlls-from-asp-net-apps/
"The simplest solution I’ve found is to turn off shadow copying, which causes the DLLs to be loaded directly from the bin directory.(...) Just add a hostingEnvironment element to your web.config:"
<configuration>
...
<system.web>
...
<hostingEnvironment shadowCopyBinAssemblies="false" />
I have a simple C# 4.5.1 x64 application which calls unmanaged dlls via a /clr C++ wrapper. App runs fine on my development machine. If I copy to Windows Server 2008 or Windows Server 2012 (with Framework 4.5.1 installed) I get an error that the wrapper won't load.
I have installed DependencyWalker on the deployment machine and I get this:
LoadLibraryExW("MyWrapper.dll", 0x000.., LOAD_WITH_ALTERED_SEARCH_PATH) called from ...
Loaded "MyWrapper.dll" at ... Successfully hooked module.
Loaded "XX.dll" at ... Successfully hooked module. (Dependency for MyWrapper.dll)
Loaded "YY.dll" at ... Successfully hooked module. (Dependency for MyWrapper.dll)
Unloaded "MyWrapper.dll"
Unloaded "XX.dll"
Unloaded "YY.dll"
LoadLibraryExW("MyWrapper.dll", 0x000.., LOAD_WITH_ALTERED_SEARCH_PATH) returned null. The specified module cannot be found.
Does anyone know why everything is loaded then unloaded and then cannot be found?
Make sure you have all the necessary redistributables (vcredist.exe) installed and you deploy a release build.
Any unmanaged c/c++ dll and also c++/cli dll links to msvcr. It is automatically installed with Visual Studio on the developer machine. It must be installed on the deployment machine together with the app. Make sure to redistribute the correct vcredist.exe version which corresponds to your version (and service pack) of VS. For vs2008 it resides in %ProgramFiles%\Microsoft SDKs\Windows\v6.0A\Bootstrapper\Packages). Note: Dependency walker does not show missing dll if it is loaded using LoadModule() or methods are loaded using [DllImport("Sample.dll")] in c#. In that case, open the unmanaged dll directly in Dependency walker and check missing deps. Make sure, unmanaged dll is in search path of your app.
I have an ASP.NET application, which has two references added: MapServer and GDAL. These two DLL's uses a bunch of other DLL's, and all of them are in my applications /bin directory.
When I run the application on my own PC in Visual Studio 2010 it runs fine. When I upload it to my Windows 2008 server with IIS it throws this exception:
Could not load file or assembly 'gdal_csharp' or one of its dependencies.
An attempt was made to load a program with an incorrect format.
When running the application through Visual Studio on the server it runs fine.
I've even tried adding the /bin directory to the PATH enviroment variable, and restarting the server. No luck though.
My guess is that the DLL is a 32-bit only DLL that you are trying to run in a x64-environment. Can you try to set the app-pool to 32-bit only?
Update: a simple instruction is here: http://help.webcontrolcenter.com/KB/a1114/how-to-enable-a-32-bit-application-pool-in-iis7-dedicatedvps.aspx
You need to register the dll at GAC: http://en.wikipedia.org/wiki/Global_Assembly_Cache
As already mentioned you may be missing something from the GAC.
To see whats happening you could try turning on Fusion Logging, this will enable you to view all of the assembly load failures.
Back to Basics: Using Fusion Log Viewer to Debug Obscure Loader Errors
I am developing on a 64bit version of Windows 7, running MOSS (SharePoint), this is my dev machine.
Now when I deploy my web service app to a test server Windows 2003 32bit (no Sharepoint installed) I get this error.
Could not load file or assembly 'Microsoft.SharePoint.Library, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c' or one of its dependencies. The system cannot find the file specified
The DLL has clearly been copied to the bin directory (Microsoft.Sharepoint.dll).
Any ideas?
If you are using sharepoint dll's it will only work on a machine with sharepoint installed.
Even if you managed to hack it and get it to work, you would probably be breaking a license agreement.
There is a way to load Sharepoint libraries in a development console with windows XP, Vista or Seven.
See here: http://fernandof.wordpress.com/2008/02/11/how-to-install-the-sharepoint-2007-vs-2005-extensions-on-a-workstation/
[O]pen the regedit and create the following keys and the string value:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\12.0]
"Sharepoint"="Installed"
That’s it! You have fooled the installer into running on a
workstation. Easy. I also recommend adding the core SharePoint
assemblies into the [GAC] using gacutil. Those assemblies can be found
by default in any [SharePoint] machine under the folder: C:\Program
Files\Common Files\Microsoft Shared\web server extensions\12\ISAPI.
This is almost certainly a dependency issue. The DLL is dependent on another DLL which isn't in the GAC or on the probing path. The two tools you need to figure this out are FUSLOGVW.EXE and Process Monitor
Fusion Log viewer will allow you to look at assembly bind successes and failures as your application loads. It's part of the Windows SDK.
http://msdn.microsoft.com/en-us/library/e74a18c4(VS.71).aspx
FUSLOGVW needs admin privs to run correctly.
If that doesn't work another tactic is to use Process monitor to look at which files aren't getting loaded and which folders are being searched.
http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx
However. Without SharePoint installed I wouldn't expect this to work.
Ade
From MSDN:
"The CI build environment for the Training Management application does not perform any tests that require a live instance of SharePoint. All the unit tests use mocks that replace the actual SharePoint instance and services. Building the code and running the unit tests only requires that the following SharePoint assemblies are installed on the CI build server:
Microsoft.SharePoint
Microsoft.SharePoint.Security
Microsoft.SharePoint.WorkflowActions
Supporting referenced assemblies"
http://msdn.microsoft.com/en-us/library/ff647619.aspx
Don't mix 64-bit and 32-bit for dev / testing / production. This will never work reliably if at all.
Well what about other dlls referenced by the Sharepoint dll? With long dependency chains it can be quite difficult to diagnose these sort of problems. In such situations I find the fusion log viewer extremely useful. It is a part of framework SDK - open the SDK Command prompt and type fuslogvw. It is pretty obvious from there
My company has login integration with GroupWise, and Exchange 5.5/2000+. The Exchange 5.5/GroupWise logic is done using wldap32.dll (win32), and so the login code is in a managed c++ class. When the configuration tool (or the backend service) tries to load the dll built off this managed c++ project on my XP development box, it works fine. On QA/Customer Windows 2003 boxes, a FileLoadException is thrown.
First off, this used to work fine. Secondly, I've validated the same working code on my box fails on the qa box.
How can I track down the cause of this exception?
Have you changed your development environment recently? In particular have you installed a service pack or new release of Visual Studio?
It appears you are linking against a C++ runtime that is not available on the client's server. You can use the Windows Event Viewer to identify the DLL failing to load, or if this shows nothing, use depends.exe to see what runtime DLLs are dependencies for your managed code.
Microsoft has moved to using side-by-side installation to handle "DLL hell", basically this allows multiple versions of a DLL to be installed (side-by-side) concurrently on a Windows installations and have applications load the correct version of the DLL at run-time. Recent releases of Visual Studio make use of this technology so I suspect this is the cause of your 'sudden' incompatibility.
Not to answer my own question, but support just updated the bug with the text following this paragraph. I'm still interested in thoughts on tracking down situations like this.
Resolved by downloading and installing the Visual C++ 2008 Redistributable
Package for Windows on the IMS:
http://www.microsoft.com/downloads/details.aspx?FamilyID=a5c84275-3b97-4ab7-a40d-3802b2af5fc2&DisplayLang=en