VSVars for VS2005 and VS2008 Beta 2

Topics: Developer Forum, User Forum
Sep 4, 2007 at 3:06 PM
What is the best way to get things setup for running a PS Prompt configured for VS2008?

I have already taken the Environment.VisualStudio2008.ps1 file and modified it as appropriate for most of the VS 2008 information/reg key roots but I see several problems.

  • Right now the profile loads VS2005 by default. I either need to be able to conditionally load one of the VS environments based on 'something' and then use two different PS shell prompts or I need to be able to remove one profile and add the other. However, I don't see any mechanism for removing path elements. Am I missing something?
  • Need someway to differentiate beween which VS environment I am running. Typicly in the past it was background color, but right now Environment.VisualStudio2008.ps1 does not handle that. Should it?

Should the environments be run in a separate scope that could be exited and disposed of? I am not very familier with scopes so imagine lots of handwaving and general ignorance in the question.

Lots of other stuff I have probably missed. I just wanted to ask and get the issue out for discussion.

-mark

Coordinator
Sep 10, 2007 at 12:09 AM
Yep this is going to be an issue. I think we are going to look at how we the PSCX profile and offer options on which to include by default (or neither).
Coordinator
Sep 10, 2007 at 12:09 AM
This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.
Developer
Sep 12, 2007 at 8:37 PM
In 1.2, you can specify your preferred SKU+Version combination. There are the following settings:

The $Pscx.Preferences['VisualStudioSku'] contains an array of SKU names. Once we find an installed SKU, we look at the $Pscx.Preferences['VisualStudioVersion'] to determine which version to use. The final setting $Pscx.Preferences['MSBuildToolsVersion'] controls the choice of the MSBuild environment (ie. whether .NET 2.0 or 3.5 csc.exe and vbc.exe are used).

In the currently checked-in code, the Visual Studio 2008 and .NET 3.5 are preferred. I think people who have 2008 installed want to prefer them. And sane people (not me) don't install beta versions on production machines. Moreover, it will take some time yet to finish PSCX 1.2, so I think this is a good default.

What is not nice, there is no safe way of switching the environments once the profile has been loaded. I think a good solution would be to rewrite the path functions from BurtHarris as cmdlets, in such way that they would log what they are changing (on some stack stored in $Pscx), to be able to undo the changes. something like Push-EnvironmentBlock and Pop-EnvironmentBlock.... Any ideas?
Sep 12, 2007 at 10:38 PM


jachymko wrote:
In 1.2, you can specify your preferred SKU+Version combination. There are the following settings:

The $Pscx.Preferences['VisualStudioSku'] contains an array of SKU names. Once we find an installed SKU, we look at the $Pscx.Preferences['VisualStudioVersion'] to determine which version to use. The final setting $Pscx.Preferences['MSBuildToolsVersion'] controls the choice of the MSBuild environment (ie. whether .NET 2.0 or 3.5 csc.exe and vbc.exe are used).

In the currently checked-in code, the Visual Studio 2008 and .NET 3.5 are preferred. I think people who have 2008 installed want to prefer them. And sane people (not me) don't install beta versions on production machines. Moreover, it will take some time yet to finish PSCX 1.2, so I think this is a good default.

What is not nice, there is no safe way of switching the environments once the profile has been loaded. I think a good solution would be to rewrite the path functions from BurtHarris as cmdlets, in such way that they would log what they are changing (on some stack stored in $Pscx), to be able to undo the changes. something like Push-EnvironmentBlock and Pop-EnvironmentBlock.... Any ideas?

I would love to have the capability to push/pop an environmentl block and not just for VS. I have build scripts that tend to clutter up the environment for specific purposes and if i could limit those changes to the scripts, that would be really nice.

-mark
Developer
Sep 14, 2007 at 3:37 PM
Soooo, it's there:

Add-PathVariable was converted to a cmdlet. If there is a "environment stack frame" created by Push-EnvironmentBlock, it records the changes it is doing into it. You can undo them later using Pop-EnvironmentBlock. Environment.VisualStudio was moved to Scripts and is called Import-VSVars now. It does call Push-EnvironmentBlock before doing any changes (note to self: not everything is logged yet. I need a Set-PathVariable for variables like VSInstallDir etc)

It is called from the profile with the default preferences. You can see the usage below.

Few things: I am really unhappy with the names. If you can come up with better ones, I'd be really happy. Also, there is no clear connection between Import-VSVars and Pop-EnvironmentBlock. I am also considering replacing the "stack" with a hashtable. that way, you cold load and unload a set of variables as a whole. if you do any changes using add-pathvariable and then call pop, everything you made since the last push is removed.

Any thoughts?

[4] » Pop-EnvironmentBlock
[5] »
[5] » gcm devenv,csc
Get-Command : The term 'devenv' is not recognized as a cmdlet, function, operable program, or script file. Verify the term and try again.
At line:1 char:4
+ gcm <<<<  devenv,csc
Get-Command : The term 'csc' is not recognized as a cmdlet, function, operable program, or script file. Verify the term and try again.
At line:1 char:4
+ gcm <<<<  devenv,csc
[6] »
[6] »
[6] » import-vsvars visualstudio 8.0 2.0
[7] » gcm devenv,csc
 
CommandType     Name                                                               Definition
-----------     ----                                                               ----------
Application     csc.exe                                                            C:\Windows\Microsoft.NET\Framework\v2.0.50727\csc.exe
Application     devenv.com                                                         C:\Program Files (x86)\Microsoft Visual Studio 8\Common7\IDE\de...
Application     devenv.exe                                                         C:\Program Files (x86)\Microsoft Visual Studio 8\Common7\IDE\de...
 
 
[8] » Pop-EnvironmentBlock
[9] »
[9] » import-vsvars visualstudio 9.0 3.5
[10] » gcm devenv,csc
 
CommandType     Name                                                               Definition
-----------     ----                                                               ----------
Application     csc.exe                                                            C:\Windows\Microsoft.NET\Framework\v3.5\csc.exe
Application     csc.exe                                                            C:\Windows\Microsoft.NET\Framework\v2.0.50727\csc.exe
Application     devenv.com                                                         C:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\IDE\...
Application     devenv.exe                                                         C:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\IDE\...
 
 
[11] » csc
Microsoft (R) Visual C# 2008 Compiler Beta 2 version 3.05.20706
for Microsoft (R) .NET Framework version 3.5
Copyright (C) Microsoft Corporation. All rights reserved.
 
fatal error CS2008: No inputs specified
[12] »
Coordinator
Sep 15, 2007 at 6:02 PM
I really like were you are going with this. I was just thinking the other day that we had too many functions and that some of those should be ported to cmdlets. I really like the idea that Add-PathVariable and Push/Pop-EnvBlock. As for the association between Push/Pop and Import-VSVars, it would be nice to have push/pop/set/append-Environment cmdlets. BTW is using EnvironmentBlock too techy? I know that it is technically called that but could we get away with Push-Environment or Push-Env or Push-EnvBlock? Just thinking out loud. :-) Anyway back push/pop/set/append. With these cmdlets you append to the current environment ie any prexisting variables get the new values appended to them using ';' as a separator. Set would complete reconfigure the environment to reflect exactly the env passed to it.

As for input, I like the hashtable idea. I would like to be able to do this:

 
[13] Push-Env $Pscx.Env.VisualStudio2005
[14] Pop-Env
[15] Push-Env $Pscx.Env.VisualStudio2008

Where $Pscx.Env.VisualStudio* are just two hashtables. Although there is a question here as to whether or not Push-Env would 'append' the specified hashtable or do the equivalent of a "set the environment - replacing everything else". I guess you could do this:

[16] Append-Env $Pscx.Env.VisualStudio2005
[17] Push-Env
[18]...
[19] Pop-Env

or perhaps just a switch parameter to Push-Env to do the equivant of "replace the entire env with this new one" which is quite a bit more dangerous I think:

 
[13] Push-Env $MySpecialEnv -Replace (or -Set)
[14] Pop-Env
[15] Push-Env $Pscx.Env.VisualStudio2008 # this would just append

Sorry for these ramblings, but I really do like this idea.