AppDomainSetup.DisallowApplicationBaseProbing
AppDomainSetup.DisallowApplicationBaseProbing is a new property we introduced in .Net framework 2.0 to control assembly probing.
When this flag is set, the probing behavior is as following:
1. We will still probe GAC for strongly named assemblies
2. We will NOT probe application base, include privateBinPath if set.
3. For dependencies of Assembly.LoadFrom(), we will NOT probe application base, but we will probe the parent's directory.
Who is the client of this probing behavior?
If you know that none of your assemblies live in application base, and you only returns assemblies to CLR loader through AssemblyResolve event, then this is for you.
This is so that you can avoid the perf hit of probing when you are sure that your assemblies can't be found in application base.
Comments
- Anonymous
August 02, 2004
Can you add event BeforeAssemblyResolve ?
This would help a lot. - Anonymous
August 02, 2004
How would this help? - Anonymous
August 03, 2004
I would be able to decide whether I would want to continue with the regular probing. - Anonymous
August 03, 2004
Dmitriy,
You mean, the event will fire after we probed GAC, and before we probe application base?
This is an interesting suggestion. But exactly how will you decide whether to continue with regular probing? - Anonymous
August 03, 2004
- I have a name pattern for assemblies that need to have a different location.
2. I have a configuration file that list the assemblies that require special handling.
This addition will make a huge difference to us. If it is possible to add this into the schedule we can talk off the blog.
dmitriy.zaslavskiy at morganstanley dot com
- Anonymous
August 03, 2004
You can achieve the same thing by hooking up AssemblyResolve event.
If you like us to probe, then you do nothing and just handle missing stuff in AssemblyResolve event.
If you don't like us to probe, set this flag and handle everything yourself in AssemblyResolve event.
It is much harder to do partial probing, like probe for this assembly but not for the other. We have some semantics we want to guarantee. Having the application interrup every binding makes it almost impossible to maintain a consistent semantics. This clearly a direction we want to move away, given the caching binding failures breaking change. Thus I don't see the possibility of add this, even beyond 2.0.
In any case, if you want to keep the discussion, please use the contact link in the left top size of this page.