Visual Studio 2008 does not resolve environment variables in *.refresh files - by Don Perkins

Status : 

  By Design<br /><br />
		The product team believes this item works according to its intended design.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.

Sign in
to vote
ID 456292 Comments
Status Closed Workarounds
Type Bug Repros 0
Opened 5/22/2009 9:14:01 AM
Access Restriction Public


We have an (admittedly bad) requirement to reference assemblies in the C:\Program Files\... folder in a web application as part of our build.  We have .refresh files in place to copy those assemblies into our project.

The problem is that one of our developers has his Windows installed to the E:\ drive.  On his sysetm the relative path, of course breaks.  We tried using the %PROGRAMFILES% environment variable, but VS9 apparently does not resolve environment variables in .refresh files.

It's hard to say if this is a bug or an enhancement, since there is no documentation stating that environment variables will work, but it is a common expectation that they would.
Sign in to post a comment.
Posted by Don Perkins on 6/23/2009 at 1:04 PM
Thanks, Chuck!

Sorry for confusing the issue -- I wasn't aware of the difference. This project was started seven years ago when there was no such thing as an "ASP.NET Web Application" (and five years before I started working in the product and took on the team lead position.)

I will definitely look into converting it over to a web application -- that should make life easier in a number of other ways, I'm sure.
Posted by Microsoft on 6/22/2009 at 9:26 PM
Sorry for the confusion. So, you are using an "ASP.Net Web Site". I thought you were using a "ASP.Net Web Application". The later was added first as an add-on in VS 2005, and then later was made part of the product in VS 2008. It uses traditional project files and is managed like the other C#/VB project file types.

I should have known that, as it is the one that uses .refresh files. Unfortunatley, the answer is really the same. Since MSBuild is not used, the .refresh file has no mechanism means of using environment variables or other. One of the other suggestions of mapping to a local drive using a drive letter will allow you to work around the issue.

I would recommend that you upgrade your projects to "ASP.Net Application" project types. This would give you much more control on your project, and it operates like the other project types. To create this type of project, is a bit misleading. You select New Project from the File menu (instead of New Web Site). Then choose the project template under the "Web" tab. I think from memory it is called "ASP.Net Application". This has the advantage of giving you and MSBuild project file and a folder based web project.

For more information, check out this article:

Chuck England
Visual Studio Platform
Program Manager - MSBuild

Posted by Don Perkins on 6/22/2009 at 7:41 AM

It may have gotten lost in translation somewhere, but, as I stated, this is in reference to a "Web Project", which has no option to unload from a solution -- and also does not have a project file to edit!

Also, while I didn't state this directly, my attempt to use %PROGRAMFILES% was by directly editing the contents of the .refresh files after they had been created by the "Add..." dialog.

For the time being, I have changed my .refresh files in the web project to use the concrete path "C:\Program Files\..." which works with our current team. But we have a contractor that we use from time to time whose Windows boot drive is on "D:". Hopefully we won't be needing him on this project for some time.
Posted by Microsoft on 6/20/2009 at 1:37 PM
Hi Don,

Thanks for taking the time to report this to us.

The Add Reference dialog box Browse tab does uses the standard file open dialog. When you add the reference to the project, that dialog (which does understand the %ProgramFiles% environment variable) resolves the file and returns the full path of the selected file. So, we really have no way to know you actually entered the environment variable.

However, I think you can still get what you want to work. After adding the reference, right click on the project, and click "Unload Project". If prompted to save, answer Yes. Next, right click on the project node again and select the "Edit {Projectname}" menu (where {Projectname} is the name of your project) In the XML of the project file, locate the reference you added. It will be a <Referenece/> element with the "Include" attribute equal to your assembly you included. You should see a sub element <HintPath/> with a path to the DLL. It will be most likley a relative path. But, you should see something like "..\..\..\Program Files\MyFolder\MyReference.dll". Now, replace the portion of the string (not including the quotes) "..\..\..\Program Files" with "$(ProgramFiles)". (Note: MSBuild properties are given with the syntax $(name). And environment variables are pulled in automatically as properties. So, $(ProgramFiles) is the environment variable %PROGRAMFILES%.) Now save and right click on the project file and say "Reload Project". This should now resolve correctly on both machines.

There are other ways you can resolve this as well. Once way of doing this is to create a common drive letter or network path which all users can reference. If you are referencing third party assemblies, it is better to copy them into a known location in source control and everyone reference the same copy. Otherwise, if I install a new version of the program on my machine, I might get a different build or results from another dev on the team.

To create a common drive letter, you could share a path off of a network server. You could have everyone share a folder on their drive under the enlistment and then actually connect back to their own share as a drive letter. Note the share can now be anywhere, but the drive letter would point to the same thing on all machines. (Command lines for these are NET SHARE and NET USE) You could also use the SUBST command (looks something like
SUBST U: \\mymachine\myshare\mylocation
Where the U:\ drive becomes known location. (Note you can use \\localhost to reference yourself on all machines for a common script.)

Lastly, Windows NTFS also supports Junctions and Links that would allow you to do very similar mappings.

I hope this information is helpful to you.

I am going to resolve this issue as "By Design". If you have any more questions, feel free to post back to this issue.

Chuck England
Visual Studio Platform
Program Manager - MSBuild
Posted by Microsoft on 5/25/2009 at 1:50 AM
Thanks for your feedback.

We are escalating this issue to the appropriate group within the Visual Studio Product Team for triage and resolution. These specialized experts will follow-up with your issue.

Thank you,
Visual Studio Product Team
Posted by Don Perkins on 5/22/2009 at 9:17 AM
Off topic: This was submitted by Don Perkins. "Cold Justice" is my Gamertag. I'm not sure why the system pulled that instead of my real name when submitting this issue.