Assembly.CodeBase vs. Assembly.Location


The CodeBase is a URL to the place where the file was found, while the Location is the path from where it was actually loaded. For example, if the assembly was downloaded from the internet, its CodeBase may start with “http://”, but its Location may start with “C:\”. If the file was shadow copied, the Location would be the path to the copy of the file in the shadow-copy dir.


It’s also good to know that the CodeBase is not guaranteed to be set for assemblies in the GAC. Location will always be set for assemblies loaded from disk, however.

Comments (7)

  1. Suzanne, I have built a smart Web Services proxy lib that generates WS proxies at runtime. And I have implemented a basic caching mechanism in which I store these assemblies on disk. For naming those I chose to give them the name of the URLEncoded WSDL URL. But when I try to load the assembly from disk (LoadFrom) I get an error – the CodeBase property could not be set. When I choose to use an MD5 hash value of the URL everything is fine …
    Any insights here?

    Thanks and cheers,
    Christian

  2. Suzanne says:

    The LoadFrom() call is throwing an exception, then? What was the type of the exception and its message? So far, it sounds like an invalid name problem – what was the exact assembly name, and the URL passed to LoadFrom()?

  3. Phil says:

    Lets say that I have an assembly that reads in config settings from a configuration file and shadow copying is enabled. The class that uses the configuration file assumes that the file is in the same directory as the assembly, which in this case would be the location where the assembly was shadow copied. Since the shadow copy process only copies the file that the assembly is in and not any external files (such as the config file), how can I make sure that the config file is copied along with the assembly file, when shadow copying is enabled. I could have the class read in the config file location from a registry key, but that is so 1997….

  4. Suzanne says:

    If this is regarding the app.config for the appdomain: the AppDomain could be set up in such a way that shadow-copying a local config file would be unnecessary (AppDomainSetup.ConfigurationFile could be set its location, or it could be the process exe’s config file for the default case.) Then, your assembly could just get that appdomain’s ConfigurationFile property.

    If this is a per-assembly config file, it could be included in that assembly as a non-manifest-containing module of a multi-file assembly. Then, it would be shadow-copied with the assembly. (An easy way to make your compiler emit this is to make it a linked ManifestResource.)

  5. Peter says:

    Is it possible to tell if the calling assembly is a Webforms app or console app, or a web application?

    I’m thinking in terms of a class that accesses things such as the local machines sound api’s.

    Obviously we wouldn’t want want web apps to access this class.

    Many thanks for your help

  6. Gauls says:

    Hi,

    I have webservice application that uses some assemblies whoes version number keeps changing and are stored in some folder on the same machine as my webservice. Every Time the assembly version changes i need to change the binding redirect and code base in the web.config file.  

    EX :

    <dependentAssembly>

    <assemblyIdentity name=”ABCD” publicKeyToken=”Sometoken” culture=”neutral” />

    <bindingRedirect oldVersion=”1.0.0.0-99999.99999.99999.99999″ newVersion=”1.0.1445.38584″ />

    <codeBase version=”1.0.1445.38584″ href=”file:///C:Program FilesTPAABCD.dll” />

    </dependentAssembly>

    Updating the web.config file is done when a particular webmethod is called. This thing works in development time,  because the version number in the config was same as the actual assembly, In production system this doesn’t not work as the assembly version is different then config file and gives internal Error 500.

    I tired restarting IIS and deleting the web service Application folder from

    C:WINDOWSMicrosoft.NETFrameworkv1.1.4322Temporary ASP.NET Files

    Nothing worked 🙁

    1. What happens onces the webmethod is called , the webservices loads the assemblies based on the config file?

    2. Reinstalling the webservice seems the only current solution to update the config file. In what other way can i update the config file?

    Many Thanks,

    Regards

    Gauls

  7. Nick Papatonis says:

    Suzanne,

    Way back in 2003 you made a response to someone that included the following…

    If this is a per-assembly config file, it could be included in that assembly as a non-manifest-containing module of a multi-file assembly. Then, it would be shadow-copied with the assembly. (An easy way to make your compiler emit this is to make it a linked ManifestResource.)

    My situation is the following…

    I have a class library project containing my business logic that is shared between various applications, including an ASP.NET web app.  The BL has numerous configuration settings that I chose to store in a config file within the business logic project.  This results in a bl.dll file and a bl.dll.config file in my output folder.  The main reason for structuring things this way is to avoid replicating the BL settings into the config files for each hosting application.

    Within the BL code, I use OpenMappedExeConfiguration to open the BL config file.  The mapped config file name is constructed by using the executing assembly’s Location property with “.config” concatenated at the end.  This approach works fine for applications other than the web application.  The web app is presenting some interesting differences.  First, the bl.dll file is deployed to the web site’s bin folder, but the bl.dll.config file is not.  In addition, the executing assembly’s Location property is pointing to a shadow copy of the bl.dll file.

    So, I have a two part question.  What is the best way to get the bl.dll.config file deployed to the web site’s bin folder in the first place?  And, how do I ensure that it is shadow copied to the temp folder for execution?  This second part is not crucial.  If it’s a lot of effort to cause the config file to be shadow copied, I could use the executing assembly’s CodeBase property to construct the config file path, assuming the config file got deployed properly.

    It sounds like your suggestion from 2003 is what I’ve been searching for, but I don’t quite understand how to implemement what you’re suggesting.  Could you please provide more detailed instruction on how to accomplish this or, possibly, refer me to any help/forums/blogs that will guide me through this?

Skip to main content