Avoid DevPath
Also see: Web Access for Visual Studio Team System
I hesitate to talk about this because I don’t want people who don’t know about it to think, “Hey, what’s this DevPath thing? I need that.” But, maybe if I don’t explain how to use it, it will be too much effort for people who don’t already know how.
(And, for those who already know how and are, in fact, using it, hopefully, they’ll see this and get off that plan.)
The intent of DevPath was to make the development environment less painful. Assemblies could be put there and bound to at runtime, ignoring the assembly version and overriding the GAC.
It turns out that that’s badness for several reasons (below). So, DevPath is soon to be deprecated. Don’t use it - not even in the development environment.
Why It Should Never Be Used
Versioning alone is why you should never, ever use it in a production environment. It subscribes your users to dll hell. See Avoid Partial Binds for details (DevPath causes partial binding, since the version is ignored for the bind).
It’s not good for the dev. env., either - it makes it unnecessarily different from the shipping env., which may lead to uncaught versioning or deployment bugs in the shipping env.
What to Do Instead
If DevPath was a development environment-only solution for you:
I strongly recommend not changing your assembly versions between non-shipping builds instead of using DevPath.
If you are shipping code relying on DevPath:
One thing you could do is create a new AppDomain with the ApplicationBase set to the path you care about. Once you do that, see Executing Code in Another Appdomain.
If there are multiple paths you want to load assemblies from, use PrivateBinPath or mu
Also see: When Are Two Algorithms the Same?
Also see: Interested in Artificial Intelligence? What about Wiki’s? Well, now you can have both.
Also see: Snippet Compiler update
Also see: C# 3.0 Lambdas and Type Inference
Also see: From C# to Java: Part 3
Also see: Startup, Shutdown and related matters
Also see: Microformats are like RFID tags for the Web
Also see: Debugging an InvalidCastException
ltiple AppDomains. If that’s not reasonable for you, consider using the LoadFrom context.http://blogs.msdn.com/suzcook/archive/2003/08/15/avoid-devpath.aspx
