I finally managed to have a first beta going to the Tech Head Brothers authors of my publishing tool based on Word 2003, XML, Web Services… Read more and a bit more.
So I have a cool setup for the tool that works for me on two machines, but when you start to distribute your software you face other challenges. On three authors computer it was not working, a VSTO security problem, for sure what else. After some discussions with them I realized they had the .NET Framework Beta 2 installed. And so ?
Here is the explanation from Misha Shneerson I had on the newsgroup:
VSTO loader (aka OTKLoader) that shipped with Office 2003 RTM would always load the latest runtime installed on the machine. Once you install .NET Fx 2.0 this runtime will be loaded. Each version of CLR runtime has its own CAS policy settings. Note also that installinng .NET Fx 2.0 would not migrate security policies from .NET Fx 1.1. So, the real problem is that your code simply does not have permission to load once .NET Fx 2.0 is installed.
The brute force solution is of course to force loading v1.1 version of CLR through the config file. But this will rule out the usage of VSTO 2005 since VSTO 2005 runtime requires CLR 2.0 to run and you can not have both versions of CLR running at the same process. Unfortunately, I should add.
So, I would suggest to manually migrate Fx 1.1 security policies to Fx 2.2. I know this is painful, but this is the least bad solution for now.
I am not sure I can disclose the full details but before VS 2005 ships we will see an Office 2003 SP2 coming out. The SP will contain a patch for OTKLoader that would not require migrating security policies from 1.1 to 2.0 even though the 2.0 version of CLR will be loaded on the machine.
The brute force solution is one I already used. You have to force Word 2003 to load the .NET Framework you are interested in by creating a winword.exe.config and saving it in the folder of winword.exe. Thanks to Chuck Hartman to remind me that method:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<startup>
<supportedRuntime version="v1.1.4322" />
</startup>
</configuration>My first trial to migrate the security policies from 1.1 to 2.2 was not successful, so I first sent the brute force solution to the different authors. Then I thought of a solution I saw some times ago on the blog of Peter Torr : A useful regfile for VSTO. So I took his regfile and modified to run with .NET Framework 2.0:
Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\dllfile\shell\FullTrust]
@="Trust assembly Beta 2"
[HKEY_CLASSES_ROOT\dllfile\shell\FullTrust\command]
@="C:\\WINDOWS\\Microsoft.NET\\Framework\\v2.0.50215\\caspol.exe -q -u -ag 1 -url \"%1\" FullTrust -n \"%1\""
[HKEY_CLASSES_ROOT\dllfile\shell\UnTrust]
@="Remove assembly trust Beta 2"
[HKEY_CLASSES_ROOT\dllfile\shell\UnTrust\command]
@="C:\\WINDOWS\\Microsoft.NET\\Framework\\v2.0.50215\\caspol.exe -q -u -rg \"%1\""
[HKEY_CLASSES_ROOT\exefile\shell\FullTrust]
@="Trust assembly Beta 2"
[HKEY_CLASSES_ROOT\exefile\shell\FullTrust\command]
@="C:\\WINDOWS\\Microsoft.NET\\Framework\\v2.0.50215\\caspol.exe -q -u -ag 1 -url \"%1\" FullTrust -n \"%1\""
[HKEY_CLASSES_ROOT\exefile\shell\UnTrust]
@="Remove assembly trust Beta 2"
[HKEY_CLASSES_ROOT\exefile\shell\UnTrust\command]
@="C:\\WINDOWS\\Microsoft.NET\\Framework\\v2.0.50215\\caspol.exe -q -u -rg \"%1\""
[HKEY_CLASSES_ROOT\Folder\shell\FullTrust]
@="Trust folder Beta 2"
[HKEY_CLASSES_ROOT\Folder\shell\FullTrust\command]
@="C:\\WINDOWS\\Microsoft.NET\\Framework\\v2.0.50215\\caspol.exe -q -u -ag 1 -url \"%1\"\\* FullTrust -n \"%1\""
[HKEY_CLASSES_ROOT\Folder\shell\UnTrust]
@="Remove folder trust Beta 2"
[HKEY_CLASSES_ROOT\Folder\shell\UnTrust\command]
@="C:\\WINDOWS\\Microsoft.NET\\Framework\\v2.0.50215\\caspol.exe -q -u -rg \"%1\"" Now it is running without the brute force solution, so it is much cleaner.
[ Currently Playing : Strategie D’un Pion - Iam - Revoir Un Printemps (04:36) ]