If you have tried to create an add-in with the wizard in the March 2007 CTP of Visual Studio “Orcas”, you will have noticed that when you try to debug the add-in, it is not loaded. In fact, it does not appear in the Add-In Manager of the second instance of Visual Studio. This is because this CTP still places the .AddIn linked file (the one with the little arrow in the Solution Explorer) in the folder “C:\Documents and Settings\<user>\My Documents\Visual Studio 2005\AddIns”. To solve it:
- Create the folder “AddIns” inside the folder “C:\Documents and Settings\<user>\My Documents\Visual Studio Codename Orcas” (by default it is not created).
- Move the .AddIn file to that folder.
- Remove the linked file from the Solution Explorer and add it pointing to the new location.
When you want to know programatically the IDE mode (design, debug or run-time) it happens that the DTE.Mode property returns only two of the three possible modes (I don’t know why Microsoft omitted the Run Mode in the vsIDEMode enum). In this article I explain how to distinguish among the three modes:
HOWTO: Guessing the IDE mode (design, debug or run-time) from a Visual Studio add-in or macro
This question appears from time to time in forums, so I wrote an article about it:
HOWTO: Initializing new events in Visual Studio macros
When it was already written I discovered that a very similar one appears in the MSDN docs:
How to: Create an Event Handler in a Macro for a Specific Type of Project
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.
This is another article that I wanted to write long time ago and now that I discovered how to get a service from a Visual Studio add-in and the Data Design Extensibility (DDEX) SDK, I have written it today. It is a question that keeps appearing in the forums:
HOWTO: Get data sources, data providers and data connections from a Visual Studio 2005 add-in
When you are looking for a property using Properties.Item(“property_name”) and you don’t know the property_name, this article may come handy:
HOWTO: Guess the names of a Properties collection from a Visual Studio add-in or macro