Traditionally the VSLangProjXX.dll files contain interfaces such as VBProjectPropertiesX, CSharpProjectConfigurationPropertiesY and VSLangProj90.dll contains them but it seems that it was forgotten to add properties to them:
BUG: Empty interfaces in VSLangProj90.dll
http://www.mztools.com/articles/2008/MZ2008018.aspx
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 🙂
I have been struggling during the last day to get a list of actual project type Guids (EnvDTE.Project.Kind property), since not all the Guids that appear in the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\<version>\Projects registry key are actual project type Guids that appear in project or solution files. Here is the result list:
INFO: List of known project type Guids
http://www.mztools.com/Articles/2008/MZ2008017.aspx
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.
As you may know if you are a C# add-in programmer, DTE events can get disconnected if you don’t hold a class variable pointing to them (VB.NET add-in programmers tend to use the WithEvents approach which already uses a class variable so they don’t suffer this problem). Although this issue is well documented in MSDN, FAQs, blogs, and an article of mine, etc., it was not clear yet for some people why a garbage collection happened if VS holds a reference to the object raising the events. So, I have updated the article to explain it more clearly:
PRB: Visual Studio .NET events being disconnected from add-in.
http://www.mztools.com/articles/2005/mz2005012.aspx
As you may know, while the general Visual Studio automation model uses the EnvDTE DLL series (EnvDTE.dll, EnvDTE80.dll, EnvDTE90.dll), there are some extension DLLs for the automation model of VB.NET and C#, the VSLangProj DLL series (VSLangProj.dll, VSLangProj2.dll, VSLangProj80.dll and VSLangProj90.dll). For more information, see my article INFO: Assemblies used in Visual Studio Extensibility.
Apart from some enums which are handy to interpret values returned from properties, the VSLangProj DLLs contain interfaces such as VSLangProj.ProjectProperties, VSLangProj2.ProjectConfigurationProperties2, VSLangProj80.VBProjectProperties3, etc. whose properties are the names that you can use when calling the EnvDTE.Project.Properties.Item(“XXX”) or EnvDTE.Configuration.Properties.Item(“XXX”).
However, if you look at the VSLangProj90.dll file of VS 2008 with the Object Browser, the VBProjectProperties4, VBProjectConfigurationProperties4, CSharpProjectProperties4 and CSharpProjectConfigurationProperties4 interfaces are all empty. I don’t know the cause, but it seems an oversight, likely they were created and later it was forgotten to add the properties. If there were no properties to add, there was no need to create them, but certainly the automation model of VS 2008 has some new project properties such as “TargetFramework” that do not appear there and that I used yesterday in my article MZ-Tools Articles Series: HOWTO: Get the target .NET Framework of a Visual Studio 2008 project from a Visual Studio add-in or macro.
Today I had to get the target .NET Framework of a VS 2008 project. While the project file stores the values as “v2.0”, “v3.0”, etc, the values returned by the automation model are a bit surprising at first glance. Here is the article that I wrote about this:
HOWTO: Get the target .NET Framework of a Visual Studio 2008 project from a Visual Studio add-in or macro
http://www.mztools.com/articles/2008/MZ2008015.aspx
Just in case you are not aware of this yet (I found a problem related to this today in the MSDN forum), Visual Studio CommandBars don’t have unique names, which means that retrieving a specific commandbar such as “Project” with this code can fail returning a commandbar that you didn’t expect:
DTE.CommandBars.Item("Project")
In fact, there are 3 or 4 commandbar named “Project” in Visual Studio 2005 and 2008, as this macro will show:
Dim sMsg As String
For Each objCommandBar As CommandBar In CType(DTE.CommandBars, Microsoft.VisualStudio.CommandBars.CommandBars)
If objCommandBar.Name = "Project" Then
sMsg = ""
For Each objCommandBarControl As CommandBarControl In objCommandBar.Controls
sMsg &= objCommandBarControl.Caption & Microsoft.VisualBasic.ControlChars.CrLf
Next
MessageBox.Show(sMsg)
End If
Next
The same happen with the “View” commandbar and others.
CommandBars are truly identified by Guid/Id pairs, and Dr.eX posted the workaround to this problem some time ago:
Using IVsProfferCommands to retrieve a Visual Studio CommandBar
http://blogs.msdn.com/dr._ex/archive/2007/04/17/using-ivsproffercommands-to-retrieve-a-visual-studio-commandbar.aspx