I have a simple doubt: I have an external assembly that I want to reference. I have an Asp.Net application. I want to use that assembly in my Asp.Net application.
I add a reference and what VS does is just placing my dll in the Bin subdirectory of my web site.
I thought that VS would have modified my web.config file adding external references...
So does it happen only when referencing assemblies in GAC??? (which makes sense given that public tokens and versions are required).
Thankyou
When the CLR loads your assembly for execution, it checks the assembly's manifest to determine what dependencies are required for it to run. It goes through a series of steps to do this:
Check for redirects - if the assembly is strongly-named, the CLR will first check the appropriate config (app.config, web.config, etc.) to see if there are any binding redirects specified. A binding redirect allows the CLR to say, where I am supposed to load v1.0.0.0, instead load v2.0.0.0. If no binding redirect is found for a strongly-named assembly, it will check a policy file in the GAC, and if no policy file is found, it checks the machine.config. If no binding redirect is specified, the CLR will use the assembly name specified in the calling assembly's manifest to load the assembly.
Check to see if the assembly has already been loaded - the CLR determines if the assembly has previously been loaded, if it has, it uses that same loaded assembly, otherwise it continues...
Load the assembly from the GAC - If the assembly could not previously be loaded and is strongly-named, the CLR will attempt to load the assembly from the Global Assembly Cache.
CodeBase - If the CLR still can't find the assembly, it will use the codeBase path to try and locate the assembly.
Probing - If the CLR still can't find the assembly, it will check the probing path for the assembly. The default probing path is the application base path of the AppDomain into which assemblies are currently being loaded.
(That's all adapted from a great article called Understanding .Net Assemblies and References ).
In the case of your web application, the CLR still does all of the above, but the AppDomain application base path is the /bin folder within your IIS application.
Related
I have the following project structure:
-Solution
-ProjectA
-ProjectB (has reference to ProjectA - projectreference tag that points to csproj of ProjectA)
Both projects have dynamic AssemblyName depending on build configuration. Let's say that if I build with "Debug" config then the outcome will be: DebugProjectA.dll and DebugProjectB.dll. After building in "Release" config, it's going to be: ReleaseProjectA.dll and ReleaseProjectB.dll. Namespace of classes in ProjectA is always the same and starts with ProjectA.*
My question is: How does ProjectB know how to find the correct DLL of ProjectA in runtime? To be more specific: How does it know the name of the referenced project's DLL (that changes in different build configs)?
My guess is that AssemblyName of ProjectA (of given build config) is somehow stored in ProjectB assembly file during the build. Is this correct? How does it work?
This is a direct quote from the documentation on Microsoft's website:
The runtime uses the following steps to resolve an assembly reference:
Determines the correct assembly version by examining applicable
configuration files, including the application configuration file,
publisher policy file, and machine configuration file. If the
configuration file is located on a remote machine, the runtime must
locate and download the application configuration file first.
Checks whether the assembly name has been bound to before and, if so,
uses the previously loaded assembly. If a previous request to load the
assembly failed, the request is failed immediately without attempting
to load the assembly.
Checks the global assembly cache. If the assembly is found there, the
runtime uses this assembly.
Probes for the assembly using the following steps:
If configuration and publisher policy do not affect the original
reference and if the bind request was created using the
Assembly.LoadFrom method, the runtime checks for location hints.
If a codebase is found in the configuration files, the runtime checks
only this location. If this probe fails, the runtime determines that
the binding request failed and no other probing occurs.
Probes for the assembly using the heuristics described in the probing
section. If the assembly is not found after probing, the runtime
requests the Windows Installer to provide the assembly. This acts as
an install-on-demand feature.
Of course, this includes projects referenced by the assembly.
Edit to clarify the OP's comment:
As you may see on the output window on visual studio during the build process, you may notice that all referenced projects get build first. Later, the final names of their assemblies get added to the main executable and that is how is able to identify them. That last part is not visible on the output.
Below is a multifile assembly consisting of two managed modules, one with a manifest:
so RUT.netmodule(RUT stands for rare used types) is a file(.netmodule) that's part of the assembly.
Let's say my client application references a type from RUT.netmodule and MultiFileLibrary.dll is a strong name assembly and it is installed in GAC.
Because RUT.netmodule doesn't physically reside in MultiFileLibrary.dll, so GAC won't have RUT.netmodule.
so my question is, maybe CLR is configured to check application's base directory to look for RUT.netmodule after it knows that the referenced type is in a different module file. But it also means that RUT.netmodule have to always in application's base directory, which sounds strange to me as if I have mutiple applications then I need to have multiple RUT.netmodule in their base directory. Is a way to "install" RUT.netmodule in GAC or when MultiFileLibrary.dll is installed in GAC, any .netmodule files are also copied into GAC?
I have never working with multi-file assemblies but as far as I can tell you should be able to sign the .netmodule by using the assembly linker tool (al.exe).
The documentation contains a small quote which might be relevant:
How to: Sign an assembly with a strong name
...
By using the Assembly Linker (Al.exe) to link a .NET Framework code module (a .netmodule file) with a key file.
My guess is that even when you place the assembly in GAC it will still reference the .netmodule and it should work if the .netmodule is signed.
Hope this information helps you.
Suppose you have an assembly B that references A and you have the source code for the assembly A only. Is it possible to build from source code the assembly A and debug it?
Currently we get this error:
Could not load file or assembly 'name' or one of its dependencies. The
located assembly's manifest definition does not match the assembly
reference.
Is there any way to bypass it?
This will depend on if the original assembly A that is referenced is strongly named. This is a feature where assemblies are signed. Keys for all compile time references are stored in the built assembly, B in your case. When loading assemblies the loader may then verify the signatures of all references to ensure the correct assembly is loaded.
So if strong naming is used it is not easy to replace the assembly A with a newer version without recompiling B. There is however a strong name validation bypass feature for full trust application domains.
If you manage to bypass or disable the strong naming you should simply be able to replace the file in the directory with the new version and attach visual studio.
How can I load an assembly using its full display name from a location outside the application's bin path?
Usually one can load an assembly from a custom location with
Assembly.LoadFrom(path);
This works, but it seems that for loading a strong-named assembly I need to specify its full display name such as in
Assembly myDll =
Assembly.Load("myDll, Version=1.0.0.1, Culture=neutral, PublicKeyToken=9b35aa32c18d4fb1");
But the problem here is that this only references assemblies that are in my probing path of my application.
So what if I have an assembly dir1/asm.dll and one assembly dir2/asm.dll and both have a strong name.
How can I load them during runtime?
During Runtime, you can specify additional directories to probe when loading an assembly via the following methods:
AppDomain.CurrentDomain.ClearPrivatePath();
AppDomain.CurrentDomain.AppendPrivatePath();
When the subdirectory names are already known during installation, you can also specify these additional directories in the app.config file in the privatePath attribute of the <probing> element.
Make also sure the file name is correct. When you have
AppDomain.CurrentDomain.AppendPrivatePath("Subdir");
Assembly myDll = Assembly.Load("myDll, Version=1.0.0.1, Culture=neutral, PublicKeyToken=9b35aa32c18d4fb1");
then .net will look for a file named "mydll.dll" in the directory "Subdir" beneath the directory of the executable.
you can load any assembly from its location via loadfile (example here)
if you want to take multiple versions of an assembly consider handling the AppDomain.CurrentDomain.AssemblyResolve (example here)
the examples are from a small open source project, which will load dlls from a seperate a "packages" folder (allowing for packages to have their own copy of a dependency, using the isolated loader)
Can I configure a .NET application in a way (settings in Visual Studio) that it references a "local" assembly (not in GAC) instead of an assembly within the GAC, although both assemblies have the same name and the same version?
If both assemblies are strong-named (signed), the CLR will always load from the GAC.
Here are the steps the runtime uses to resolve assembly references (from How the Runtime Locates Assemblies):
Determines the correct assembly version by examining applicable
configuration files, including the
application configuration file,
publisher policy file, and machine
configuration file. If the
configuration file is located on a
remote machine, the runtime must
locate and download the application
configuration file first.
Checks whether the assembly name has been bound to before and, if so,
uses the previously loaded assembly.
If a previous request to load the
assembly failed, the request fails
immediately without attempting to load
the assembly.
Checks the global assembly cache. If the assembly is found there, the
runtime uses this assembly.
Probes for the assembly (... some material omitted ...)
As stated later in that same article:
There is no version checking for assemblies without strong names, nor does the runtime
check in the global assembly cache for assemblies without strong names.
So if you can afford to remove signing from the local assembly, the application will use it instead of the one in the GAC.
For more detail than you could probably ever want about the runtime-binding mechanisms, see Suzanne Cook's blog.
This blog entry from Scott Hanselman also provides a great overview of the binding process.
If you can change the version number of the local dll, you can use a dll version redirect using the oldVersion attribute. You can use a strong name for the local assembly:
Please look this page:
http://msdn.microsoft.com/en-us/library/7wd6ex19.aspx
Also you should consider that it is possible to modify the version number of a compiled assembly like it is described here:
Change Assembly Version in a compiled .NET assembly
You can use ilmerge and merged the assemblies into a single library to get around it.
To successfully deploy your .NET Framework application, you must understand how the common language runtime locates and binds to the assemblies that make up your application. By default, the runtime attempts to bind with the exact version of an assembly that the application was built with. This default behavior can be overridden by configuration file settings.
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).