“Smarter than the average Document.”

Smart Document Deployment is definitely an issue that needs a lot of work.

For the past week I’ve been repeatedly stumped in the simple task of loading a Smart Document solution into Word. Not a specific, possibly-buggy SmartDoc – ANY SmartDoc solution. Even ones that worked before. Even the SDK-supplied SimpleSample. ALL.

I followed the MSDN instructions quite specifically. (Here).
I tried to debug using all the information here.
I added Code Access Security.
I changed namespace names.
I tried read the Fusion log to see what’s going on.
I uninstalled and reinstalled Office 2003 TWICE, in two different languages.

And all this time this nagging, teasing, whining headache of an error message popping up. “Missing or invalid Smart Document”. Grrr… I’ll show him missing or invalid!

Hmpf. Well. As always, the answer came from a totally unexpected direction.
Well, a rather expected direction, but in an unexpected manner. The Troubleshooting document listed above mentions the following possible cause:

You have Microsoft Windows® .NET Framework 1.0 and Microsoft Windows® .NET Framework 1.1 installed on your computer. However, you accidentally configured the code access security policy using version 1.0 of the .NET Framework instead of 1.1. Correct this by using the .NET Framework 1.1 to grant Full Trust permissions to the assemblies. Remember to delete the previous settings.

I have never had 1.0 installed on this machine, so I didn’t suspect a thing – but then I remembered that I *DID* install the 2.0 framework a couple of weeks ago, trying to get Whidbey to run here. (Unsuccessfully, I might add). Even though I built my SmartDoc project in Everett linked to Framework1.1, and I set my code-access permissions in the Configuration tool for Framework1.1, and everything was supposed to be side-by-side and fine and dandy – and nevertheless, once I uninstalled the 2.0 framework things started working immediately.

My guess is Word tried to load the managed Smart Document DLL using the 2.0 DLLs. Does this make sense? Is there any reason this happens? Any way to stop it? Do I need to specify explicit binding rules in WINWORD.EXE.config to get it to bind properly when both 1.1 and 2.0 are installed?

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.