I have an integration that’s working fine as a console application but I need it to work as a Web API for my integration to work correctly. So, I start a new project in Visual Studio, choose "ASP.NET Web Application (.NET Framework) for the template, target the .NET Framework 4.7 and run the bare app in IIS Express, which gives me a basic start page. Then I close the page, add the Milestone SDK through NuGet, and restart IIS Express, which is when I get this message.
I have searched this forum and found this post, which indicates to me that the app is not able to find its dependencies. Unfortunately there was no clear answer on that post, and I read all the posts that were referenced by the Milestone engineer, but they all involved old instructions that from what I can tell don’t apply since the switch to Nuget. Also, the dependencies do appear to be installed where they belong, right in my project’s \bin folder. However, this appears to be caused by the fact that the project is not run by its own executable like a console app, it is instead hosted by IIS Express, which runs out of [C:\Program](file:C:/Program) Files\IIS Express.
I have manually copied all the Milestone dependencies to this folder (which is not a clean solution but only for troubleshooting purposes) and that changes the error from not being able to find AVIExporterClientMW.dll to not being able to find System.Web.Http, so it appears a step in the right direction. I then tried copying all the System*.dll files into the same folder but that didn’t clear up that second error. So it’s not so much that the dependencies aren’t there, it’s that the app is somehow misconfigured and not able to find them even though they appear to be where they should be.
The issue is that the Nuget SDK package has not been designed for IIS. It contains dll’s which reference native code dll’s.
The IIS (and IIS Express) is not able to load native dll’s automaticly. When w3wp.exe runs it is able to find .Net dll’s in the bin folder of the website, but it will be looking elsewhere for native dll’s.
To solve this the workaround is to add the bin folder to system paths. Do the following:
- on development machine or deployment server go to ‘edit system environment variables’. Note that it is the system environment variables, thats important.
- On the window being shown, choose Environment variables
- Then go to lower part of the variables (System variables) and find path. Choose edit
- In the new popup click “new” and write the path of the bin folder. Could be [c:\inetpup\somewebsite\bin](file:c:/inetpup/somewebsite/bin)
- Click ok (3 times to close all windows)
- Most of the times it is enough to restart IIS or visual studio (if using IIS Express), but to be sure the change has effect, restart the entire computer.
That worked, thanks! Been stuck on this almost a week, so this is fantastic.
Update: While adding the project’s bin directory to the system path solved my original issue, I immediately ran into another issue: Could not load file or assembly ‘System.Web.Http’. This one had to do with not being able to find the requested version of 5.2.7.0, only 5.2.6.0 could be found. Using the ILDASM tool I was able to determine that the version of System.Web.Http in my bin folder was 5.2.6.0. I tried updating all packages using NuGet Package Manager but I was still stuck with 5.2.6.0.
Next, I created a new project using the same template (ASP.NET Web Application .NET Framework: Web API) and checked the version of System.Web.Http in that new project’s bin directory, and it was the correct 5.2.7.0. Out of curiosity, I installed the Milestone SDK package, and sure enough that file was replaced with the 5.2.6.0 version. So, somehow, installing the Milestone SDK rolled back System.Web.Http from 5.2.7.0 to 5.2.6.0, thus breaking the application.
So, to get access to the correct dll again, I created a second new project, but this time did not add the Milestone SDK, copied the 5.2.7.0 file to my original project’s bin directory, and am finally able to load an run it correctly. This isn’t the cleanest solution but hopefully it will help someone get past the problem until someone more knowledgeable comes up with something better!
Adding it to path was not enough for me.
I was using IISExpress, and I had to do another workaround which consists of adding a property group in your .csproj, below the tag, to use IISExpress with 64-bit :
<Use64BitIISExpress>true</Use64BitIISExpress>
Hi, adding the project’s bin folder to the system path didn’t solve me the Issue (IIS 7/x64 - MIP 2022 R2). The simplest workaround that I found was to intercept assemblies loading and force to look first at the bin folder.
private string LibPath= "D:\DEV\MIP-SDK-LIBS\";
--------------------------------------------------------------------
//Subscribe to assembly resolve event
var domain = AppDomain.CurrentDomain;
domain.AssemblyResolve += Domain_AssemblyResolve;
--------------------------------------------------------------------
//Intercept assembly resolving and force to bin folder
private Assembly Domain_AssemblyResolve(object sender, ResolveEventArgs args)
{
Assembly result = null;
if (args != null && !string.IsNullOrEmpty(args.Name))
{
//Get current exe fullpath
FileInfo info = new FileInfo(Assembly.GetExecutingAssembly().Location);
//Build potential fullpath to the loading assembly
var assemblyName = args.Name.Split(new string[] { "," }, StringSplitOptions.None)[0];
var assemblyExtension = "dll";
var assemblyPathLib = Path.Combine(LibPath, string.Format("{0}.{1}", assemblyName, assemblyExtension));
//Check if the assembly exists in our "Libs" directory
if (File.Exists(assemblyPathLib))
{
result = Assembly.LoadFrom(assemblyPathLib);
}
else
{
return args.RequestingAssembly;
}
}
return result;
}