IIS ASP.NET MVC and dllimport calls lock the file preventing future deployment
So I have a ASP.NET MVC project handling video files uploads, and I used the MediaInfo library (C++) along with the included C# wrapper (using DllImport functions) to determine the video duration. I added the MediaInfo.dll file to my project, and set the "copy to output directory" to always. Everything works perfectly.
My problem is that when I rebuild (from Visual Studio) or re-deploy the project to my production environment, it fails because the file is locked.
Unable to copy file "SourcesMediaInfoMediaInfo.dll" to "binMediaInfo.dll". The process cannot access the file "binMediaInfo.dll" because it is being used by another process.
Of course, that's because IIS is still running. I'm aware I can stop the AppPool, rebuild, and restart it, but it is an hassle to do it every time you build in development, and complicate updates in production. Especially when every other DLLs (.NET) and the rest of the project can be updated without having to do that.
So I tried the method suggested here and here . Each time I want to scan a video, I use LoadLibrary() and after call FreeLibrary() until it returns false. The FreeLibrary part works, it unlock the file. But calling the method a second time, it calls LoadLibrary and then at the first DllImport function call, I get an InvalidOperationException and the process crash.
I feel like I'm overdoing thing and it don't feel normal and I'm wondering if I'm completely on the wrong track.
What's the usual method to develop using non-managed dll calls in a usual Visual Studio / MVC environment?
After reading more on the subject, if you want to control the DLL loading/unloading process, it can't be done with DllImport. You need to use GetProcAddress to call the functions. You could also create a C++/CLI library.
In my case, I managed to "hack" around the problem by creating a different AppDomain every time and forcing a FreeLibrary call and a AppDomain.Unload. This cause the DllImport to reload the dll successfully because it's a different AppDomain.
链接地址: http://www.djcxy.com/p/44542.html上一篇: 依赖于其他DLL的插件DLL