次の方法で共有

Another debugging tip

  • [アーティクル]

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_binWordProject238
  • You
    kick yourself for forgetting the AssemblyLinkLocation,
    and make the custom properties point to MyCoolTemplate_binMyCoolTemplate 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 ;-)