Scenario: using Visual Studio you start debugging a Web Part that references a DLL deployed to the GAC and you receive an error message like this for your DLL:

The following module was built either with optimizations enabled or without
debug information ...

Now the breakpoints in your DLL will not be hit and trying to point Visual Studio to the PDB file in your \bin\debug\ folder using the modules window won’t work either. And of course you didn’t accidentally enable optimizations or disable debug info.

The DLL hasn’t changed either but obviously the GAC’d version and the PDB file in your \bin\debug\ folder somehow got out of sync. Whatever the cause for this is you just have to get the current version of the DLL into the GAC. To automate this go to Project | Properties | Build Events and add the following lines adapted to your DLL’s name as a post build command:

The install command has no backslash between $(TargetDir) and the file name

The install command only needs quotation marks if there are spaces in $(TargetDir)

You can’t use the DevEnvDir macro anymore as gacutil.exe is in a different directory now

As this doesn’t refer to the project itself but to a dependency you cannot use macros like TargetName and TargetPath

Visual Studio only reports errors in the last post build step–see the external references section for a solution

Visual Studio has to be run as administrator for gacutil.exe to work

You will still get an “exited with code 1” error the first time you run this after every build–just hit F5 again. At least this is consistent with the user experience when adding a DLL to the GAC by drag & drop via Explorer :-).

And of course this applies to referenced DLLs becoming stale in general–it’s not limited to SharePoint scenarios and or the latest incarnation of Visual Studio.

External References

See this blog post about how to add error checking to your post build commands.