Exposing the Global Assembly Cache

If you're familiar with the Global Assembly Cache (GAC) you're probably aware there's a special file system viewer thingy (technical term) sitting over top of the GAC contents at c:\windows\assembly; this is a nice convenience when it comes to registering assemblies in the GAC—simply drag and drop, avoiding a trip to the command line and gacutil –i

More often than not, this is all good. When you need to dive into the real GAC, to extract an assembly, drop in debugging symbols, or whatever, you'll quickly realise the viewer is somewhat limiting.

To get past the GAC's outer facade, you've got a few options:

• From a command line, browse to c:\windows\assembly\gac_msil
• Map a network drive to \\machine-name\c$\windows\assembly\gac_msil
• Create a virtual drive: subst z: c:\windows\assembly\gac_msil where 'z:' is any unmapped drive letter
• Start –> Run c:\windows\assembly\gac_msil
• Turn off the viewer altogether to browse the GAC directory structure normally within Windows Explorer: create a new DWORD named DisableCacheViewer with a value of 1 below the HKLM\Software\Microsoft\Fusion key

Five ways to do the same thing? Well this is Windows after all—and there are probably more!!! ;)

If you drop the gac_msil bit you'll find there are other directories that make up the GAC proper to explorer but most of what you'll be after resides below gac_msil. Each assembly is represented in by name as a folder with different versions represented as sub folders named as the version number with a GUID appended; the assembly proper will live in one of these folders.

If you found this post helpful, please support my advertisers.

Remove quotes from batch file parameters

No doubt a boring old school trick for the Powershell users among you, so, like, over batch files but handy in case of emergency:

If you supply a quoted parameter to a batch file (e.g. a directory path) and later need to remove the quotes to accommodate additional manipulation, handle the incoming parameter as %~1 instead of %1. 

To remove a trailing slash, do this:

IF "%SOLUTION_DIR:~-1%"=="\" SET SOLUTION_DIR=%SOLUTION_DIR:~0,-1%

Thanks Chuck and Jon!

Conditional Post-Build Event Command for x64 sgen

I’ve bitten the bullet and decided to run Windows Server 2008 Hyper-V on my workstation; in addition to virtualising my MOSS dev environment, I’ve also chosen to virtualise my workstation environment on Windows Server 2008 x64; work won’t let me get away with Windows 7 RC1 and there’s no “supported” upgrade path to the RTM anyway.

You may have read my previous post on the subject of x64 targeting with Visual Studio setup projects; today, however, is all about just getting VS to compile a project with a post-build event where Visual Studio 2008 is running on Windows Server 2008 x64 with SP2. In our case, the post-build event needs to run sgen.exe from the correct location since some of our devs are still on Vista x32. And yeah, I know, post-build events are old school but it’s an existing solution…

Windows Server 2008 with Visual Studio 2008 SP1 and .NET 3.5 SP1 installed does not include sgen.exe for some reason. Why not?!? Good question—you can install it by downloading the Windows SDK for Windows Server 2008 and .NET Framework 3.5. v6.0a does seem to be installed by VS2008 on 32-bit/W2k3 environments (more about this). Kicking off the SDK installer, I chose to install the .NET Development Tools only (Developer Tools\Windows Development Tools\.NET Development Tools).

This all seems good but sgen will be installed to a different location than you may be used to: %programfiles%\Microsoft SDKs\Windows\v6.1\Bin\x64 (the 64-bit Program Files folder, that is). To accommodate this difference from the 32-bit world, I need some conditional logic in my post-build event.

At first glance, using the %processor_architecture% environment variable makes sense—it returns “x86” in my current XP 32-bit environment, presumably the same in Vista x32, and “AMD64” in Hyper-V… not quite “x64” but enough to branch on. As we all know, however, Visual Studio is only available as a 32-bit application and seems to do some additional environment variable setting of is own: echo %processor_architecture% in a post-build event prints out “x86”, obviously the same as our 32-bit environment. No good.

To work around and take advantage of this, my post-build event compares the %ProgramFiles% variable against “C:\Program Files”; when queried from a post-build event in a 64-bit environment, it reliably returns “C:\Program Files (x86)” which I know is the 32-bit Program Files folder; in that case, my script uses the 64-bit sgen. Note the same variable will return “C:\Program Files” in a normal command window so be careful and test in VS directly.

In the end, here is my post-build event:

REM Use the 64-bit sgen from the Win 2008 and .NET 3.5 SDK in a 64-bit dev environment
REM ProgramFiles variable is set to 'Program Files (x86)’ in a x64 environment
REM Processor_Architecture variable returns x86 in both an x86 and x64 environment within VS

if /I "%ProgramFiles%" == "C:\Program Files" (
set ToolPath="C:\Program Files\Microsoft
SDKs\Windows\v6.0A\Bin\sgen.exe"
) else (
set ToolPath="C:\Program Files\Microsoft
SDKs\Windows\v6.1\Bin\x64\sgen.exe"
)

%ToolPath% /compiler:"\"/keyfile:$(ProjectDir)
MyKeyFile.snk"\" /force "$(TargetPath)"

Batch file variables

Admitedly, I'm not a big batch file geek but like most of you I infrequently dive in and whip up a batch file for any number of reasons. 

So with that preface, here's my stupid tip: 

When setting a variable, don't included spaces between the assignment operator

This probably isn't what you want:

set myvar = hello

echo %myvar%

%myvar%

But this works as expected:

set myvar=hello

echo %myvar%

hello