Unable to use a 3rd party DLL in an ASP.NET application, but works from a Windows Forms .NET application

0
votes

We have a 3rd party application that provides an SDK in the form of a DLL that can be used to develop custom applications that connect to their service. The DLL lives in the 3rd party application's directory along with a bunch of other DLLs that it depends on. The SDK guide provides instructions for creating a test application through Visual Studio and it says to add a reference to the SDK DLL with Copy Local set to False. I created a test Windows Forms .NET application and added a reference to the DLL as per the instructions and everything worked fine. Referencing the DLL in an ASP.NET application, however, results in a FileNotFoundException exception for one of the dependent 3rd party DLLs.

As an experiment, I tried adding a reference to the offending DLL to my project with Copy Local set to False, but got the same error. With Copy Local set to True it gets further, but then fails on another DLL. Adding a reference to that DLL fails regardless of the Copy Local setting.

I assume the issues have to do with differences between how "standard" .NET applications load assemblies vs ASP.NET applications, but I'm not quite sure how I should go about resolving this.

Is there a proper way to reference a 3rd party DLL (and its dependents) in an ASP.NET application without putting them in the GAC or the application's bin directory?

1
c#asp.net.netdll.net-assembly
There are a lot of ways where this could go wrong, so it is not possible to give you an answer based on what is in your question. The 3rd party DLL might have dependencies in C or C++, or it might not even be designed to work on ASP.NET. The modern way to reference a DLL is by using NuGet (if a package is available), which usually takes care of the dirty details about referencing its own dependencies. – NightOwl888

1 Answers

2
votes

ASP.NET web apps on IIS run in session 0 with limited resources, compared to WinForms apps running in your user session with much more permissions and resources.

They are completely different environments by nature, so unless the vendor of such a library claiming ASP.NET/IIS support you should simply assume it is not compatible, and should be avoided.

You should notice that even Microsoft's own technologies (Office automation, System.Drawing and so on) only support WinForms, but not ASP.NET.