Powershell
Automatically finding missing and duplicate files in CSProj (Revisited)
As promised in I have come back to the problem of detecting errors in Visual Studio project files. I have updated the script to now report CS files that are on disk that do not appear in the list of included (and compiled) files in the Project. This has a few limitations, including that it only works with CS files (although the script could be easily amended to look for any file extension you like).
Keeping your Powershell profiles and functions synchronised between computers
If you’re like me and you use Powershell on a regular basis, you probably have a load of functions set up in your profile.ps1 file so that they get loaded when you start a new session. The moment you start doing this, there’s the constant problem in the background of how to keep this in sync between different computers. I will often be fooling around with some new technology at home and will come up with a super-useful Powershell command, and will then need it at work as well.
I solved this problem with use of Dropbox (you could use any other file syncing app you like, such as Skydrive (or even a network share), the only prerequisite is that it supports symbolic links).
- If you haven’t already, separate your Powershell functions into distinct files, and have them all be loaded by your profile.ps1, which acts as a bootstrapper. Your profile will look something like this:
$scriptFiles = gci "$home\Documents\WindowsPowerShell\*.ps1" -Exclude "profile.ps1" foreach ($scriptFile in $scriptFiles) { . "$($scriptFile.PSPath)" | out-null }Once you’ve accomplished this, you need to create the symbolic link. Open the command prompt and cd into your My Documents folder. If you already have a directory called WindowsPowershell in there, you’ll need to delete it, copying all the files within into your new directory in Dropbox. The command you need to run is this:
mklink /D WindowsPowershell <dropboxPowershellDir>
where <dropboxPowershellDir> is the full path to the directory of scripts in your Dropbox folder. Et voilà, you now have a Powershell profile that synchronises between computers!
Ensuring you get the CLR version you want when remoting in Powershell
This is an issue I ran into recently when trying to run some of our regular Powershell scripts recently – they were the same scripts we’d always run but now we were trying to run them remotely (instead of making a person log in over RDP and run a batch file. Very high-tech, I know.) but we were running into an issue to do with the CLR version that gets loaded with your Powershell session.
We’re using our own binaries (written in C#) in our Powershell scripts, and we need v4 of the CLR loaded to get them to run. Normally v2 is what you get, but we found that you can edit the file $pshome\powershell.exe.config with the contents:
<?xml version="1.0"?>
<configuration>
<startup useLegacyV2RuntimeActivationPolicy="true">
<supportedRuntime version="v4.0.30319"/>
<supportedRuntime version="v2.0.50727"/>
</startup>
</configuration>
This caused v4 of the CLR to be loaded, but only when you run Powershell locally. If you want to do the same when you remote into the machine, it doesn’t work.
I couldn’t find any documentation on this, but thanks to some nice people on StackOverflow I now have the answer. The configuration file contents above are still what you need, but you need to put them in another file. Two other files actually, if you’re on 64-bit. The files you need are located at c:\windows\System32\wsmprovhost.exe.config file and c:\windows\SysWOW64\wsmprovhost.exe.config.
That should be all you need!
Richiban 