I wrote about a few debugging tips for VSTO the other day. Something else just came up this morning that I should add. Does this scenario sound familiar?

  • You decide to create a new VS project
  • You click through all the default dialogs, ignoring the silly default name (you'll change it later)
  • You build and debug WordProject238 for a while until it is looking good
  • You give the finished project to someone and they complain that the name is not very descriptive
  • You rename the document to MyCoolTemplate.dot and rename the assembly to MyCoolAssembly.dll
  • You test the document and it fails to find WordProject238_bin\WordProject238
  • You kick yourself for forgetting the AssemblyLinkLocation, and make the custom properties point to MyCoolTemplate_bin\MyCoolTemplate instead
  • Your code still fails to run with some spurious "Can't be found or loaded" error

Well guess what? You just broke a fundamental rule of the CLR -- the "assembly name" (the thing you pass to Assembly.Load) must match the internal "assembly name" (the thing inside the Manifest). The compiler sets the Manifest's name to be the same as the DLL's name when you build the project, and manually re-naming the DLL after the fact will cause problems.

You have to go to the Project Properties inside VS, change the output name to MyCoolTemplate.dll, and then re-build the project. (This should also fix up the custom properties for you).

This "bug" came up several times during the product cycle, and it just came up again today. If it ever comes up again, I'll have a URL to point to ;-)