App.config Examples


Below are three examples of useful application configuration files.



  1. Forces the v1.0 CLR to be run. If the v1.0 CLR is not installed, the app will fail to run.

    <?xml version =”1.0″?>
     <configuration>
        <startup>
             <requiredRuntime version=”v1.0.3705″/>
             <supportedRuntime version=”v1.0.3705″/>
         </startup>
     </configuration>


  2. Redirects “assemblyName, Version=1.0.0.0, Culture=neutral, PublicKeyToken=25283151a234958d“ to version 2.0.0.0 of that assembly. This is only useful for strongly-named assemblies, since versions don’t matter for those that are simply-named.

    <?xml version =”1.0″?>
    <configuration>
    <runtime>


            <assemblyBinding xmlns=”urn:schemas-microsoft-com:asm.v1″>


                    <dependentAssembly>
                            <assemblyIdentity name=”assemblyName” culture=”” publicKeyToken=”25283151a234958d”/>
                            <bindingRedirect oldVersion=”1.0.0.0″ newVersion=”2.0.0.0″/>


                    </dependentAssembly>
            </assemblyBinding>


    </runtime>
    </configuration>


  3. Redirects “assemblyName, Version=1.0.0.0, Culture=neutral, PublicKeyToken=8968ee41e78ce97a“ to codebase “http://www.yourwebsite.com/filename.dll“. ‘Href’ can also be set to something like “file:///c:/localfile/filename.dll“. Note that redirecting to a codebase causes a System.Net.WebPermission or System.IO.FileIOPermissionAccess.Read + PathDiscovery demand when loading that assembly.

    <?xml version =”1.0″?>
    <configuration>
    <runtime>


            <assemblyBinding xmlns=”urn:schemas-microsoft-com:asm.v1″>


                    <dependentAssembly>
                            <assemblyIdentity name=”assemblyName” culture=”” publicKeyToken=”8968ee41e78ce97a”/>
                            <codeBase version=”1.0.0.0″ href=”http://www.yourwebsite.com/filename.dll”/>


                    </dependentAssembly>
            </assemblyBinding>


    </runtime>
    </configuration>


    Comments (25)

    1. Take Outs for 14 May 2004

    2. David Levine says:

      Suzanne,

      Is there a way to use application configuration files with different binding redirects on a per-appdomain basis? I would like to have a managed app host multiple appdomains, each with a different environment.

      Thanks for any help.

    3. Suzanne says:

      Yes, see the ‘App.Config Files’ link in this blog entry.

    4. yoohoo says:

      very helpful hints Suzanne. thank you very much

    5. Ali says:

      That is invaluable insight. It really helped. Thanks a lot!!!!!!!!

    6. Patrick says:

      Thanks for a simple and direct sample of redirection.

    7. I changed app.config while the application is running. But the application does not read the change, unless I restart the application. What should I do?

    8. James Moore says:

      Will this solution work for assemblies that are registered in the GAC? would oyu have to register App.config?  and what if the app uses Machine.config instead of App.config

    9. Mike Nacey says:

      Do you have any idea why a codebase href of:

      file:///../../myassembly.dll

      would not work?

      Thanks.

    10. alevi says:

      Can you please let us know about machine.config tag details???

    11. I typically recommend that you build and test your assemblies against the same version of .NET that you

    12. Pre-v2, when you load an assembly by path through Fusion (LoadFrom(), ExecuteAssembly(), etc.), it can

    13. By default, the application configuration file of the default appdomain (and other appdomains for v1.1

    14. E.Palus says:

      We have an unmanaged app that is loading a .NET assembly through interop wrappers.  This loaded assembly uses another .NET assembly that requires settings from the app.config. Can we configure the required settings in the unmanged app.config file?    

    15. Jonathan Gilbert says:

      Is there any way to do this at run-time? I’ll keep searching, but this thread seems very on-topic. Basically, what I’m hoping to do, if it is possible, is have a compile-time reference to a DLL in another project, but not deploy that DLL with the build output. Instead, after firing up, the program needs to determine the location of the DLL by other means and have it be loaded from there. Just using strong names and GACcing the dependency isn’t an option at this point, unfortunately.

    16. Caleb Dougherty says:

      Hi Suzanne,

      I have a simple versioning issue that I cannot seem to resolve after searching the net for a day or so.

      Perhaps you could help.

      I have a program (X) that accesses an interface in another program (Y) using .NET remoting.

      Say I built my program with version 1.3.4.0 of the dll containing the interface.

      The version number of the DLL updates with each build of the Y software, but the functionality does not change.  I also don’t know what future versions will be.

      How would I go about telling my program to always use the assembly from the remote program/server?  

      I’ve tried using some app.config settings as you suggest in this post, but no luck.

      Is what I’m trying to do even possible?

      Thanks,

      Caleb

    Skip to main content