I need a little help in terminology.
You can put an assembly in the GAC to "share" these assembly globally in the machine. What do you call if you put the assembly in the same directory where the executable is?
I have been calling it "side-by-side" because the EXE and the DLL is "side-by-side". I've done some reading and it seems that "side-by-side" stands for something else
EDIT: Are those DLLs called "Private assemblies"?
Side-by-side refers to two versions of the same assembly (i.e. 1.0.0.0, 1.1.0.0) being installed in the GAC at the same time.
Whether in the GAC or in the same local directory as the main application EXE assembly, this DLL assembly would be known as a dependency of the main assembly.
One suggestion is using the terms local versions (NOT GAC) and system versions (GAC)
Related
I made some enhancements to the web site in Visual Studio 2012 and rebuilt the project. Up on the IIS server, I renamed the original dll to fooOLD.dll and copied up the newer version, foo.dll.
But now when I try to run the main page, there's an error:
Could not load file or assembly 'fooOLD' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
I have tried stopping and starting the IIS server, to no avail.
Apparently, IIS noticed my renaming of the file and has "remembered" it somewhere. How do I tell IIS that I'm trying to replace the old dll with a newer version?
You need to remove the old DLL from the bin directory.
If you don't, you have two assemblies in that directory with the same AssemblyName:
The runtime does not consider the file name when determining an assembly's identity. The assembly identity, which consists of the assembly name, version, culture, and strong name, must be clear to the runtime.
Now apparently the wrong one is loaded first, causing the error to be thrown, because the loading assembly (your site) is compiled against a newer version of the referenced assembly.
Do iisreset
Go to C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files or
C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files
Note: Select path based on framework version you are using.
Delete folder named after your application.
IIS will use newly copied file.
I have a bunch of assemblies (DLLs) I want to reference in my current .NET 4.5 project. However, right now all of them sit in some local folder in my Hard Drive. When someone works on this same project, these reference assemblies obviously aren't in the same local folder. My plan is to copy these assemblies into some folder in my project, and put that in source control.
Is this a good plan? And what folder do these things usually go to?
NuGet is a prefer method; however, some assemblies are not in NuGet. So here is an example what nopCommerce does.
Create a Dependencies folder (inside your project folder)
Keeps all third parties assemblies inside it.
Definitely a good idea. Generally I'll have a "dependencies" directory at the top level of the solution (or one higher if you have one), with all the DLLs that the projects use. Those are in source control, so when you check the code out, it will just work as-is, since the DLLs are all relative to the projects.
NuGet is the most common way to use external libraries and it places the dependencies in a folder called Packages at the root of the solution folder. You can create a folder called dependencies for your non-nuget dependencies. By placing this folder at the root of your solution you can make relative references so that works for everyone.
Better way to GAC all the DLL assemblies.
http://msdn.microsoft.com/en-us/library/ex0ss12c(v=vs.80).aspx
gacutil -i "DLL File Path"
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.
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