与ASP.NET MVC项目本机DLL依赖关系 [英] Native DLL dependencies with ASP.NET MVC Projects

问题描述

编辑：我找到了一种方法让它在本地工作，但是在 Azure 我仍然得到 System.IO.FileNotFoundException 在该程序集。
我的问题可能与这个问题在这里。但是它略有不同，我已经尝试过这个解决方案，但它没有起作用。以下是详细信息。

我有一个ASP.NET MVC应用程序，其中添加了一个参考添加到第三方 CLR DLL。该第三方DLL需要一个它调用的本机DLL。现在，如果我能够控制影子复制的发生地点和复制的地方，我会在天堂。影子复制错过复制本地DLL，尽管它是构建动作设置为内容和复制到输出目录设置为复制始终。

所以我搜索互联网， a href =https://stackoverflow.com/questions/28275944/how-to-include-libsodium-net-on-asp-net>关于SO的讨论，与前面提到的相同。我尝试添加在 Application_Init 和 Application_Start PATH环境变量的代码c $ c> Global.asax ，我在两种方法中设置了断点，令我惊讶的是，在获取ASP.NET错误页面之前，它甚至打破了断点。这使我相信在绑定时引用的程序集命中本机DLL并调用它。我能做什么？我可以延迟参考绑定吗？
编辑：是的，我打开了引用DLL的代码，它是用Managed C ++编写的，我将链接器设置调整为 Delay Load native DLL，现在我的首先执行 Application_Start 。 Yayy！但是这并不能解决与 Azure相同的问题。

这是DLL的测试解决方案

这是Native DLL的源代码

以下是使用本机DLL的引用程序集的源代码

要下载Native DLL分发， Go到他们的分发页面，选择你想要的位置（我使用32位）的windows档案，你会发现 amzi.dll 在API / bin目录。

解决方案

实际问题是在Azure服务器上不能识别的包装DLL使用早期框架和工具集的缺乏支持以及Debug CRT。

1. 我使用XDT / Application_Start来设置PATH环境变量包含我的本机DLL的位置




2. 我升级了我的Managed C ++ Wrapper DLL，使用Toolset 14.0和.NET 4.6.2




3. 在托管C ++ Wrapper DLL上使用/ DELAYLOAD的链接器设置

EDIT: I found a way to get it to work locally, but on Azure I still get System.IO.FileNotFoundException on that assembly. My question might seem like a duplicate to this question here. But it is slightly different, I have already tried that solution and it did not work. Here are the details.

I have an ASP.NET MVC App that has a Reference added to a third party CLR DLL. That third-party DLL requires a native DLL which it invokes. Now if I had control over where the Shadow Copying occurs and what is copied, I would be in paradise. The Shadow Copying misses copying that native DLL despite it's Build Action set as Content and Copy To Output Dir set as Copy Always.

So I searched internet and ran into this discussion on SO, which is same as what was mentioned earlier. I tried adding the code that sets the PATH Environment Variable inside Application_Init and Application_Start of Global.asax, I set the breakpoints in both the methods and to my surprise I get the ASP.NET Error Page before it even hits the breakpoint. This leads me to believe that the referenced assembly at the time of binding hits the native DLL and invokes it. What can I do? Can I delay the reference binding somehow? EDIT: Yes we can, I opened the Referenced DLL's code which was written in Managed C++, I adjusted the linker setting to Delay Load the Native DLL and now my Application_Start executes first. Yayy! but that does not solve the same problem I am having on Azure

Here is the test solution with DLLs

Here is the source code for the Native DLL

Here is the source code for the Referenced Assembly that uses the Native DLL

To download the Native DLL distribution, Go to their distribution page, choose the windows archive with the bitness you desire (I am using 32-bit), and you will find amzi.dll inside APIs/bin directory.

解决方案

Actual problem was the wrapper DLL not recognized on Azure server because of lack of support of earlier frameworks and toolsets, as well as Debug CRT.

1. I used XDT/Application_Start to set the PATH environment variable to include the location of my native DLL

2. I upgraded my Managed C++ Wrapper DLL to use Toolset 14.0 and .NET 4.6.2

3. Used Linker Setting of /DELAYLOAD on Managed C++ Wrapper DLL

这篇关于与ASP.NET MVC项目本机DLL依赖关系的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！