Have I ever mentioned how much I love the community? Today Kirill Osenkov posted a comment on the blog pointing out that there was an API to get the .NET Framework install path: RuntimeEnvironment.GetRuntimeDirectory() . I didn’ t know that and now I do. \ud83d\ude42<\/p>\n
I took the opportunity to rewrite Update-Gac.ps1 and in the process I decided to make it better. This illustrates the point I’ve made many times. With GUIs – you click buttons and that the end you what do you have? Maybe the system works, maybe it doesn’t and that is it. With scripting, you end up with a system that may or may not work (same as before) BUT you also produce an artifact (a script). When you share that script – the world changes. If your script is crap (or just doesn’t work) – people will look at it and tell you so and in the process they often tell you how to make it work or make it better. If it works – often people will show you better ways to accomplish the same task (as Kirill did today). <\/p>\n
Sometimes someone’s script will spark an inspiration – “I don’t need THAT but if it did THIS, that would be awesome!” and an incentive to create new scripts.<\/p>\n
One way or the other, the act of sharing a script improves your world. You get better. Others get better. The world gets better.<\/p>\n
So that is one thought. The other thought is that PowerShell is all about producing scripts OF THE RIGHT QUALITY<\/strong>. <\/p>\n Does that mean PowerShell is all about producing high quality scripts? ABSOLUTELY NOT!<\/p>\n High quality scripts are often very difficult and expensive to write. We absolutely want to support people that want to do this (we think about the guy who wants to run scripts that run the Federal Reserve Bank’s servers or the DataCenter at the CIA [I sure hope both of those environments write high quality scripts]). BUT we also want to support people that want quick and dirty scripts. <\/p>\n The task at hand should determine the quality of the script. For my Update-Gac script, it was a quick and dirty script that I rarely use. Now that I’ve decided to share it, I get a little embarrassed by how raw it is so I invested a few minutes this morning to improve the script itself (thanks again to Kirill) and the user experience of the script. At that is the point, scripts are living things. That start out and then over time we craft them, buff them, take suggestions from other people, sometimes other people take our scripts and bring them to new levels. <\/p>\n The efficient and effective creation and sharing of IT artifacts (scripts) is probably the biggest contribution PowerShell can make to the industry. Said another way, PowerShell doesn’t solve your IT problems. PowerShell helps the IT community to work together to solve it’s problems. This is precisely why we’ve added Graphical PowerShell (now called PowerShell Integrated Scripting Environment) to V2 – to make it easy to create and debug scripts. It is also why we added Modules – to make it easier and safer to share scripts.<\/p>\n OK – enough with all that. Here is the new and improved Update-gac.ps1<\/p>\n Set-Alias ngen (Join-Path ([System.Runtime.InteropServices.RuntimeEnvironment]::GetRuntimeDirectory()) ngen.exe) <Update 12\/4\/2008> NOTE – this is a workaround for a V1 bug. This is fixed in V2.<\/strong> <\/p>\n Cheers!<\/p>\n Jeffrey Snover [MSFT]
[AppDomain]::CurrentDomain.GetAssemblies() |
sort {Split-path $_.location -leaf} |
%{
$Name = (Split-Path $_.location -leaf)
if ([System.Runtime.InteropServices.RuntimeEnvironment]::FromGlobalAccessCache($_))
{
Write-Host “Already GACed: $Name”
}else
{
Write-Host -ForegroundColor Yellow “NGENing : $Name”
ngen $_.location | %{“`t$_”}
}
}<\/p>\n
Windows Management Partner Architect
Visit the Windows PowerShell Team blog at: http:\/\/blogs.msdn.com\/PowerShell<\/a>
Visit the Windows PowerShell ScriptCenter at: http:\/\/www.microsoft.com\/technet\/scriptcenter\/hubs\/msh.mspx<\/a><\/p>\n