Category Archives: The strange case of…

The strange case of Package ‘Visual Studio Explorers and Designers Package’ has failed to load properly

I was getting the error “Package ‘Visual Studio Explorers and Designers Package’ has failed to load properly” when working with add-ins in VS 2008 since a couple of days ago, along with “COM object that has been separated from its underlying RCW cannot be used” some other times. While I had seen the second error working with add-ins, I had never seen the first one. Browsing the MSDN Visual Studio Extensibility forum today I discovered that I was not the only one, and that the culprit is the Microsoft Source Analysis for C# tool that I installed a couple of days ago, when problems started 🙂

The strange case of InvalidCastException using EditPoint.FindPattern with Visual Studio Database Projects

Many months ago I reported to Microsoft through Microsoft Connect an InvalidCastException that happened when using the EditPoint.FindPattern with .sql files of a database project of Visual Studio 2008 Team Suite (or VS 2008 Edition for DB Professionals) Beta 2:

EditPoint.FindPattern causes InvalidCastException on SQL editor of VSTS for DB Professional projects
http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=295427

As I reported, the problem didn’t happen in Visual Studio 2005 (at the time of that report), so apparently the bug was introduced in Visual Studio 2008 Beta 2. Fortunately Microsoft fixed the bug for VS 2008 RTM, so I thought the case was closed.

However, last week a customer of my MZ-Tools add-in reported that same problem but using VS 2005. How could that be if the problem didn’t happen at that time? In fact the problem didn’t happen today with VS 2005 SP1 and the VS 2005 Vista update on my computer. Reviewing the list of updates that the customer had installed, I had all of them but this one:

Microsoft® Visual Studio® 2005 Team Edition for Database Professionals Service Release 1
http://www.microsoft.com/downloads/details.aspx?familyid=9810808c-9248-41a5-bdc1-d8210a06ed87&displaylang=en

I installed it, and bingo! The problem was reproduced. So, while VS 2005 SP1 works fine, that update, which was released after SP1, introduced the bug, that was included in VS 2008 Beta 2 and was fixed in VS 2008 RTM, but for VS 2005 users the bug remains there if they install that service release.

The strange case of System.UnauthorizedAccessException when registering a Visual Studio add-in for COM Interop

Today I received a bug report for a new customer of my MZ-Tools add-in for Visual Studio (who purchased directly the product without trying the trial version) and the first thing that he encountered when running the setup was:

System.UnauthorizedAccessException: Access to the registry key ‘HKEY_CLASSES_ROOTComponent Categories{62C8FE65-4EBB-45e7-B440-6E39B2CDBF29}’ is denied.

(alas, not the most wonderful first impression about a just purchased product, but…)

He was administrator and had disabled the antivirus and other things to no avail.

The exception was thrown from RegAssemblyVSNET200X.exe, a small utility that my setup uses to register the .NET add-in DLL for COM Interop, which basically checks that some required DLLs exist on the machine and then calls System.Runtime.InteropServices.RegistrationServices.RegisterAssembly to register the assembly for COM/ Interop (the same that you can do with the regasm.exe utility of the .NET Framework).

The only reference to this problem that I found with Google was:

http://www.dotnet247.com/247reference/msgs/54/273059.aspx

That shows that a call to EnsureManagedCategoryExists is made. When you register an assembly for COM Interop, a registry entry is created like this:

HKEY_CLASSES_ROOT
   CLSID
      <Your GUID>
         Implemented Categories
            {62C8FE65-4EBB-45e7-B440-6E39B2CDBF29}

And after creating that registry entry, the .NET Framework calls EnsureManagedCategoryExists to ensure that the implemented category, well, actually exists. Using Reflector for .NET to decompile that method I got:

Private Sub EnsureManagedCategoryExists()
   Using key As RegistryKey = Registry.ClassesRoot.CreateSubKey("Component Categories")
      Using key2 As RegistryKey = key.CreateSubKey("{62C8FE65-4EBB-45e7-B440-6E39B2CDBF29}")
         key2.SetValue("0", ".NET Category")
      End Using
   End Using
End Sub

And somehow even if you are administrator the CreateSubKey method can fail if the user doesn’t have proper permissions.

While I was investigating all this, the customer was smart enough to find this KB article explaining the problem and solution:

FIX: “Access to the Registry Key Denied” Error Message When You Register .NET Assembly for COM Interop
http://support.microsoft.com/kb/327507

The article states that it is a permissions problem (even if you are an administrator) although it does not clarify how permissions can become different on several machines (for most admins, COM Interop registration works fine). It states too that the problem was fixed in .NET Framework 1.1, which means that it should happen only with .NET Framework 1.0 (Visual Studio .NET 2002), but the customer was using MZ-Tools for Visual Studio .NET 2003, 2005 and 2008, so there is something missing here and in fact, as fas as I can tell, the logic and the decompiled EnsureManagedCategoryExists method is virtually the same for the three .NET Framework versions.

Anyway I hope this post helps to solve this problem if you ever encounter it.

The strange case of error 80131018 loading a Visual Studio add-in

A couple of weeks ago a received an error report from a customer of my MZ-Tools add-in saying that VS 2005 failed to load it with error “Unknown error” and error code 0x80131018. Searching my e-mail history it happened that that error was already reported by a previous customer months ago, but it was not clear how it was solved. The current customer tried to reinstall the add-in, to reinstall VS 2005 and even to format the hard drive, to no avail. Searching on the web, there is little information about this error, only that it is mapped to COR_E_ASSEMBLYEXPECTED and that it caused because a .NET assembly doesn’t have a manifest, that is, it is not a .NET assembly actually. In fact, this method is used to know if a DLL is a .NET assembly or not. But how could it be that a .NET add-in assembly does have a missing manifest? The customer sent it to me and the manifest was there. In fact, it loaded perfectly on my machine, and on another machine of him. The fuslogvw.exe tool gave this log:

LOG: This bind starts in LoadFrom load context.
WRN: Native image will not be probed in LoadFrom context. Native image will only be probed in default load context, like with Assembly.Load().
LOG: Using application configuration file: C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\devenv.exe.Config
LOG: Using machine configuration file from C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\configmachine.config.
LOG: Attempting download of new URL file:///C:/Program Files/MZTools2005/MZTools5.DLL.
LOG: Assembly download was successful. Attempting setup of file: C:\Program Files\MZTools2005\MZTools5.dll
LOG: Entering run-from-source setup phase.
ERR: Error extracting manifest import from file (hr = 0x80131018).
ERR: Failed to complete setup of assembly (hr = 0x80131018). Probing terminated.

In the tests that I asked him to perform, the assembly loaded correctly using Assembly.LoadFrom from a Windows application or using the Reflector for .NET tool, so the error happened only inside VS 2005.

Finally, and when I was quite desperate with this problem, the customer discovered that the problem was caused by the version 2007 of his antivirus, which I won’t cite, but suffice to say that the culprit was its “Protection Against Unknown Threats” feature. As soon as he deactivated that feature, the add-in loaded quite happily.

I hope this helps if you ever find this problem.