|
Description
|
VSTO 1.0 solutions require .NET policy to be in place to permit them to run. A VSTO solution will not run by default unless some .NET policy explicitly permits a VSTO 1.0 solution to run. Those policy decisions are recorded in the v1.1 policy system. When you install v2.0 on an v1.1 machine and then run a VSTO 1.0 solution, we always load the latest version of the CLR so v2.0 is loaded. This is necessary because many customizations must run inside an Office process--the latest version of the CLR must be run to ensure that newer customizations compiled against newer CLRs will run. If for example Office locked to the v1.1 CLR it would guarantee that v2.0 customizations would not be able to be loaded. The CLR does everything possible to ensure older CLR customizations will run on newer CLR versions. When the v2.0 CLR is loaded and a VSTO 1.0 solution is loaded, the CLR policy being checked is the v2.0 CLR policy file, not the v1.1 CLR policy file. No attempt is made to migrate v1.1 CLR policy decisions to v2.0. Also, there isn't an appropriate time to do so-- v2.0 install time would not work because a VSTO 1.0 solution could be installed at a later time and lays down new v1.1 CLR policy. No migration could occur automatically at that time. Because VSTO 1.0 is v1.1 based, the office loader for VSTO 1.0 customizations (otkloadr.dll) needs to decide whether to load a VSTO 1.0 customization based on v1.1 policy. The fix for this bug will have otkloader check v1.1 policy when loading VSTO 1.0 solutions instead of checking the policy of the latest CLR. |