I've more than one ASP.NET 2.0 web site on IIS 6 and Windows Server 2003.
Each site reference some DLLs: design, logic and so on.
Each site is on a different ApplicationPool with default configuration about recycling techniques.
Every DLL is strong named (not delayed) and has a version that never changes (2.0.0.0), all DLLs are placed in GAC.
After I update a DLL in GAC (ie. MyLibrary.dll) that has changed in something (method, classes..) for the use in web-site "A", and after recycling only the "A" application pool, when I try to access to web-site "B" that reference the same DLL I get the common error about that DLL:
The located assembly's manifest
definition does not match the assembly
reference. (Exception from HRESULT:
0x80131040)
Of course nothing is changed in DLL rather than code, same strongkey, same version, culture. The error disappear over recycling "B" application pool, of course.
What can generate a strange, RANDOM (I've to say!), behavior? There's something more, like hashing, that it's used to compare assemblies?
Addendum
Perpetualcoder asked me how DLLs are referenced, if with full qualified name, I think it is, here a line of web.config:
assembly="MyNamespace.MyComponent,
Version=2.0.0.0, Culture=neutral,
PublicKeyToken=1234567890ASDFGH"
I keep repeating myself: don't store files in the GAC unless you absolutely have to. asp.net copies dlls to a temp folder and runs the site from there, it might be checksums mismatch between the loaded dll and the one in the tempfolder.
You should keep your site's dlls local to the sites, in their bin folder. It will give you more flexibility and you don't hurt application B by updating a dll for application A. you also get xcopy deployment for the low price of giving up a bit of diskspace.
Frans, it is a procedure that I understand and it could be a way to deploy of course, but what I don't understand is why even if full qualified name is correct, error comes however.
I saw in DLL manifest, there's the hashing algoritm specification.
Does ASP.NET perform a hashing compare over DLLs?
What I mean in few words: IIS/ASP.NET finds that DDL "A" doesn't match DLL "B" hash, but triplet "key,culture,version" is the same so why it doesn't just update instead popping out an web.config error?
Related
I am getting the classic exception
Could not load file or assembly 'XXX.Base, Version=11.0.0.0, Culture=neutral, >PublicKeyToken=xxxxxxxxx' or one of its dependencies. The located assembly's >manifest definition does not match the assembly reference. (Exception from >HRESULT: 0x80131040)
The assembly D:\xxx\xxxx\xxx\bin\xxx.xxx.xxx.xxx.dll was found but could not >be loaded.
It might have the same name as the referenced one but different version, >culture or public key token.
I know there are tons of these posts on SO and all over the web, but I have one question to which I have not been able to find an answer. Where else, other than web.config, does an ASP.NET get these version numbers from? In the references section of my app, the version is listed as 9.0.0.0. However, when I compile the app and put into IIS, I'm getting exceptions for the wrong version number.
I have already tried:
recompiling the app,
restarting the server,
restarting IIS,
clearing the ASP.NET temp files
restarting the app pool,
putting a newly recompiled version of the app onto the server,
checking the web.config (I can't even find some of these dlls referenced at all in the web.config file)
checking the packages.config file (it's not in here either)
Are there any other spots where these references are stored? I know that in visual studio I can expand references, but I'm assuming that list is stored in a file somewhere and I'm wondering where that file might be?
Where does my app get the idea that it needs version 11.0.0.0 of the assembly when it's listed as 9.0.0.0 in references?
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.
By common DLL I mean that on the file system of the server running the two that there is only one DLL shared by the service and the site.
The goal is that the DLL will have it's own App.config file so that when the service hits the DLL and asks for settings in the config, and when the website hits the DLL asking for the same settings, that those settings will always match each other.
I imagine that if the service uses a different copy of the same DLL with a different copy of the App.config, then the service's DLL's config may not match the website's DLL's config. I'm trying to ensure integrity by only having one set of the DLL and it's config on the server.
Is this a feasible goal?
I know I have to write up specific code in the DLL to ensure that it won't read either Web.config but that doesn't seem too bad. Are there other concerns I'm not thinking of?
First of all, why share the same physical assembly? There is no benefit whatsoever, and quite a few drawbacks. Even if the assembly contains generic functions which are non-application specific, each application should reference it's own local instance of the assembly.
Secondly, no it's not feasible to set up DLL config sharing at runtime (except by abusing the machine.config). Even if you GAC the assembly for sharing (recommended if you absolutely must share it), the assembly still executes under the context of the app domain which loads it, and each app domain has it's own config.
The ideal way would be package the assembly as a NuGet package and then you can easily manage the shared config requirement by including a configuration template as part of the package.
Is it required to have anything SQL Server related installed on a web server in order to make use of SMO? I've built a web app that programmatically creates a SQL Agent job, adds a step (which ultimately fires of dtexec to run an SSIS package), and executes.
This works fine on my local machine which has SQL client tools installed, however when I move to a web server, I get reference issues and I'm starting to think it's due to something not being installed.
Could not load file or assembly 'Microsoft.SqlServer.SqlClrProvider, Version=10.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91' or one of its dependencies.
This is a rat hole.
The problem is that once you locate that assembly and copy it to the bin folder of your application it will complain about a completely different one.. or even the same file simply due to missing dependencies.
For more information read this: http://www.sqldbadiaries.com/2010/10/20/how-i-fixed-could-not-load-file-or-assembly-microsoft-sqlserver-smo-version10-0-0-0-issue/
That site lists the files you need and the fact you need to register and gac a few files. Quite frankly, you are much better off just biting the bullet and install the client tools on your web server.
Yes, your application requires this assembly in its bin directory to function. This error means that the server doesn't have the SMO (and its dependant) assemblies.
Back in your solution in Visual Studio, right click on the assembly above, and select/change the "Copy Local" to "True". Copy this for each SMO assembly that you've referenced.
When you publish your application, this will bring those .DLLs on your development machine along in your published bin directory.
Check your web.config file for any references as well
search your code for SqlClrProvider
I have a solution which contains multiple WAPs (Web Application projects).
Every WAP has it's own Web Deploy project in order to be able to precompile these sites.
On one of the web app we are created a new WCF file with
AspNetCompatibilityRequirementsMode.Allowed
In debug mode it is working ok, but if i switch to release it crashes:
(we are using msbuild to create the deployable versions)
Could not load file or assembly 'App_Web_*****, Version=0.0.0.0,
Culture=neutral, PublicKeyToken=null' or one of its dependencies. The
system cannot find the file specified.
I found some explanation in this link: WCF service
WCF stores the list of referenced assemblies into the customString
attribute in the build result (service.svc.cdcab7d2.compiled),
including App_Global. It seems there is an incorrect assumption here
that those assemblies will always be there, which is not necessarily
the case in Web Deployment Projects (aspnet_merge) where assemblies
will be merged. After the merge step, the assemblies are actually all
merged into a single assembly (let us say MyWebSite.dll) as we
selected that option in WDP. ASP.NET only updates the .compiled files
it knows about, so App_Global.asax.compiled actually has a correct
reference to MyWebSite_Deploy.dll instead of App_Global.dll. Original
assemblies are removed after the merge step. WCF reads the list of
assemblies previously stored, and throws when it cannot find
App_Global
List of solutions i've tried:
1.Check 'Allow this precompiled site to be updatable' - not worked
2.Remove manualy the App_* reference from service.compile file
(It worked but it should be another solution)
3.Add fully qualified name for the service/factory in .svc
The service has a fully qualified name.
4.tried to set this key:
<SourceWebPhysicalPath>..\..\ProjectName</SourceWebPhysicalPath>
following these instructions
5.<compilation debug="false" batch="false">
Tried this to set to web.config using these instructions
6."Merge All outputs to a single assembly"
i haven't tried this because it requires to register all the used assemblies to GAC and means we need to change the deployment logic.
I don't want to delete the asp.net temporary folder because it stops the application and it is inacceptable
I also found Scott Gutthrie link but it's from '07 it should made it's way to asp.net 4.0
Additional Info
The service is placed: ProjectName\WebResorce\Service.svc ,
<%# ServiceHost ... Factory="SolutionName.SharedWeb.WadoLabsServiceHostFactory" %>
where the SharedWeb is a Shared Web project
Do you have any other ideas?
Thanks in advance
The following setup worked for me:
In the svc file, specify a qualified name of the service, as <%# ServiceHost ... Service="<Namespace>.<ServiceContractClass>, <AssemblyName>" CodeBehind="ServiceContractClass.svc.vb" %>
(Can't remember why it was required, but) I made sure that the Namespace and the AssemblyName are different.
The trick is to specify the qualified name, including the AsseblyName.(The assembly name that is specified in the project containing the service, not the Web Deploy Project).
Also note that there is a space between the comma after the class name, and the AssemblyName.
Why don't you implement the WCF services in a separate library project inside the same solution, and simply reference that project from your web app(s)? That way they would stay out of the pre-compilation process, and you could work with predictable type names inside the *.svc files. Plus, this would probably also give you a cleaner solution structure.