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
http://www.mztools.com/articles/2007/MZ020.htm
This question appears from time to time in forums, so I wrote an article about it:
HOWTO: Initializing new events in Visual Studio macros
http://www.mztools.com/articles/2007/MZ019.htm
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
http://msdn2.microsoft.com/en-us/library/ms228948(VS.80).aspx
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
http://www.mztools.com/articles/2007/MZ018.htm
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
http://www.mztools.com/articles/2007/MZ017.htm
It seems that as I learn more and more about the IDE services (VS SDK) and how to call them from an add-in, I can’t stop playing with them and wondering if I can solve problems that previously seemed unsolvable. One of them, very old, was how to get the Guid of the project subtype, to identify Test projects (for example), a problem that I posted long time ago in the MSDN VSX forum and I got a partial answer. What I really wanted is, given an EnvDTE.Project, get all its project type/subtype Guids, without using convoluted code. Yesterday I found a promising solution by another MVP, Daniel Cazzulino, but I was not completely satisfied having to read the .vbproj or .csproj files to get the Guid of the project (not to be confused with the Guid of the project type) in order to get the IVsHierarchy object, which is the key piece here to cast it to IVsAggregatableProject and call the GetAggregateProjectTypeGuids method. Finally I got inspired and thanks to the EnvDTE.Project.UniqueName property you can get the IVsHierarchy object calling IVsSolution.GetProjectOfUniqueName. I wrote the detailed solution in this article:
HOWTO: Get the project flavor (subtype) of a Visual Studio project from an add-in
http://www.mztools.com/Articles/2007/MZ016.htm
Although I am happy with the new world of IDE services called from add-ins, it is a somewhat bittersweet feeling: on the one hand it is great to be able to call them from an add-in, but, on the other hand, I can’t help thinking that add-ins are second-class citizens in the VS extensibility and that a lot of functionality is not directly available to them and you have to use the complex and intimidating SDK… I wish there was a single, simple, unified and managed (.NET) approach. Do you feel the same? I hope your comments about it.
As I posted in a previous blog entry, where I explained how to reference an assembly in the GAC from an add-in, here is the article explaining how to get a Visual Studio service from an add-in:
HOWTO: Get a Visual Studio service from an add-in
http://www.mztools.com/articles/2007/MZ015.htm
The extensibility model for Visual Studio add-ins sometimes is not enough to meet your needs and you need some service from a Visual Studio package, but you don’t want to transform your add-in into a VSPackage, you just want to get some service only available to VS packages. I will blog about it in another post, but the first thing to understand is that you don’t need in many cases to install the Visual Studio SDK (or VSIP in previous versions) since some assemblies are in the GAC or other Visual Studio folders. If you have the assembly and the SDK documentation (available online), you don’t need to get your computer “dirty” with the SDK or CTPs, etc.
The problem is how to reference assemblies that seem to be only in the GAC (such as Microsoft.VisualStudio.OLE.Interop). You can’t really reference an assembly in the GAC but here is a workaround:
HOWTO: Reference a Visual Studio assembly in the GAC from an add-in
http://www.mztools.com/Articles/2007/MZ012.htm
It is said that it takes three iterations to make a software application right and it seems to be correct: it was not until Visual Basic 3.0 when people started to use it in serious applications, it was not until MZ-Tools 3.0 when my add-in was widely used and it was not until .NET Framework 2.0 (which is actually the 3rd iteration after versions 1.0 and 1.1) when Microsoft did it right with .NET Data Providers, making it possible to use provider factories and base classes to write database-independent code. If I was fascinated with source code control providers as I posted recently, I am even more fascinated with data providers, since the times of ODBC around 1995. It happens that for my first job I had to learn Visual Basic 3.0 and ODBC in two weeks…and before becoming interested in the extensibility of IDEs around 2000, I was an expert in ODBC/OLEDB technologies, maybe some of you still remember me in the ODBC newsgroups around 1997-1999… anyway, to the point:
You may have noticed that Visual Studio .NET 2002 and 2003 used OLE DB providers and not the new ADO.NET data providers in the Data Connection dialog of the Server Explorer. Inexplicably, despite the previous experience with ODBC and OLEDB, Microsoft did not provide a standard way to enumerate .NET data providers or to show a standard connection dialog in .NET Frameworks 1.0 and 1.1. It was in .NET Framework 2.0 when the new ADO.NET 2.0 providers provide connection string builders, connection factories, etc. You can learn more about it in What’s new in ADO.NET 2.0. Visual Studio 2005 leverages the new capabilities of ADO.NET 2.0 providers and in turn provides good extensibility to use any ADO.NET 2.0 data provider in the data design-time experience of the IDE, thanks to the Data Designer Extensibility (DDEX). Using DDEX Visual Studio 2005 provides a new Data Connection dialog based on ADO.NET providers, not OLEDB providers. You can read a very good Introduction to Visual Studio Data Designer Extensibility (DDEX) and then you can read the DDEX SDK documentation. With DDEX you can make any ADO.NET 2.0 provider appear in the data connection dialog as explained in those links. Also, you can use that dialog from your own code (an add-in or VS package) and since this is a common question but it does not seem to be addressed in the documentation, I have written an article about it:
HOWTO: Using the Choose Data Source dialog of Visual Studio 2005 from your own code
http://www.mztools.com/articles/2007/MZ011.htm
A common question that appears in forums from time to time is how to guess the type of a project (Windows, Web Application, Web Site, Smart Device, Class Library, Console, etc.). The answer is not so simple and you have to check several properties. I have explained it in my this article:
HOWTO: Guess the type of a Visual Studio project from an add-in or macro
http://www.mztools.com/articles/2007/MZ014.htm