I know not to put strongly named assemblies into the bin folder on early versions of ASP.NET. I remember this caused problems, but I don't remember specifically what problems. Does anyone know if this still applies to ASP.NET 2.0? Is there any reason not to put strongly named assemblies into the bin folder on ASP.NET 2.0 or later versions?
The problem you describe was fixed on .NET 2.0, so you don't need to worry about it anymore.
However, beware that if you put a strong-named assembly in the bin folder, and an assembly with the same strong name exists in the GAC, then the assembly in the GAC will get loaded.
There should be no problems with this. I've done it a few times during development/testing and I even have a site currently running that has strongly named assemblies in the bin folder with no issues.
Assemblies are strongly named for a reason (obviously) so you should have a good reason to drop them in the bin folder.
I have not experienced problems with strong named assemblies being put into the bin. I have experienced some Interop problems with strong named assemblies and versioning conflicts, but those were caused by developers compiling older versions of an ComPlus application library into the solution instead of the current or newer version.
Related
Am I doing this right? I've got many, many separate ASP.NET webforms projects which reference the same main library which contains many tool methods. When I change something in that library, I don't know of a way to make sure that these projects get the updated version of the library. Does auto-refresh detect changes in references even if you don't open the project in Visual Studio? Or does IIS know when a reference has changed and will recompile the project?
Assuming the DLL file is binary compatible (changing an existing method signature is the easiest way to break compatibility) all it comes down is that the newest DLL is in the \bin\ folder. If the site is running it would need to be restarted to pick up the DLL being replaced.
If this is a project reference in your solution, building just does all of this for you.
If this project is outside of your solution, you really should look into using Nuget to distribute this shared project. Even if you only distribute it to yourself. You do not need to host the package publicly on nuget.org
I am getting a build error when I attempt to build my asp.net application. The error is:
The type 'MediCare.Framework.Authentication.IUserAuthenticate' is defined in an assembly that is not referenced. You must add a reference to assembly 'MediCare.Framework, Version=1.0.1.95, Culture=neutral, PublicKeyToken=1999fa3c42b9'.
I can see the class in the library which is in the references folder. How do I debug this issue?
My intention is to point the references folder to the library source code's bin directory (since the pdb file is lcoated there and any updates to the library will reflect in the application). However, when I point the references folder to the bin directory of the source code, I get the error message above.
Update The application was originally developed in VS 2008 and I am modifying it in 2010. I think I am confused about where the GAC assemblies would be, if I am using VS 2010 (2.0 framework location or 4.0 framework location) ? .NET 4.0 has a new GAC, why?
Update (06-26-2012)
The file in the GAC ("C:\Windows\assembly\") has been deleted. But this error is still occuring.
This could possibly be caused by version inconsistencies. Meaning, in order to fix this, I would do a complete clean build of your assemblies (and also an assemblies that might be nested inside an assembly). Just go out cold and do a new build on all assemblies. That should work.
Go into windows explorer, right click on the DLL file that your project is using that contains this class, and look at the version tab. Make sure version number matches what you see in the error message. My guess is that it won't.
If it does match, then check the GAC and make sure there isn't a different version of the DLL there that it could be picking up. To do that, go to windows explorer, and navigate to c:\windows\assembly. See if that assembly is in there with a different version number. If it is, you may need to delete it from the GAC (use caution though because other apps may depend on it being there).
An episerver installation puts the episerver assemblies in the GAC, I see them with C:/windows/assembly.
Besides, all the episerver dll's are present in C:/Program files/Episerver after an episerver installation.
When a create an episerver project via the episerver deployment center or with Visual Studio 2010 using the episerver template, I see that the bin-folder of the newly created project contains a lot of episerver-dlls, which is not very surprising. And I suppose that they are copied from C:/Program files/. If I open the project in visual studio, I see that it's those dll's that are referenced and not the ones from the GAC or from C:/program files/episerver.
Well, all of this is very confusing.
Why is Episerver putting dll's in the gac and not referencing them? What is the best way to handle references to episerver dll's for development in a team?
Moreover, IF episerver would reference the ddl's from the GAC, how would I see that in VS. I mean, what would the properties of the reference be?
Basically, this is all just episerver deployments decisions. I'll try and go over every your question one by one:
Putting dlls into GAC is useful when you want your users to access dlls in the reference dialog from ".NET Framework" tab. Suppose you're creating simple project (not episerver one) and want to add episerver dlls. Instead of looking for them on the hard drive you reference ones that are pointed from the GAC. That's easy for development.
Why not reference GAC dlls ? It's to easier deploy your solution with the dlls. Suppose you're deploying your solution to the server. Server won't be having episerver dlls in the GAC (and shouldn't have, anyway). So they're probably setting "copy local = true" property to copy the dlls into the output folder, making your solution portable. Also, the GAC assemblies aren't "referenced" - GAC just contains copies in a case of need and a reference is added to the "program files" folder with the dlls.
Best way for a development team is to use GAC or to define some kind of "Third Party"("externals") folder in the repository and put your dlls there (and reference from there). First approach requires episerver install on every dev machine, second uses up some space in your repository.
As GAC assemblies can't be referenced (they actually can be, but it's a headache), there is virtually no difference between the result - different paths only.
We usually create a separate directory where we store all .dll-files and reference them from that directory. This means all third party-librarys and episerver-dlls.
The biggest reason for doing this is to avoid a hassle when a new developer needs to setup the project, and also to avoid conflicts between different versions when referencing from GAC.
I'm trying to set up a web app (32bit on ii7/win7, 32bit setting is enabled, everything is compiled to x86, using vs2008), but there's clearly some dll module loading issue happening. I've been watching procmon and fusion logs but I'm not seeing the name of the missing dll.
I'm a complete newbie to asp.net (but fairly heavy experience on other platforms).
I know I can call depends.exe on a binary to see what the dependancies are, but how do I do it for asp.net? specifically, is it possible to get a list of the dlls that iis7 loads for my application?
update: I manually blew away all of the binaries for my application and rebuilt (clean didnt seem to do the trick, I guess). it's now sort of working. or at least it's getting further and more detailed.
An asp.net web project dll shouldn't depend on anything that is not part of the default .net run-time or explicitly referenced in the project. I would start by reviewing the references. Noramlly an asp.net web project has a bin folder that contains the compiled website/webapplication and any dll's that it depends on (aside from the .net run-time). This is usually done by the programming tool used to create the project.
If you still don't find the culprit, you could try using Filemon (http://technet.microsoft.com/en-gb/sysinternals/bb896642.aspx) and use it to watch IIS to see what files it is looking for and isn't finding.
An additional option is to examine the web.config file that should have been included with the web site/application. Its an XML file and usually has an Assemblies section that lists assemblies that should be loaded. For example you might see:
<assemblies>
<add assembly="MySql.Data, Version=6.2.3.0, Culture=neutral,
PublicKeyToken=C5687FC88969C44D"/>
</assemblies>
This means that the code wants to use the MySQL.Data.dll, and specifically version 6.2.3.0 of that DLL. It is possible to have different versions of .Net dll files installed at the same time. So you might have the desired DLL, but not the correct version as specified in the Web.Config file.
We have a web application that's deployed to many websites with only frontend changes, the shared backend portion has it's DLL in the GAC so we only have to update that one dll and all the sites get the update.
Is there a way to override the GAC with a DLL in the /bin folder to test out new features before they get released?
If it has the same version number as the referenced DLL, the GAC gets used.
If you increment the version number, rebuild the website referencing the new version number, put the new version in the /bin directory, then that DLL will be used.
If you do not want to change the version number, you're pretty much out of luck.
When .NET loads strong named assemblies, first it tries to decide what version number to use. It does this via the reference first, then it looks for publisher policies, then it looks for binding redirects in the configuration file.
After it does this, it looks for the assembly in the GAC, then in any codebase specified, then it probes various file system folders for the DLL. If at any one of those steps it finds the right version assembly, it stops.
If you are not changing the version number of your strong named assembly, .NET will find the original one in the GAC and stop looking. Note that because it stops when it finds one, and because looking in the GAC is first, specifying a codebase for your assembly will do no good unless you also specify a new version number.
I have been able to override the GAC with the assembly in the \bin folder using the <codebase>Element.
By specifying <codebase version="1.2.3.4" href="/bin/MyAssembly.dll" /> in my web.config file I can tell my application to use this version rather than the version specified in the GAC.
You may also want to take a look at the <probing>Element for specifying assembly locations?
I think I might be saying the same think as Adam Sills, but re-worded it for my understanding. Through my own testing, looks like this is what happens:
If your app is compiled with version 1.0.0.0 and 1.0.0.1 is in the GAC, then you can omit the .dll from your /bin.
If your app is compiled with version 1.0.0.1 and 1.0.0.0 is in the GAC, then you MUST place the .dll in your /bin to ignore the GAC. A error will occur if the GAC version is older than the required version of your app, unless you include the newer version in your /bin.
I hope this is correct...
You can view binding information in the log file using the Assembly Binding Log Viewer (Fuslogvw.exe), which is included in the Windows Software Development Kit (SDK).
s