Avoid DevPath
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.
Comments
- Anonymous
August 16, 2003
Suzanne hi,great blog...I tried to use devpath in 1.0 but didn't succeed , I even posted this on the newsgroups but no one answered,how do enable devpath?I disagree with you on the "Why It Should Never Be Used"I think it should never be used on the QA machines, and that way you'll avoid deploying devpath enabled programs and get into an un familiar environment when you go production.did mean that devpath will no longer exist in whidbey? - Anonymous
August 18, 2003
I agree with Suzanne on this, it's too easy to get into trouble with DEVPATH and I've always avoided using it for that reason. I can see why it's useful during development as a time-saver, but ultimately I don't think it's good pratice.Wrt enabling DEVPATH, what did you try? AFAIK if the environment variable is correctly set then you just need a config file with developerInstallation set to "true".Deprecated means that it will be removed in a "future" version, although typically this translates to the next major release after it has been deprecated. I would guess that if it is being deprecated in v2 then it will be removed in v3, although I could be wrong. - Anonymous
August 18, 2003
The comment has been removed - Anonymous
August 18, 2003
The comment has been removed - Anonymous
August 19, 2003
Great Blog.But it is a problem with .Net that this assembly / version documentation is scattered in blogs and news groups. It is obviously too subtle for technical writers to understand.It would be really wonderful to have this information gathered together in one, (farily large), serious document. How does this versioning really work?The best I've found is Jeffrey Richter's book, and that is only superficial.Anthony - Anonymous
August 19, 2003
Thanks, Anthony. There are articles in MSDN which cover this (search for "version", for example). But, it's hard to cover everything in just one article. Usually, they take one viewpoint, and cover the interesting information from that viewpoint. For example, if someone is new to .NET, they're probably not ready for the nitty-gritty details about special cases in something they don't need to use. - Anonymous
October 28, 2003
The comment has been removed - Anonymous
November 08, 2003
From what I can tell from your description, it sounds like you are changing your assembly versions for each build. You can avoid the problems you describe by not doing that - only change after each shipping (non-development) version. See http://blogs.msdn.com/suzcook/archive/2003/05/29/57148.aspx for more information. - Anonymous
March 23, 2004
The comment has been removed - Anonymous
April 27, 2004
I was humored to see that when you search on "devpath" in Google it makes the suggested correction:
Did you mean: death - Anonymous
July 13, 2004
The comment has been removed - Anonymous
July 13, 2004
The comment has been removed - Anonymous
June 12, 2006
this blog posions the mind of people who don't realize that suzanne cook doesnt know what she's talking about.
for better info on devpath, i suggest reading
http://blogs.msdn.com/junfeng/archive/2005/12/13/503059.aspx
particularly the comment that says
"
At the time of her blog, we briefly considered deprecating DEVPATH, and replace it with something else. The decision was reverted and we fully support DEVPATH in development mode.
The ultimate authority is MSDN. If MSDN does not say it is deprecated, it is not deprecated. " - Anonymous
June 12, 2006
'John' (I presume that's not your real name): That blog entry was correct at the time I wrote it (in 2003). However, it is true that plans can change over time. Note that the blog entry you gave does not dispute the reasons I gave against the use of DevPath (other than because it was on the chopping block). For those reasons, I still consider it better to deprecate it if the breaking change committee will allow it (apparently, it may not).
Kevin: Like I suggested in my original entry, for your case, I recommend not changing your assembly versions between non-shipping builds instead of using DevPath. That avoids having to update .configs while avoiding the disadvantages of DevPath.