Our application is composed of mixed C# / managed C++ CLI / native C++ assemblies & DLLs.
We have a wrapper assembly that exposes the application's API.
FOR EXAMPLE...to create new console applications that use the API, you must reference that assembly, and also set the console application's output directory to the BIN directory of our installed application. ( due to the use of reflection, etc., everything must stay in the app's BIN directory and output to that directory, you cannot do a copy local of just the one assembly or nothing works )
My issue is when creating an ASP.NET web forms application (nothing to do with the console app), I would like to use that assembly, so I need the web application to "live" in our application's BIN directory.
When I try that errors occur due to ASP.NET trying to preload every single assembly in that BIN directory.
Can someone provide instructions on how to get this to work? I've spent hours now on every combination of referencing assemblies, copying them all, and trying to use LoadFrom.
Without seeing the construction of this it's hard but ...
Bin referencing
Create a web application and reference the necessary dll from the web site via bin references
Right click the web application, select the browse option and pcik the dlls you need to reference. Select copy local to true so you get the dll copied through to the web application so you aren't forever dependent on the console app being exactly where it needs to be in relation to the web app.
Not a solution I would necessarily go with though - it seems like the arcitecture of the system is a little off. Cross you have to bare etc...
OR
GAC referencing
the dlls that you need to reference from the console app - strongly name them and put them in the GAC (global assembly cache). Both apps will be able to see them then.
Copy over the dll
I guess there is another solution around adding a post build step to the console app that reruns a batch file that will copy over the dlls into the web app. I think that's going to be pretty much the same as the bin reference though really.
Probing element
You could use a <probing> element in your web.config to instruct the CLR to search for other directories for assembles (it normally just does the GAC and bin (a simplification to be fair is that) ). This is going to enable you to reference your API folder - but only if it is under your application path. Although someone here has used an NFTS junction to get around this.
More info here
In fact this answer gives a lot more detail about this kind of thing
How do I reference assemblies outside the bin folder in an ASP.net application?
And good luck
Related
I couldn't find any information about it. Does anybody know whether IIS load all dlls in bin directory of web application or all dlls in any directory or maybe only directories referenced by project (in this case how it determines which dll is "master")?
I've just had a situation where someone didn't remove all files from web application directory before deploying new version, while some dll was renamed. This redundant dll was in bin directory of MVC 4 web application.
As an experiment I made a new ASP.NET Webforms project, and deployed it to IIS. I then made a 2nd .net class library, and copied the .dll file to the web app's \bin folder (the class library is not referenced or used anywhere in the ASP.NET app).
I started up SysInternals ProcMon, recycled the app pool and web site in IIS, and requested the site in a browser.
w3wp.exe does indeed read the class library .dll file on first page request.
This MSDN page also states:
You can store compiled assemblies in the Bin folder, and other code anywhere in the web application (such as code for pages) automatically references it. A typical example is that you have the compiled code for a custom class. You can copy the compiled assembly to the Bin folder of your Web application and the class is then available to all pages.
Assemblies in the Bin folder do not need to be installed in the Global Assembly Cache (GAC). The presence of a .dll file in the Bin folder is sufficient for ASP.NET to recognize it.
Which does seem to imply that ASP.NET will reflect over the assemblies it finds in \bin and automatically load them.
Interestingly, even if you put a non-.net file (I copied twain.dll from C:\Windows) into your ASP.NET bin folder, those files are also read. The runtime seems to just ask the filesystem for \bin\* and loops over the files to check for .NET assemblies to load.
I also noticed that if you add this to your web.config file:
<system.web>
<compilation targetFramework="4.5">
<assemblies>
<clear />
</assemblies>
</compilation>
Then the page will no longer run, with the error
Could not load type 'WebApplication1.Global'.
So it seems that the runtime no longer loads those classes from the assemblies. However, the runtime still reads the non-referenced console application .dll and non-.net assembly twain.dll off the drive.
So, the answer comes down to what you mean by "loads all dlls" ... If you mean makes available in the runtime, then the answer is sort-of "no" if you specify your own system.web | compilation | assemblies but the default is to load all. But if you mean what files are physically read, then "yes".
It doesn't load any DLLs automatically.
Every DLL it loads is directly related to a request. First, Global.asax is compiled (which may load some DLLs from bin). Then, whatever HTTP modules and HTTP handlers are defined in web.config (there's some overlap with the previous step). Then the final aspx/asmx/... Some others might go for the ride as part of the configuration or something like that, but all the DLLs that are loaded are always loaded explicitly.
Thus, there is no "master" DLL. web.config, Global.asax and the actual requested file are the ones to decide what's actually going to happen. If you need to have a particular DLL loaded (and you don't simply have it referenced), you need to do it yourself.
EDIT:
Since this is a bit complicated, let me expand a bit.
The main thing to keep in mind here is that ASP.NET is always dynamically compiled - at least to an extent. At the very least, you always have to compile Global.asax - no way around it. Now, dynamic compilation in ASP.NET has an important feature - it's out-of-process (at least for the legacy compiler - I'm not sure about Roslyn+). So whatever the compiler does to find references etc., doesn't actually reflect what's loaded to the worker process itself - and to your application domain in particular.
The dynamic compilation is handled by the BuildManager class on the .NET side - http://referencesource.microsoft.com/#System.Web/Compilation/BuildManager.cs,fb803c621f3806a8. Since you asked about a "master DLL", the most relevant bit would be the code that handles Global.asax compilation, which is one of the starting points of any ASP.NET application. The very initial compilation is handled by the EnsureTopLevelFilesCompiled method. Looking through the code, you can easily see the first steps:
CompileResourcesDirectory();
CompileWebRefDirectory();
CompileCodeDirectories();
...
CompileGlobalAsax();
Most of this is slightly different for web sites vs web projects, as well as for pre-compiled sites, but we can pretty much ignore that. Now, the code isn't the simplest code in the world, but basically, it boils down to producing a bunch of assemblies - about one assembly per code directory. Again, this is done out of process - while the compiler has to load the binaries in bin, they are not necessarily loaded into the ASP.NET worker process. Instead, only the necessary references are actually loaded.
The main thing to take from this is that the dynamic compilation will indeed do a lot of resolving to help you (after all, you don't even know the name of the dynamic assembly where your types are compiled, so you can't specify it!) - but that doesn't mean that all the assemblies in bin are loaded in your ASP.NET application domain. The easiest way to check this is to add an empty assembly that isn't referenced anywhere to bin, and then print out AppDomain.Current.GetAssemblies - you will see that while the file was indeed touched during the compilation process, it wasn't loaded into the ASP.NET application domain. You need to bear this in mind if you ever try to implement some dynamic module loading in ASP.NET - you need to load those assemblies yourself.
You can tweak the way the compilation works in your web.config (especially the global one) - for example, by default, all the assemblies in bin are loaded for compilation purposes, but you can use the system.web/compilation/assemblies tag to cherry pick whatever you want.
Yes asp.net loads any dlls present in your bin directory .
I have recently written a blog on this as I ran into an issue with dlls which were not used in my project. Please refer this blog ,trying to discuss couple of other common scenarios as well.
Asp.net loads all dlls in the bin directory.
My question may have already been asked but any of the answers match my case.
I need to do a website (ASP.NET MVC 4) with some features of a software. I have finished to developed my website and wanted to test it in a test environment (Windows server 2008 - 64bits).
It works perfectly fine with my dev computer(windows 7 - 64bits). But after I deployed it on IIS, one of my features doesn't work.
This feature is a bit particular. It need a 32 bits COM written in VB6 (this dll can't be change) that call an other dll. When I test the website deployed on IIS, the first ddl is called fine but the 2nd seemed to be not called at all.
This dll are in the installed file of the software. I have the same version of on both computer.
I authorize my app pool to use 32bits application. I tried to give some access to my dll (the COM and interop) like IUSR, IIS_IUSRS. But nothing seems to work.
I have checked both of my dll are registered properly.
I'm a bit lost. Can someone help me ?
PS: Sorry for my English, I can speak but I'm really weak with syntax.
Some suggestion here:
You need to figure out which managed dll, native dll and lib files are referenced by your application (directly or indirectly).
For managed dll, make sure they are in the web's bin folder.
For native dll and .lib files, check out whether those .dll and .lib files are in the PATH. If not, you can either copy them to there; or, you can put them into a folder and add that folder into the PATH. Then restart VS and IIS (command "iisreset") to make sure the setting is picked up.
By the way, putting all of the files in the web's bin folder won't help. The reason is CLR copies the files into a temporary folder under framework directory and run the web there, but CLR only copies away managed dll (not the native ones), so you still get "module not found" error.
I have reproduced this error using the following sample solution
Web1 references a managed c++ project say "MCpp1.dll". The project further references two unmanaged c++ projects with the output say "Lib1.lib" and "Lib2.lib"
If I copy all of those files into web's bin folder, I get the exception of "module not found error".
I create a folder say "C:\Lib" and copy "Lib1.lib" and "Lib2.lib" into it and add this folder into PATH. I restart VS, and also run "IISReset" since I have a IIS web
Open VS and request a page and it works now
I have also contacted the CLR/Fusion team for suggestion of how to get the related module name when this exception happens, which should be very helpful to make diagnosis.
Hope this helps ,
GODFATHER
Is there a way to deploy changes to a single code-behind file when using a "web project" (i.e. the web project dll is in the bin) without deploying the whole dll? Will the single file override the class in the dll if placed in the bin?
No, there isn't. Since it is part of the compiled DLL, you need to recompile and redeploy.
Putting the file in the bin folder will do nothing.
If you have a web farm, you could take some of the servers offline, update the application, put them back online and do the same with the remaining servers, so no downtime occurs (of course, you need to ensure that changes to shared code and systems can work with both versions of your code).
I want to update a class library (a single DLL file) in a production web application. This web app is pre-compiled (published). I read an answer on StackOverflow (sorry, can't seem to find it anymore because the Search function does not work very well), that led me to believe that I could just paste the new DLL in the bin folder and it would be picked up without problems (this would cause the WP to recycle, which is fine with me because we do not use InProc session state).
However, when I tried this, my site blows up and gives a FileLoadException saying that the assembly manifest definition does not match the assembly reference. What in the world is this?! Updating the DLL in Visual Studio and re-deploying the entire site works just fine, but it is a huge pain in the rear. What is the point of having a separate DLL if you have to re-deploy the entire site to implement any changes?
Here's the question: How can I update a DLL on a production web site without breaking the app and without re-deploying all of the files?
The thing to remember is that there are web sites and web applications as far as Visual Studio and ASPNET is considered.
Web Sites typically have all of the aspx and vb files published to the live server and ASPNET Worker Process recompiles the app every time before presentation.
On the other end is the web application, where all of your code behind files get compiled down to a single DLL file and you simply deploy your aspx pages and you bin folder with the DLL file to production.
There is also a "hybrid" known as "Precompiled Web Sites" (see the link for the official MSDN overview) where you don't have the single DLL layout of a web application, but all the compile work of the website is done for you. There are several "modes" to this depending on your needs.
It seems to me that your error is caused because your site is set up as a web site with some kind of precompilation in place. Using the pre-compiled model is a little more "strict" in that is assumes certain files/signatures are in place. Having an updated version of the DLL file causes a break since the precompilation wants a name and a version of the file.
If possible, your best bet would be to convert to a web application, since you can add the additional DLLs into production without a problem. Otherwise, take a look at this matrix to see what form of precompilation you need for your application.
Look at this SO post, might be what you are referring to. The located assembly's manifest definition does not match the assembly reference
Have a look at your reference. Does it say "specific version = true" ? Set it to false, republish your app (you have to do it once, because now your app is still looking for an assembly with a specific manifest) and try it again.
I'd like to know what happens when a native (read: non-.NET) DLL is placed within the Bin folder of an ASP.NET application. Specifically I have ~two questions (I won't bog down these straight forward questions with the specifics of my situation):
Does ASP.NET store the DLL's in memory? Is this why a) I can't delete the files and b) changing permissions on the files doesn't affect ASP.NET's ability to read them?
Also, is it possible for a native DLL in one ASP.NET application bin folder to affect a completely different ASP.NET application? Because that certainly seems to be happening with two of my applications. Is a native DLL a resource that is subsequently used by the ASP.NET client in any context?
for me, if the CLR comes across a non-net dll in the bin folder, it will try to load it and not be able to, and the compiler will show you the YSOD.
if you are having trouble deleting the dlls, i would suggest iisreset - works for me when i come across files i can't delete.
You won't be able to delete any files in the Bin folder of your app until you stop IIS.
Your other app may be dying because it's sharing an AppPool with the application that's loading the "bad" DLL; this may in turn be killing (read shutting down) the AppPool. Make sure each site is running on a different pool and you shouldn't seen any problems on the other site.