• Comments 39

Below is the content of the Update-GAC.ps1 script that I run whenever I install a new version of PowerShell. Our installation is supposed to ngen the assemblies in the background. If that works, it doesn't work fast enough for me. Also I've seen lots of examples where people run this script long after their install and things get a TON faster so …. The install team is looking into the issue but until then – here is the script I use:

Set-Alias ngen @(
dir (join-path ${env:\windir} "Microsoft.NET\Framework") ngen.exe -recurse |
sort -descending lastwritetime
[appdomain]::currentdomain.getassemblies() | %{ngen $_.location}

<Update 12/4/008> NOTE - there is a updated (and better) version of this script HERE.


Jeffrey Snover [MSFT]
Windows Management Partner Architect
Visit the Windows PowerShell Team blog at: http://blogs.msdn.com/PowerShell
Visit the Windows PowerShell ScriptCenter at: http://www.microsoft.com/technet/scriptcenter/hubs/msh.mspx

Leave a Comment
  • Please add 8 and 8 and type the answer here:
  • Post
  • Don't forget that on x64 systems, you need to use "Microsoft.NET\Framework64" instead.

  • Consider passing "/nologo" to ngen.exe, to reduce noise.

  • Great info (as always)!

    As I'm not a .NET-guy, where can I find some backgroud info on GAC, ...

  • Jeffrey Snover [MSFT]: In V1, we had a problem which caused our assemblies to not get ngen&#39;ed during

  • I made a couple of tweeks to add detection of x86 and AMD64:

    Set-Alias ngen @(

    $ngen_path = Join-Path ${env:\windir} "Microsoft.NET\Framework"

    if(${env:PROCESSOR_ARCHITECTURE} -eq "AMD64"){

    $ngen_path = Join-Path ${env:\windir} "Microsoft.NET\Framework64"


    dir $ngen_path ngen.exe -recurse | where {$_.length -gt 0} | sort -descending lastwritetime


    [appdomain]::currentdomain.getassemblies() | %{ngen /nologo $_.location}

  • Can you use this to speed up Exchange Management Shell as well? As this always take a long time to load up!

  • Yes it does speed up the exchange managment shell.  it is still a little slow, but a major improvement.

  • FANTASTIC!  Thank you!

    I tested on XPsp2 and Vista Ultimate sp1 - both with great success.  The above comments helped too.

  • Jeffrey Snover of Microsoft, PowerShell dude extraordinaire, recently reminded us of a way to Speed Up

  • If you think your PowerShell startup is slow, or even if you think it is OK, follow the instructions

  • Am I correct in assuming that this script, in order to retain its benefits, would need to be re-run after any update or patch to Exchange or the .NET Framework?

  • see also



  • Error for System.Data.dll on x64 PowerShell.

    For some reason ngen always fails to comile a native image of System.Data.dll on PowerShell x64. Here's the relevant message.

    Microsoft (R) CLR Native Image Generator - Version 2.0.50727.3053

    Copyright (c) Microsoft Corporation.  All rights reserved.

    Installing assembly C:\Windows\assembly\GAC_64\System.Data\\System.Data.dll

    Failed to find dependencies of image C:\Windows\assembly\GAC_64\System.Data\\System.Data.dll be

    cause this image or one of its dependencies is not a valid Win32 application.

       Compiling assembly C:\Windows\assembly\GAC_64\System.Data\\System.Data.dll ...

    Error compiling C:\Windows\assembly\GAC_64\System.Data\\System.Data.dll: An attempt was made to

    load a program with an incorrect format. (Exception from HRESULT: 0x8007000B)

    Uninstalling assembly C:\Windows\assembly\GAC_64\System.Data\\System.Data.dll because of an err

    or during compilation.

  • There's a pretty easy way to get the framework path. I noticed some commenters trying to make it find the right version of ngen or what not...

    $FrameworkPath = [System.IO.Path]::GetDirectoryName([Object].Assembly.Location)

    $NgenPath = [System.IO.Path]::Combine($FrameworkPath, "ngen.exe")

  • @Brian - Making Microsoft.NET\Framework into Microsoft.NET\Framework64 as DM said.

Page 2 of 3 (39 items) 123