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 multiple AppDomains. If that’s not reasonable for you, consider using the LoadFrom context.