Aspnet.Config


Jamie asks about what is aspnet.config.

Alan has a detailed discussion on binding policies.

http://blogs.gotdotnet.com/alanshi/commentview.aspx/d4edb084-c625-4b6e-8e5c-7c2580cfcee9

And aspnet.config is what Alan described as Host Policy.

I don’t really see why you need host policy. In fact, I successfully convinced Asp.Net team to remove this policy in Whidbey. If you have a Whidbey beta1 redist install, you will see aspnet.config is gone.

Comments (5)

  1. Hi Junfeng,

    I remember reading that post. Thanks for linking to it again. I couldn’t find it when I tried searching for it.

    Unfortunately Alan doesn’t say any more about it than this.

    "The last policy mechanism is known as host policy , and is intended to be used by hosting processes such as ASP.NET to inject their own policy behaviour."

    I tried asking at the PDC but couldn’t find anyone who knew about it (even at the Hosting the CLR session!). It sounds like it may be a bit of a DEVPATH [1], but I’d still like to know about it. 😉

    http://blogs.msdn.com/suzcook/archive/2003/08/15/57238.aspx

  2. It is just yet another binding policy, as simple as that:)

    So really the binding policy system works like following:

    App.config->Publisher Policy->Host config->Machine.config.

    The idea was that maybe there are some host specific assemblies that the host wants to guarantee that specific versions are loaded, regardless of what app.config and publisher policy says.

    For example, in Asp.Net cases, they have to load the version of System.Web.dll that are compatible with their isapi filter. So they have this aspnet.config, which redirects every references of System.Web.dll to the one shipped in framework directory.

    But in reality this is never useful. Nobody redirect System.Web. This is why I convined Asp.Net team to remove this policy.

  3. I was thinking being able to set the CodeBase for a number of assemblies could be useful. You get the same advantages as putting assemblies in the GAC, without actually putting them in the GAC. This can be useful when testing an application that will have a few assemblies in the GAC when deployed.

    A problem I’m hitting at the moment is crossing crossing from one app domain into another with a different application base. If you try using the LoadFrom context you risk being trumped an assembly with the same name in the Load context. In this case the AssemblyResolve event won’t save you and you always end up with an exception.

    In this case it seems the only option is to create a config file that sets a CodeBase for every app domain crossing assembly. This is anoying if your spawned app domains use config files already. I’m relectant to put assemblies in the GAC that will only be used by one application. App domain crossing in a single application seems like a bad reason to break xcopy deployment.

    This is why I’m interested in Host config. I could put my app domain crossing assemblies in there without breaking xcopy deployment. The question is how to create an application that uses a Host config file.

  4. In .Net one AppDomain represents one application. So if you have multiple AppDomains with different application bases, the assembly is shared between multiple applications. It is not unreasonable to put it in GAC.

    For your scenario, most likely those assemblies you want to share belong to the host. Since they are strongly named(otherwise you can’t share them), it is very unlikely that other applications will carry them. If they do, you can say this is unsupported. With this in mind, it is not a bad choice to use Assembly.LoadFrom.

    Of course you can also try Assembly.LoadFile or Assembly.Load(byte[]), but you must handle the dependencies yourself.

    I don’t want people to use host policy, is because host policy overwrites publisher policy. If someone ships a security patch with publisher policy, you don’t want to overwrite the publisher policy.