I like being able to build projects and solutions from the command line. That is easy enough to do from a “Developer Command Prompt”, as that sets up all the necessary environment variables (via vsvars32.bat).
However, I have long preferred TakeCommand/TCC to cmd.exe, so I created a .bat file for TakeCommand that called vsvars32 (if necessary), then launched MSBuild with the appropriate command line. The .bat allowed certain parameters – Config and Target – to be set. Unfortunately, if you set one, you had to set them all.
I wanted the same functionality in PowerShell, and thought I would have to translate vsvars32.bat to a .ps1 file. Naturally, someone has already done that. Even better, someone created a way to run a .bat file, extract the resulting environment vars to a temp file, and set those environment vars in the PowerShell session. Much better – no having to keep a .ps1 in sync with a .bat!
With the power of PowerShell named params and default values, it is easy to create flexible functions that don’t rely on the position of a parameter for its meaning.
Here is the basic help:
[master +1 ~0 -1 !] > get-help Build-Solution
Build-Solution [-Proj] <string> [[-Config] <string>] [[-Target] <string>]
The Config var defaults to “Debug”, and the Target var defaults to “Build”.
> bld12 gloogle.sln
> bld12 flankle.sln –Target REBUILD
msbld12 depends on Invoke-CmdScript. Download the attached files and rename to *.ps1.
A number of years ago I started a new job at a software company. A colleague walked me through the email system, network layout, and other infrastructure. He explained how Brief was the standard editor, and was set up so everyone had a local config file that pointed to the common config file on the network. The common config set up the necessary drive mappings, file shares, etc. No matter what computer you logged in to, Brief was set up correctly based on your user id.
I thought of that as I find myself using SkyDrive more and more to share my own config files, script files, utilities, and other junk I want available on various computers. It is very nice having _vimrc and my PowerShell profile always synchronized across computers, while being able to easily add computer-specific changes.
My local PowerShell profile can be identical on all computers that have a _skydrive environment variable pointing to the local SkyDrive dir:
# Load the common profile, shared via SkyDrive
# Machine-specific pieces here…
# Load posh-git example profile
Visual Studio 2013 is doing this, now, too. Not only does VS2013 save information in the user’s profile, but VSCommands 12 saves a whole bunch of options.
Save to a local dir sync’d with SkyDrive, DropBox, or any one of similar services, and your VS2013 experience can be consistent across computers.
The Package Manager Console is an instance of PowerShell in a tool window.
You can get your full PowerShell environment by manually running your startup script:
> cd $env:Home\Documents\WindowsPowerShell # you may need to use $env:USERPROFILE
> . Microsoft.PowerShell_profile.ps1
(Of course, use the name of your startup script…)
I use posh-git with PowrShell, and now I have that in VS2013:
(I suspect this would work in VS2012, but I haven’t tried it.)
UPDATE: To load your startup script automatically, you need to find the script that the Package Manager Console first loads. I found a file named “Profile.ps1” in “C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\Extensions\t15jiici.0ox\Modules\NuGet”.
In Profile.ps1, I added:
For many years I used CodeWright, and then SlickEdit, for all my editing. Both of those had a very useful feature: Save Files on loss of focus.
As Visual Studio improved, I started using it more and more, and missed that autosave feature. So, a few years ago, I wrote an AddIn for VisualStudio 2010 that saved all changed documents when VS lost focus.
I kept that AddIn up-to-date for VS2012 and VS2013, but read recently that AddIn support would be going away, and VSPackages was the way to enhance and extend VS.
Converting the AddIn to a VSPackage was pretty straightforward, except for one problem: the autosave functionality didn’t work initially. I found that this appears to be a difference in AddIn load behavior vs. VSPackage load behavior. AddIns are initialized on load, while VSPackages are only initialized when certain conditions exist. (This is done to minimize VS startup time by preventing all the extensions from trying to load at once.)
The load behavior is controlled by attributes decorating the class that extends Package. I added the attributes for UIContext_EmptySolution and UIContext_SolutionExists, and the extension works as desired. See this post for details in installing the extension.
(Note that you can get the same behavior in vim by adding this to your _vimrc:
‘ Save all files when gvim loses focus
au FocusLost * wa
“au” is the abbreviation for autocmd, and FocusLost is the name of the event to trigger it.
Similarly, setting autowrite saves changes when you switch buffers (:bn, for example).)
This is the re-emergence of the cbates.net web site.
Have a look around, leave a comment…