Hi Gary,

I ran the command you suggested, and looked at the log. There is one entry
indicating an error:

 <entry>
   <record>17</record>
   <time>2005/09/23 14:08:42.914</time>
   <type>Error</type>
   <source>Microsoft Visual Studio</source>
   <description>LoadLibrary failed for package
[SlickEdit.MSVSP.GUIElements.GUIElementsPackage, GUIElementsWhidbey,
Version=1.0.187.1000, Culture=neutral,
PublicKeyToken=bf81d2044fa6b642]</description>
   <guid>{509B99FF-C721-47BB-B0B6-C2FB2DC3A465}</guid>
   <hr>8007007e</hr>
   <path>C:\\WINDOWS\\system32\\mscoree.dll</path>
 </entry>

I think 0x8007007E means that a module could not be found, so I
double-checked the registry keys for this package. The CodeBase value points
to the correct location of this package, and the corresponding UI DLL
resides in a 1033\ subdir, so I believe it is finding the package DLLs
correctly. Next I checked the manifest for GUIElementsWhidbey.dll to find
the dependencies:

.assembly extern mscorlib
{
 .publickeytoken = (B7 7A 5C 56 19 34 E0 89 )                         //
.z\V.4..
 .ver 2:0:0:0
}
.assembly extern CoreWhidbey
{
 .publickeytoken = (BF 81 D2 04 4F A6 B6 42 )                         //
....O..B
 .ver 1:0:187:1000
}
.assembly extern Microsoft.VisualStudio.Shell.Interop
{
 .publickeytoken = (B0 3F 5F 7F 11 D5 0A 3A )                         //
.?_....:
 .ver 7:1:40304:0
}
.assembly extern Microsoft.VisualStudio.Shell
{
 .publickeytoken = (B0 3F 5F 7F 11 D5 0A 3A )                         //
.?_....:
 .ver 2:0:0:0
}
.assembly extern System
{
 .publickeytoken = (B7 7A 5C 56 19 34 E0 89 )                         //
.z\V.4..
 .ver 2:0:0:0
}
.assembly extern 'Microsoft.VisualStudio.Shell.Interop.8.0'
{
 .publickeytoken = (B0 3F 5F 7F 11 D5 0A 3A )                         //
.?_....:
 .ver 8:0:0:0
}
.assembly extern mscorlib as mscorlib_6
{
 .publickeytoken = (B7 7A 5C 56 19 34 E0 89 )                         //
.z\V.4..
 .ver 1:0:3300:0
}

I've manually verified that each of these dependencies exists either in the
GAC, or in my installation directory alongside the DLL which fails to load.
I even installed my CoreWhidbey.dll assembly into the GAC to see if the
runtime was only looking in the GAC to resolve dependencies, but that
resulted in the exact same error I listed above. Every one of the
dependencies also matches up with respect to public key token and version #,
except for mscorlib. The version of mscorlib in my GAC is 2.0.0.0, which is
what I would expect, but the version it is looking for is 1.0.3300.0. I
didn't think this would matter, but is it possible the machine's security
settings or something else is causing the .NET runtime to look for _exactly_
this version of the assembly, and not a newer, backwards-compatible version?
This is a brand new virtual machine, started with a clean disk. All I have
done is installed Windows 2000 with SP4, installed Whidbey Beta2, and then
installed my plug-in. Regarding your earlier question about whether I have
tried this in another Win2k VM, yes I have. I created another VM and did
exactly the same things, except this time I installed Whidbey RC instead of
Beta2. I still get the same error. I'm really stumped at this point. If it
would help, I would be happy to send you the installer itself to try in your
own Win2k VM.