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 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…