Carlos Quintero (Microsoft MVP) blog : The strange case of...

The strange case of VS 2010 (Beta 2 /CTPs) closing at startup or failing to create add-ins

carlosq — Tue, 20 Oct 2009 11:12:00 GMT

As you know if you develop add-ins, Visual Studio 2005 introduced XML-based add-ins that use an .AddIn file that you must place in the proper folder for Visual Studio to show the add-in in the Add-In Manager. Which XML parser Visual Studio uses to parse .AddIn files wouldn't be of interest if it wasn't because for some people their Add-In Manager didn't show XML-based add-ins... and the problem was solved installing MSXML. While I didn't experience that problem personally, I have experienced a related problem with VS 2010 Beta2 and older CTPs.

The problem was that when I tried to create an add-in with the add-in wizard I got this misleading error message (misleading because I do have the proper language installed).

"An error occurred, and the wizard could not generate the project. Verify that the programming language is properly installed"

And more interestingly, if a place an .AddIn file (even an empty .AddIn file!) in one of the folders that VS scans for .AddIn files, VS 2010 fails to load with the following error message:

"The application cannot start"

and then it closes!

I remembered the problem of the empty Add-In Manager, I thought it could be related, so I verified with the Process Monitor tool that VS was certainly failing to get the MSXML2.Document.6.0 ProgId from the registry just before scanning folders for .AddIn files. I installed MSXML 6.0 and lo and behold, the problem was solved.

So, I discussed this with several people inside the VS team and they confirmed that VS 2010 will use MSXML 6.0 to parse .AddIn files, etc. (I am not sure if VS 2005/2008 uses that version or older ones). It happens that I was using a virtual machine with Windows XP SP2, and it doesn't include MSXML 6.0 (it includes MSXML 3.0 SP5), but VS 2010 Beta 2 / CTPs didn't install it either. When I asked why VS 2010 didn't install it as a prerequisite, the answer was that VS 2010 will require SP3 of Windows XP (which includes MSXML6), and the final release of VS 2010 will refuse to install on Windows XP SP2, something that the current betas / CTPs don't enforce yet.

Now I hope that the Visual Studio Team modifies VS 2010 to show better behavior and diagnostics if, for whatever reason, Visual Studio doesn't find the MSXML parser that it requires. We as developers tend to focus on code paths where things go as expected, and pay less attention to edge cases, but when things go bad, it causes a lot of pain to other people trying to diagnose and solve the problem. Something better than silent errors (empty Add-In Manager), crashes without further information or misleading error messages can be done...

The strange case of error 0x80070005 "Access Denied" using PEVerify.exe with an add-in referencing a Visual Studio assembly not in the GAC

carlosq — Mon, 29 Jun 2009 15:35:00 GMT

It took me quite a lot of time to fix the problem of Error 0x80070002 "The system cannot find the file specified" using PEVerify.exe to verify add-in with referenced assemblies from Visual Studio not in the GAC. I found the problem yesterday Sunday afternoon when I was with my laptop at a Starbucks with no connection to Internet other than a very weak GPRS connection with my mobile phone, so I could only get on the web that the solution was to use the codeBase tag in a .config file. The file that I used was:

<?xml version="1.0" ?>
<configuration>
   <runtime>
      <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
         <dependentAssembly>
            <assemblyIdentity name="Microsoft.VisualStudio.Data.Interop" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
            <codeBase version="8.0.0.0" href="C:\Program Files\Microsoft Visual Studio 8\Common7\IDE" />
         </dependentAssembly>
      </assemblyBinding>
   </runtime>
</configuration>

Using this file I got this other error:

0x80070005 "Access Denied"

rather than:

0x80070002 "The system cannot find the file specified".

So today with more Internet connectivity I have been investigating the problem. The only reference to this problem was Debugging Assembly Loading Failures, where Suzzane Cook stated the obvious, to check file locks without shared-read access and ACLs. But this was not the problem.

The fusion log showed this:

LOG: GAC Lookup was unsuccessful.
LOG: Attempting download of new URL file:///C:/Program Files/Microsoft Visual Studio 8/Common7/IDE.
LOG: Assembly download was successful. Attempting setup of file: C:\Program Files\Microsoft Visual Studio 8\Common7\IDE
LOG: Entering run-from-source setup phase.
ERR: Error extracting manifest import from file (hr = 0x80070005).
ERR: Failed to complete setup of assembly (hr = 0x80070005). Probing terminated.

So I was clueless until I found the string "ERR: Error extracting manifest import from file" in a .rc file inside www.koders.com, the site that has the source code of some open source portions of the .NET Framework CLR and tools. The string led me to the identifier ID_FUSLOG_MANIFEST_EXTRACT_FAILURE which in turn led me to the following code in the bindhelpers.cpp file:

HRESULT BindToSystem(IAssemblyName *pNameSystem,
                     LPCWSTR pwzSystemDirectory,
                     IUnknown *pUnk,
                     IAssembly **ppAsmOut,
                     IAssembly **ppNIAsmOut,
                     IFusionBindLog **ppdbglog)
{
    HRESULT hr = S_OK;
    IAssembly *pAsm = NULL;
    CAssembly *pCAsm = NULL;
    CNativeImageAssembly *pAsmNI = NULL;
    DWORD dwSize = 0;
    IAssemblyManifestImport *pAsmImport = NULL;
    INativeImageEvaluate *pNIEva = NULL;
    WCHAR wzManifestFilePath[MAX_PATH];
    IAssemblyName *pName = NULL;
    static BOOL bCalled = FALSE;
    CDebugLog *pdbglog = NULL;
    BOOL    bFoundInDevOverride = FALSE;

    MEMORY_REPORT_CONTEXT_SCOPE("FusionBindToSystem");

    if (!pNameSystem || !ppAsmOut || CAssemblyName::IsPartial(pNameSystem) || !CAssemblyName::IsStronglyNamed(pNameSystem) || !pwzSystemDirectory){
        return E_INVALIDARG;
    }

    *ppAsmOut = NULL;

    // should only be called once.
    if (bCalled) {
        *ppAsmOut = g_pSystemAssembly;
        if (g_pSystemAssembly) {
            g_pSystemAssembly->AddRef();
            return S_OK;
        }
        else {
            return HRESULT_FROM_WIN32(ERROR_FILE_NOT_FOUND);
        }
    }

    if (IsLoggingNeeded()) {
        CDebugLog::Create(NULL, pNameSystem, NULL, &pdbglog);
    }

    wzManifestFilePath[0]= L'\0';

    if (pUnk) {
        hr = pUnk->QueryInterface(IID_INativeImageEvaluate, (void **)&pNIEva);
        if (FAILED(hr)) {
            goto Exit;
        }
    }

    // temporary IAssemblyName for mscorlib
    g_pSystemAssemblyName = pNameSystem;
    g_pSystemAssemblyName->AddRef();

    // we are here because we cannot find the custom assembly,
    // or we are not asked for a custom assembly.

    if (!bFoundInDevOverride) {
        hr = CAssemblyName::CloneForBind(pNameSystem, &pName);
        if (FAILED(hr)) {
            goto Exit;
        }

        hr = CreateAssemblyFromCacheLookup(NULL, pName, ppAsmOut, NULL);
        if (FAILED(hr) && hr != HRESULT_FROM_WIN32(ERROR_FILE_NOT_FOUND)) {
            goto Exit;
        }

        if (hr == S_OK) {
            DEBUGOUT(pdbglog, 1, ID_FUSLOG_CACHE_LOOKUP_SUCCESS);
        }
        else if (hr == HRESULT_FROM_WIN32(ERROR_FILE_NOT_FOUND)){
            DEBUGOUT(pdbglog, 1, ID_FUSLOG_ASSEMBLY_LOOKUP_FAILURE);
        }

        if (hr == HRESULT_FROM_WIN32(ERROR_FILE_NOT_FOUND)) {
            dwSize = MAX_PATH;
            hr = StringCchPrintf(wzManifestFilePath, MAX_PATH, L"%ws%ws.dll", pwzSystemDirectory, SYSTEM_ASSEMBLY_NAME);
            if (FAILED(hr)) {
                goto Exit;
            }

            DEBUGOUT1(pdbglog, 0, ID_FUSLOG_ATTEMPT_NEW_DOWNLOAD, wzManifestFilePath);

            hr = CreateAssemblyFromManifestFile(wzManifestFilePath, NULL, NULL, ppAsmOut);
            if (FAILED(hr)) {
                DEBUGOUT1(pdbglog, 1, ID_FUSLOG_MANIFEST_EXTRACT_FAILURE, hr);
                goto Exit;
            }
        }
    }

Exit:

    if (pdbglog) {
        pdbglog->SetResultCode(FUSION_BIND_LOG_CATEGORY_DEFAULT, hr);
        DUMPDEBUGLOG(pdbglog, g_dwLogLevel);
        DUMPDEBUGLOGNGEN(pdbglog, g_dwLogLevel);
        if (ppdbglog) {
            *ppdbglog = pdbglog;
            pdbglog->AddRef();
        }
    }

    SAFERELEASE(g_pSystemAssemblyName);

    if (SUCCEEDED(hr)) {
        pCAsm = static_cast<CAssembly *>(*ppAsmOut); // dynamic_cast
        pCAsm->SetIsSystemAssembly(TRUE);

        g_pSystemAssembly = *ppAsmOut;
        g_pSystemAssembly->AddRef();
        g_pSystemAssembly->GetAssemblyNameDef(&g_pSystemAssemblyName);
    }

    if (FAILED(hr)) {
        SAFERELEASE(*ppAsmOut);
    }

    SAFERELEASE(pdbglog);
    SAFERELEASE(pAsmImport);
    SAFERELEASE(pAsm);
    SAFERELEASE(pAsmNI);
    SAFERELEASE(pNIEva);
    SAFERELEASE(pName);

    bCalled = TRUE;
    return hr;
}

I have marked in bold the relevant code. It was not until I saw the name of the function CreateAssemblyFromManifestFile when I realized that I had to specify the full file name and not the folder of the assembly in the .config file. Once modified to the following it worked without errors:

<?xml version="1.0" ?>
<configuration>
   <runtime>
      <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
         <dependentAssembly>
            <assemblyIdentity name="Microsoft.VisualStudio.Data.Interop" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
            <codeBase version="8.0.0.0" href="C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\Microsoft.VisualStudio.Data.Interop.dll" />
         </dependentAssembly>
      </assemblyBinding>
   </runtime>
</configuration>

The "access denied" error was misleading since it would be more useful to keep showing the "file not found" error.

Now, imagine the time that you could save diagnosing problems in extensions for Visual Studio if you could have access to the Visual Studio source code, even without being able to debug, just debugging with the brain as I did...

The strange case of Add Resource \ New Image menu empty when an add-in is loaded in Visual Studio

carlosq — Fri, 26 Jun 2009 21:05:00 GMT

These days I have been playing a lot with resource images in managed satellite dlls and one thing that I was noticing sporadically was that the Add Resource \ New Image menu on the toolbar of the document window of a resource.resx file was empty, while it should have the typical "Bmp image", "Png image", etc. menu entries. Since I was playing with 32-bit bitmaps images with transparency in the alpha channel that cannot be created with Visual Studio, most of the time I was using a 3rd party bitmap editor and using the Add Resource \ Add Existing File... menu. But nonetheless, I was intrigued by the missing submenus in the New Image menu. Today that I finished my investigation of the managed satellite dlls, I decided to investigate the issue.

The first thing that I noticed was that the issue was not reported on the web, or maybe only mentioned once without a solution, which was strange because I could reproduce the problem on two computers on mine. I was clueless when I discovered by chance that the problem happened only when I had my MZ-Tools add-in loaded in Visual Studio on startup. After a few minutes of debugging I isolated the problem: it happened when the toolbar of the add-in was created, so I was able to create a minimal add-in to reproduce the problem and report it to Microsoft:

The Add Resource\New Image menu empty when VS add-in creates a toolbar
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=470755

The problem happens with VS 2005 and 2008, but it is fixed in VS 2010 Beta 1, likely due to its new WPF-based commandbars.

The strange case of Visual Studio getting "out of memory"

carlosq — Tue, 09 Jun 2009 08:11:00 GMT

I started programming in the old times of 16-bit MS-DOS, where you had only 640 KB of memory, and you had concepts like "expanded memory" and "extended memory" and memory bank switching to use more than 640 KB and then wonderful things like the Watcom C++ compiler that allowed you to create linear 32-bit MS-DOS programs to use all the available memory, not just 640 KB or 1 GB MB (oops!). When Windows (95) became a 32-bit OS and I learned at college about 32 bit pointers, it seemed that 4 GB of memory will be enough forever. Guess what? Some weeks ago I got "out of memory" errors from Visual Studio when trying some features of my MZ-Tools add-in that operate on every file of a solution. Specifically, the problem happened when iterating the code elements of the EnvDTE.ProjectItem.FileCodeModel of every file of the solution. My computer had 4 GB of RAM so I was surprised by this error (later I learned that the amount of RAM is irrelevant for most "out of memory" errors in modern virtual memory operating systems).

The first reference that I found on the web about this error was in the MSDN VSX forum:

ProjectItem.FileCodeModel causes memory fragmentation?
http://social.microsoft.com/Forums/en-US/vsx/thread/9d6c1d17-63c8-40c4-b6bc-e7f0ead65c3d

Notice that while MSFT people explained that this is due to COM objects in memory wrapped by .NET objects that are not released, the explanation does not solve the problem, neither the manipulation of the Garbage Collector (GC). I didn't try using EnvDTE.Project.CodeModel because it didn't meet my needs of "file by file" processing.

Then I found that mine was not the only extension for Visual Studio experiencing this problem. Resharper was also experiencing it and provided some tools to fix it. But it was non until I read this post when I learned about the cause and (kind of) solution for this problem:

Hacking Visual Studio to Use More Than 2Gigabytes of Memory
http://stevenharman.net/blog/archive/2008/04/29/hacking-visual-studio-to-use-more-than-2gigabytes-of-memory.aspx

So, the problem is not the lack of physical memory (RAM) or virtual memory, but the address space of 32-bit processes, which is limited to 4 GB and half of it is reserved for the OS (kernel mode) so the process has only 2 GB for it (user mode). And using the file code model of every file of a solution can cause Visual Studio to reach the limit of 2 GB of its user-mode address space. Using the /3GB option in the boot.ini file allows 3 GB of address space for the user mode part of the process and 1 GB for the kernel mode part, which can cause other problems because 1 GB is little these days for some video cards, etc.

Also, to take advantage of the 3 GB address space, a process must be "marked" to indicate the OS that it can use all those memory addresses. This is done with the LARGEADDRESSAWARE flag in the executable image that Visual Studio 2008 does have set, but Visual Studio 2005 doesn't (although you can patch it with the editbin utility as explained in the link above).

In my case, using the /3GB option in boot.ini with VS 2008 "solved" the problem and using the Task Manager I saw devenv.exe passing the limit of 2 GB without causing the "OutOfMemory" exception. I say "solved" because this is not really a happy solution, it is not something that you can patch in your add-in, you need to show a message explaining the user to either use Windows 64-bit (which gives 32-bit processes the full 4 GB address space for user-mode) or to use the /3GB option with Windows 32-bit (that can cause other problems, in my case with two other applications).

So, 32-bit pointers and 4 GB are not enough these days... maybe with 64-bit pointers we'll have these problems solved forever.

There is a bunch of very interesting resources on the web about all this, starting by the Raymond Chen's series:

Summary of the recent spate of /3GB articles
http://blogs.msdn.com/oldnewthing/archive/2004/08/22/218527.aspx

and this one of today:

“Out Of Memory” Does Not Refer to Physical Memory
http://blogs.msdn.com/ericlippert/archive/2009/06/08/out-of-memory-does-not-refer-to-physical-memory.aspx

The strange case of Microsoft.mshtml assembly missing

carlosq — Fri, 17 Apr 2009 09:21:00 GMT

I received the following bug report from a customer:

System.IO.FileNotFoundException: File or assembly name Microsoft.mshtml, or one of its dependencies, was not found.

My MZ-Tools add-in references this component. Actually it doesn't use it (it was for future HTML/ASP.NET support) but that doesn't matter. AFAIK, that component was installed by every installation of Visual Studio, because it is used for the ASP.NET/HTML designers (which until VS 2008 were IE-based). How could be that the customer didn't have it?

It turned out that the customer was using Visual Studio .NET 2003 and that he installed only Visual C++, neither VB.NET nor C#. It seems that Visual C++ 2003 doesn't use that component, and as soon as he installed VB.NET, the component was installed...

BTW, it seems that each time that I think about dropping support for VS.NET 2003 and concentrating only in VS 2005, 2008 and 2010 with .NET 2.0, I receive an e-mail from someone that happens to use VS.NET 2003... definitely developers of commercial add-ins need to support old versions of Visual Studio for many years....

The strange case of 8013150A loading a Visual Studio add-in

carlosq — Tue, 24 Mar 2009 13:02:00 GMT

Visual Studio add-ins are not very friendly when trying to auto-update them (at least as of Visual Studio 2008), so when deploying an add-in for internal use within an organization, one creative idea is to put the assembly dll in a shared network folder and register the add-in from there in each computer without copying it to the hard disks. You can do this putting the XML .AddIn file in that same folder and adding that folder to the list of locations that VS uses when searching for add-ins (Tools, Options menu, Environment, Add-in/Macros security). During the day you won't be able to update the add-in assembly because it will be in use by the developers, but chances are that you will be able to do it at night (with some automated mechanism).

There is still a problem, though. As of .NET Framework 3.5 (without SP1) and below, by default assemblies in shared network folders lack FullTrust permission required to run add-ins, because shared folders belong to the LocalIntranet_Zone, which has a LocalIntranet permission set, not a FullTrust permission set. This was an incovenience not only for add-ins, but also for general .NET applications, and since configuring the .NET runtime security policy is not trivial, I guess that Microsoft got tired of support calls and complaints from developers and IT staffs and in SP1 of .NET Framework 3.5 they changed things to allow .NET assemblies to run with FullTrust permission from shared network folders (you can revert back this change if you want the old behavior).

Note: .NET Framework 3.5, 3.0 and 2.0 share the same CLR, so it's CLR 2.0 what matters for security and add-ins, not the .NET Framework.

So, the question I was wondering is: can then a .NET 2.0 add-in run from a shared network location without further security configuration changes? I did the test, and I got this nice COM error: 8013150A (not very helpful as usual). If I changed the permissions to FullTrust in that shared network location, it worked, so I have enhanced my article about troubleshooting with a mention to this error:

HOWTO: Troubleshooting Visual Studio and Office add-ins
http://www.mztools.com/articles/2007/MZ2007009.aspx

The only remaining thing to clarify is why the security policy change doesn't work with add-ins. Well, it happens that this is by "design", it doesn't work with ClickOnce applications or applications that are designed to run on a host:

Running Intranet Applications in Full Trust
http://msdn.microsoft.com/en-us/library/cc713717.aspx

The strange case of ProjectItem.Open(EnvDTE.Constants.vsext_vk_Designer) trying to check-out a form file

carlosq — Mon, 09 Mar 2009 15:10:00 GMT

Today I have solved a problem that was bugging me for months. I was aware of it but I hadn't paid much attention to it (because I knew it was not a problem of my MZ-Tools add-in) until today, when I decided to take a closer look. The problem was the following: whenever I executed one of the features of MZ-Tools that reviews the designers of forms (such as the TabIndex review, the Access Keys review, etc.), of a solution under source control, the MDI form of the application became checked-out after the review and I had to undo the check-out by hand.

The line of code that caused the check-out was, of course:

ProjectItem.Open(EnvDTE.Constants.vsext_vk_Designer)

and I knew that the problem was not MZ-Tools because opening the designer by hand in the IDE resulted also in a silent check-out. I noticed too that if I disconnected the solution from source control, in this case Visual Studio prompted to edit the read-only file with a dialog with buttons "Edit In-memory", "Make Writeable" and "Cancel". So, Visual Studio was really feeling the need of edit a designer file when opening it. But what was causing it?

I have spent the whole morning prunning the project, the form and the code, with several oops-too-much-pruning-that-no-longer-reproduces-the-problem and finally I have a minimal reproducible pattern:

1) Create a new Windows Forms project with Form1.

2) Create a user control UserControl1 with this code:

   Private Sub UserControl1_VisibleChanged(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.VisibleChanged

      Me.Size = New Size(100, 100)

   End Sub

3) Build the project so the usercontrol appears on the toolbox.

4) Add the usercontrol to the form and set its Dock property to Fill.

5) Build the project again

6) Close all windows

7) Close the solution

8) Using the Windows Explorer, set the read-only attribute of the Form1*.* files

9) Open the solution again

10) Try to open the Form1.vb file in Design view. You get a prompt to edit the read-only file.

I know it's stupid to set the size of the usercontrol in the VisibleChanged event of a usercontrol that will be docked, but that was what the code was doing in the end ...

So, the solutions are:

1) Stop doing stupid things or...

2) Change the code to the following, so it only executes at run-time:

   Private Sub UserControl1_VisibleChanged(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.VisibleChanged

      If Not Me.Site.DesignMode Then

         Me.Size = New Size(100, 100)

      End If

   End Sub

Is there anything that an add-in can do when it encounters this situation? If VS shows a prompt, there is nothing that an add-in can do. But if VS does a silent check-out, or silently changes the read-only flag of files you can do something: get the read-only value before calling ProjectItem.Open(EnvDTE.Constants.vsext_vk_Designer), get it afterwards, compare them and it they are not the same you can inform the user that there is something wrong in the file or in the controls used in the file, and that the same problem would happen if he opens the designer by hand, so it's not really add-in's fault.

Update (March 11, 2009):

If the file is not read-only, then VS edits it behind the scenes and you get an unexpected prompt to save the changes when closing the solution.

Also, I have found other pattern that reproduces the problem without wrong code:

1) Create a Windows Form project in VS 2008

2) Add a ListBox control to Form1 and set its Dock property to Fill

3) Save the changes, close the windows, and close VS

4) Using Windows Explorer, set the read-only attributes of the three Form1*.* files

5) Open VS and load the solution

6) Try to open the Form1.vb file in Design view. You get a prompt to edit the read-only file.

The strange case of infinite recursion in an add-in severely crashing Visual Studio 2005 and 2008

carlosq — Thu, 12 Feb 2009 12:43:00 GMT

Don't you love when Visual Studio severely crashes? I really hate those moments because I am always afraid that if it is a problem of VS and not a problem in my code, I am in trouble...

Some time ago I explained The strange case of Visual Studio 2008 severely crashing loading an add-in that was caused by Visual Studio commandbars. Fortunately the cause of this problem and a workaround was known.

I also opened a bug report at Microsoft Connect due to Application of custom attribute crashes VS 2008 (VB) still with SP1 applied. This causes a crash in the VB 2008 compiler. While Microsoft closed the report as "not reproducible" I am glad that they have reopened it recently and they sent me some "dumping" tools to install on my computer and send them back more information to get a clue about the problem since it is not reproducible with a few lines of code. Hopefully this one can be fixed because it is preventing me to migrate to VS 2008.

Yesterday I got a new severe crash while debugging my MZ-Tools add-in. The crash was something like:

Problem signature
Problem Event Name: APPCRASH
Application Name: devenv.exe
...
Fault Module Name: kernel32.dll
Fault Module Version: 6.0.6001.18000
Fault Module Timestamp: 4791a76d
Exception Code: e053534f
Exception Offset: 000442eb

Searching the web I only found a similar issue but it didn't explain the cause or fix. The line of code crashing in my code was just setting the value of a class field, which seemed quite innocent. On Windows Vista the dialog didn't offer the chance of sending it to MS but today on a Windows XP machine the dialog allowed me to send the bug report. But more importantly, after more careful debugging I realized that my code was calling the method of a class that called another method, and then other, and then other, and 10 calls later it was calling again the original method, causing an circular dependency that eventually crashed Visual Studio. For example this code reproduces the problem:

public void OnConnection(object application, ext_ConnectMode connectMode, object addInInst, ref Array custom)
{
   switch (connectMode)
   {
      case ext_ConnectMode.ext_cm_Startup:
      case ext_ConnectMode.ext_cm_AfterStartup:
         f1();
         break;
   }
}
void f1()
{
   f2();
}
void f2()
{
   f1();
}

While the fault was in my code (I have already fixed it), I wondered if Visual Studio could show better information, such as an StackOverflowException or OutOfMemoryException or similar (that would give me a hint about a circular dependency) rather than a crash in the kernel32.dll module. And guess what? I did a test and VS.NET 2003 shows a more friendly message with the StackOverflow exception indicating a too deep recursion. Somehow something was changed in VS 2005 and now Visual Studio behaves much worse crashing completely. So I have opened a bug report at Microsoft Connect (you are invited to vote to get it fixed):

Add-in causing stack overflow causes "Microsoft Visual Studio has encountered a problem and needs to close"
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=414301

It happens that I had seen this very same problem in my code a couple of years ago but I had totally forgotten that such crashes in VS are sometimes produced by circular dependencies of methods in the code. I hope this helps other people (and me) when searching on the web a crash in a VS add-in in Exception Offset 000442eb of Kernel32.dll.

The strange case of "%ALLUSERSPROFILE%\Datos de programa\Microsoft\MSEnvShared\AddIns" add-In file path

carlosq — Fri, 16 Jan 2009 07:58:00 GMT

(Or why it is a bad idea for an add-in to add add-in file paths to Visual Studio)

When Visual Studio 2005 introduced XML-based add-ins, which used an .AddIn file rather than COM registration), rather than providing just two fixed folders to place such files (one for all users, other for the current user), Microsoft provided five (5!!) folders, listed in the Tools, Options menu, Environment, Add-in/Macros Security section.

Not only that, Visual Studio allows to add more folders using the Add... button or programmatically writing to the "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\8.0\AutomationOptions\LookInFolders" registry key (VS 2005).

Not only that, you will have a difficult time expanding VS-proprietary placeholders like %VSAPPDATA%, %VSCOMMONAPPDATA% or %VSMYDOCUMENTS%, if your add-in setup wants to use one of those folders.

Not only that, Visual Studio 2008 added a sixth folder, %ALLUSERSDOCUMENTS%\Microsoft\MSEnvShared\Addins.

Not only that, Visual Studio 2008 actually fails to look for XML files in that new folder (see HOWTO: Using the Process Monitor (ProcMon) tool to diagnose Visual Studio add-ins problems)

And not only that (finally), Visual Studio hardcoded "Application Data" in one of the paths ("%ALLUSERSPROFILE%\Application Data\Microsoft\MSEnvShared\Addins") without taking into account that that folder is localized and in other languages it doesn't exist with that name on the hard disk. For example, in Spanish, it is should be "%ALLUSERSPROFILE%\Datos de programa\Microsoft\MSEnvShared\AddIns".

I documented all that in the article INFO: Default .AddIn file locations for Visual Studio add-ins.

Guess what? Yesterday, while writing an utility that scans the add-in file paths, I noticed that on my Spanish computer Visual Studio 2005/2008 listed "%ALLUSERSPROFILE%\Datos de programa\Microsoft\MSEnvShared\AddIns" as one of the add-in file paths in the Tools, Options menu, Environment, Add-in/Macros Security section. Indeed VS 2005 listed 6 folders instead 5, and VS 2008 listed 7 folders instead of 6.

How could that be? At first I thought that the service pack 1 of both IDEs could have "fixed" the problem adding the localized version of that path maintaining the wrong one (with "Application Data" hardcoded). But I quickly discarded that explanation because I had installed SP1 from long time and those folders were not there. Then I remembered that I had installed recently an add-in (I won't cite its name), and looking into the contents of the "%ALLUSERSPROFILE%\Datos de programa\Microsoft\MSEnvShared\AddIns" folder, there was the .AddIn files of this add-in. So, the setup of this add-in is placing the .AddIn file in that folder, AND it is adding that folder to the "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\8.0\AutomationOptions\LookInFolders". In other words, it is trying to "fix" what Microsoft did wrong with that folder. But I think this is a bad idea for this reason: if this add-in is installed on a non-English computer and the user happens to be a developer of add-ins who is unaware of the problem of the hardcoded "Application Data" path, he will see two paths listed:

%ALLUSERSPROFILE%\Application Data\Microsoft\MSEnvShared\Addins
%ALLUSERSPROFILE%\Datos de programa\Microsoft\MSEnvShared\AddIns

And certainly he will use the second one because any non-English developer knows that it is the correct one (using an API call to get the actual localized folder), but when his add-in is installed on another machine, the second path is not in the list of paths that VS scans, and the add-in won't appear in the Add-In Manager.

Placing the .AddIn file in the first path (%ALLUSERSPROFILE%\Application Data\Microsoft\MSEnvShared\Addins) is also a bad idea because the setup will create that English folder on non-English computers, and then the computers will have those two paths physically on the hard disk.

So, what to do? I'd recommend to use the "%VSCOMMONAPPDATA%\AddIns" folder instead, which is also for all users but it neither mess the list of paths of Visual Studio nor creates English folders on non-English computers. The only drawback is that the folder is actually different each VS version:

For Windows XP:

VS 2005: "C:\Documents and Settings\All Users\Application Data\Microsoft\VisualStudio\8.0\Addins"

VS 2008: "C:\Documents and Settings\All Users\Application Data\Microsoft\VisualStudio\9.0\Addins"

For Windows Vista:

VS 2005: "C:\ProgramData\Microsoft\VisualStudio\8.0\Addins"

VS 2008: "C:\ProgramData\Microsoft\VisualStudio\9.0\Addins"

To get it programmatically the custom action of your setup that copies the .AddIn file must call the API that returns special folders with the parameter CSIDL_COMMON_APPDATA and then concatenate "Microsoft\VisualStudio\8.0\Addins" for VS 2005 or "Microsoft\VisualStudio\9.0\Addins" for VS 2008. For example:

Using the .NET Framework the call is System.Environment.GetFolderPath(System.Environment.SpecialFolder.CommonApplicationData)

Using the free InnoSetup installer, the PascalScript call is ExpandConstant('{commonappdata}') (see: HOWTO: Create a setup for a Visual Studio 2005 / 2008 add-in using Inno Setup)

Using the Win32 API, you can use the SHGetFolderLocation, SHGetFolderPath, SHGetSpecialFolderLocation, and SHGetSpecialFolderPath functions.

Being the path different for each VS version you can't use a single .AddIn file with two hosts inside (HostApplication tags) for VS 2005 and VS 2008, but that's a minor extra work for the setup of an add-in, and we all know that software is all about our users, not about us the developers...

The strange case of Visual Studio 2008 severely crashing loading an add-in

carlosq — Wed, 10 Dec 2008 13:09:00 GMT

Some months ago a customer of my MZ-Tools add-in reported a crash in Visual Studio 2008 Team Suite when loading it. When an add-in crashes loading it, usually Visual Studio captures the exception or COM error and shows a semi-friendly messagebox indicating that the add-in has caused an exception or failed to load, and give you the chance of removing it. While sometimes the error is <Unknown Error> and you get only the error number (specially if the problem is found by the CLR loading the add-in and not executing the code), this crash was more severe: "Visual Studio needs to close", and your only options are to close or to restart. MZ-Tools doesn't have instrumentation yet, but after a couple of custom builds with traces sent to the customer I was able to determine that the problem happened creating the very first toolbar. Somehow the customer changed to Visual Studio 2008 Professional Edition and the problem disappeared so I closed the incident (falsely).

Last week it was a prospect who experienced the severe crash. It is not the best experience for a prospect to download a trial version of your product, install it and get such a crash. I knew that for such severe crashes the problem is not really my add-in but the prospect would think otherwise... Since the add-in is marked to load on startup, it crashes VS every time so chances are that he will uninstall and forget the product. But fortunately he reported it to me, so I troubleshooted it. After a couple of days verifying that the problem was actually MZ-Tools and not other extensions, that the referenced assemblies were present and that the versions were correct, I recalled this problem, that I had almost totally forgotten. I retreived the e-mails of the previous case, and the problem happened with VS 2008 Team Suite also this time. And when I was about to send him a minimal add-in that creates a toolbar to reproduce the problem, I searched the web and I found this post by Jamie Cansdale, former MVP colleague and author of TestDriven.NET (formerly NUnitAddIn):

VS 2008 crashes on startup when 'Code Analysis Tools' feature is not installed
http://weblogs.asp.net/nunitaddin/archive/2007/11/29/vs-2008-crashes-on-startup-when-code-analysis-tools-feature-is-not-installed.aspx

So, the problem happens in Visual Studio 2008 Team Suite if you don't install the "Code Analysis Tools". Since in the first case the user switched to Visual Studio 2008 Professional Edition, which doesn't include the Code Analysis Tools (only Visual Studio 2008 Development Edition or Visual Studio 2008 Team Suite), the problem disappeared. In the second case, the prospect run the setup again and certainly the Code Analysis Tools were not installed. After installing them, MZ-Tools loaded fine.

Now, I have tried to reproduce the problem to report it to Microsoft to no avail:

My computer has Visual Studio 2008 Team Suite with the Code Analysis Tools and SP1. I have removed the Code Analysis Tools and the problem doesn't appear. I have removed the SP1 and nothing. I have removed VS 2008 completely and I have installed it from scratch without the Code Analysis Tools and the problem doesn't appear. So, I don't know yet how to reproduce but at least I am glad that I know how to solve it and hopefully I won't forget it again (I'll force myself to check the "The strange case of ..." series for those rare problems...)

I have also updated this article:

HOWTO: Troubleshooting Visual Studio and Office add-ins
http://www.mztools.com/articles/2007/MZ2007009.aspx

UPDATE (Dec 11, 2008): Finally I have reproduced the problem with a clean virtual machine and Visual Studio 2008 Development Edition without the "Code Analysis Tools" and without installing SP1. The problem happens when an add-in performs certain operations with commandbars of DTE such as:

Trying to create a toolbar

Trying to retrieve an inexistent command bar

Trying to set the Name property of a Commandbar

Maybe others

The problem can be solved through two ways:

Installing the missing "Code Analysis Tools" component

Installing Service Pack 1

While not many users are affected by this bug since most of them perform a full installation of Visual Studio 2008 and/or install SP1, the problem is so nasty that you may want to detect this circumstance and show a warning when loading your add-in. Something like the following in the OnConnection method before manipulating CommandBars:

If IsVS2008TeamSuite() Or IsVS2008DevelopmentEdition() Then

If Not IsCodeAnalysisToolsComponentInstalled() Then

If Not IsVS2008SP1Installed() Then

MessageBox.Show("This add-in is going to crash :-(")

End If

Some details to implement those functions:

You can detect if VS 2008 SP1 is installed using the registry key:

- HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\DevDiv\VS\Servicing\9.0\VSTS\<locale>, name "SP" for VS 2008 Team Suite

- HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\DevDiv\VS\Servicing\9.0\VSTD\<locale>, name "SP" for VS 2008 Development Edition

Where <locale> is the language of Visual Studio, such as 1033 for English, 3082 for Spanish, etc. Your add-in can get the locale of IDE using the DTE.LocaleID property.

The SP value can be 0 (no SP installed) or 1 (SP1 installed)

You can detect if VS 2008 Team Suite installed if the registry key "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\9.0\Setup\VS\VSTS" exists

You can detect if VS 2008 Development Edition installed if the registry key "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\9.0\Setup\VS\VSTD" exists

You can detect if the "Code Analysis Tools" component is installed getting the folder of VS 2008 (reading the "ProductDir" name under the registry key above), appending "Team Tools\Static Analysis Tools\FxCop" and checking if the file FxCopSdk.dll exists or not.

Notes:

VS 2008 without SP1 lacks the folder "Team Tools\Static Analysis Tools\FxCop" if Code Analysis Tools are not installed (as expected)

VS 2008 SP1 creates that folder even if you don't have Code Analysis Tools installed, but it doesn't add DLLs, just some Repository\Compatibility folder with some XML files

The strange case of toolwindow not showing when the add-in is loaded on startup

carlosq — Tue, 02 Dec 2008 08:56:00 GMT

Visual Studio preserves the visibility state of its own toolwindows (Solution Explorer, etc.) but not of toolwindows created by add-ins. It is up to the add-in to store the state of its toolwindows when unloaded, and restore them when it is loaded again. So, some add-ins can show their toolwindows when loaded and not only when the menu to show them is invoked. However, some developers are noticing that in some cases toolwindows don't show when the add-in is loaded on startup, but they show if the add-in is loaded by hand using the Add-In Manager. If this is the case, chances are that it is because you are not using the OnConnection method correctly and the IDE is not fully initialized when the add-in is trying to show its toolwindow:

HOWTO: Use correctly the OnConnection method of a Visual Studio add-in
http://www.mztools.com/articles/2008/MZ2008004.aspx

This is just one of the many side effects of a badly designed IDTExtensibility2 interface that populates the MSDN forum with related questions every week...

The strange case of add-in setup not detecting running instances of Visual Studio 2008 on Windows Vista

carlosq — Mon, 01 Dec 2008 12:18:00 GMT

If you are creating a setup for your Visual Studio add-in, chances are that you don't want running instances of Visual Studio when the add-in is going to be installed or uninstalled. For my MZ-Tools add-in, I use the free InnoSetup, which is script-based and uses Pascal for custom code, and I wrote an article some time ago about how to create a setup for a Visual Studio add-in using InnoSetup.

A couple of weeks ago I noticed something strange: when running the setup on Windows Vista, it detected running instances of Visual Studio .NET 2002, 2003 and 2005, but not of Visual Studio 2008. Actually, I detected the problem on Windows 2008 Server with the Visual Studio 2010 CTP, but I was able to reproduce the problem with Windows Vista and Visual Studio 2008.

The setup detects running instances of Visual Studio by using the GetActiveOleObject function for the ProgID of each Visual Studio version ("VisualStudio.DTE.7", etc.):

function IsVSRunningByProgID(ProgID: String):Boolean;
var
   IDE: Variant;
begin

   try
      IDE := GetActiveOleObject(ProgID);
   except
   end;

   if VarIsEmpty(IDE) then
      Result := False
   else
      Result := True
end;

The GetActiveOleObject function returns a running (if any) COM (ActiveX) server given a ProgId. Somehow it was failing for Visual Studio 2008 whose ProgId is "VisualStudio.DTE.9.0". I tried to reproduce the problem with a VB6 program using the GetObject function, and it worked, but I soon realized that the GetObject function of VB6 always return an instance: if none is running, it creates one.

Incidentally, the setup worked as expected on Windows XP so I suspected that the User Account Control (UAC) of Windows Vista (and Windows Server 2008) could be the culprit. And the final detail was that while Visual Studio .NET 2002, 2003 and 2005 require by default admin rights (so you get a "consent prompt" from the UAC of Windows Vista), Visual Studio 2008 was designed to run without admin rights, so it launches without "consent prompts" on Windows Vista, running as a standard user even if you are an administrator. Searching on the InnoSetup forums, I confirmed that on Windows Vista a process running with elevated priviledges (such as my setup) cannot interact with a COM process running with low priviledges (such as Visual Studio 2008), so the GetActiveOleObject call fails ("Operation unavailable") and no instance is returned, as if no instance was executing. In fact, the setup worked as expected if I run Visual Studio 2008 as an administrator (using the context menu) and getting the "consent prompt" of the UAC.

So, which is the solution for this problem? The forums mentioned something about mutexes or something that I am not willing to investigate, because sometimes when you devote a lot of time to a tough problem you realize that you don't have a problem actually, or that it is not so severe. For example, an add-in can be installed perfectly even with Visual Studio running, it just needs to copy some files and add some registry entries. Its toolbar and menus won't appear in the running instances of Visual Studio but if the user goes to the Add-In Manager, it will be there. There is only a problem when uninstalling the add-in, because removing the commands (and permanent UI if used) requires to persist the changes and if there is a running instance of Visual Studio the changes will be overwritten when this other instance is closed. But I guess I'll have to live with that.

For applications that are not setups, such as applications automating the IDE (or for setups that allow you to execute .NET code), you can use System.Diagnostics.Process.GetProcessByName("devenv") and it will work.

The strange case of 8013141A loading a Visual Studio add-in

carlosq — Fri, 28 Nov 2008 08:37:00 GMT

A developer posted a couple of days ago in the MSDN forum about Visual Studio Extensibility that loading his add-in caused and exception with error number <Unknown Error> (8013141A). Of course, searching with Google doesn't always offer much information about these bizarre errors, nor the tools of the Windows SDK for which this error is, well, unknown too.

Since the section of my article about troubleshooting crashes in add-ins didn't help much, I have enhanced it with further and more detailed explanations, and a mention to this error:

HOWTO: Troubleshooting Visual Studio and Office add-ins
http://www.mztools.com/articles/2007/MZ2007009.aspx

The strange case of empty Add-In Manager (not showing XML-based add-ins)

carlosq — Tue, 04 Nov 2008 09:02:00 GMT

There is a problem that I have never experienced but it was happening for a few people in Visual Studio 2005 / 2008. The symptoms were:

- The Add-In Manager is empty
- The Add-In only shows registry-based add-ins, not XML-based add-ins (using an .AddIn file)

Of course the first difficulty was to notice that the problem happened to several add-ins, not only a specific add-in. When you don't see your add-in in the Add-in Manager, the first thought is that your add-in is not correctly registered, specially because folders to put the .AddIn file are a bit tricky, as I explained in the article INFO: Default .AddIn file locations for Visual Studio add-ins (COM-registration is also tricky, BTW).

Using a file-monitoring tool like Process Monitor revealed that Visual Studio actually found .AddIn files, so there was no registration problem.

After almost one year with this problem unsolved, someone discovered yersterday the cause: a bad installation of MSXML 6.0, which apparently is used by Visual Studio to read the actual contents of the XML .AddIn files used by add-ins. After uninstalling MSXML 6.0 and installing the latest MSXML 6.0 SP1 the problem was solved. Here is the whole discussion thread with the problem:

VS 2008: Add-In Manager is empty
http://social.msdn.microsoft.com/Forums/en-US/vsx/thread/6778e3a2-2783-4826-a5f2-7089e1c8fb90

I have updated my article:

HOWTO: Troubleshooting Visual Studio and Office add-ins
http://www.mztools.com/articles/2007/MZ2007009.aspx

I would be nice if Visual Studio showed an error message rather than failing silently when parsing .AddIn files, and better yet, used the XML parser of the .NET framework rather that depending on an external component.

The strange case of no ext_ConnectMode.ext_cm_UISetup phase fired, not even once

carlosq — Tue, 14 Oct 2008 10:14:00 GMT

Continuing today with some tests about the The OnConnection method and ext_ConnectMode.ext_cm_UISetup of Visual Studio add-ins of my last post, I created a sample add-in using the code of the first sample (temporary UI) of my article HOWTO: Adding buttons, commandbars and toolbars to Visual Studio .NET from an add-in, and later I changed my mind to use the ext_ConnectMode.ext_cm_UISetup phase using the second sample. To my surprise, the ext_ConnectMode.ext_cm_UISetup phase was never fired, not even once, despite the fact that debugging the add-in should fire it each time because of the /resetaddin command-line flag in the Start Options of the Debug tab of the project properties window.

Opening a command prompt window to use devenv.exe /resetaddin MyAddin.Connect caused no effect too. So, I started to get paranoid about the VS 2008 SP1 that I installed some weeks ago. Could it be possible that it broke the behavior somehow? Unfortunately no, the cause was other: in order to Visual Studio calls the OnConnection method of your add-in with the ext_ConnectMode.ext_cm_UISetup phase, your add-in registration must specify that it wants "CommandPreload", a flag in the registry (COM registration) or tag in the .AddIn file (XML registration). Otherwise Visual Studio doesn't bother to load add-ins that haven't requested the ext_ConnectMode.ext_cm_UISetup phase. When you use the add-in wizard to create an add-in project, the page 4 of 6 has a checkbox:

"Yes, create a "Tools" menu item. By default this will cause the Add-in to load when the button is clicked unless the Add-in is set to load on startup of the host application."

that you must check for the wizard to set that "CommandPreload" flag. I totally forgot this flag and it happens that since I always delete the whole code of the Connect class generated by the add-in wizard because I don't like the code that it creates, most of the time I don't bother to check that checkbox to delete less code... so, if you change your mind about whether you want ext_ConnectMode.ext_cm_UISetup phase or not in your add-in, it is not enough to change the code of your OnConnection method, you need to pay attention to that flag, either to get the ext_ConnectMode.ext_cm_UISetup phase, or to optimize your add-in preventing to load it for a phase that it won't use...

The strange case of "No such interface supported" (Error 80004002) loading a Visual Studio add-in

carlosq — Mon, 29 Sep 2008 13:02:00 GMT

Some days ago I received an angry complaint from a prospect of the trial version of my MZ-Tools add-in, who uninstalled it because, somehow, he didn't want the add-in loaded at startup during the evaluation period but he wanted to load it manually...(read more)

The strange case of System.BadImageFormatException: Could not load file or assembly 'Microsoft.mshtml'

carlosq — Wed, 23 Jul 2008 07:16:00 GMT

A couple of days ago another customer of my MZ-Tools add-in reported this exception: "System.BadImageFormatException: Could not load file or assembly 'Microsoft.mshtml, Version=7.0.3300.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'...(read more)

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

carlosq — Fri, 13 Jun 2008 08:05:00 GMT

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...(read more)

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

carlosq — Sun, 08 Jun 2008 21:14:00 GMT

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...(read more)

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

carlosq — Thu, 22 May 2008 08:03:00 GMT

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...(read more)