Monthly Archives: February 2010

VS 2010

VS 2010 and the macros IDE

Although not very usual, add-ins can be created for the Macros IDE too. In fact, version 6.0 of MZ-Tools integrates with the VS IDE and with its macros IDE. I will remove support for the macros IDE in future versions because I think that nobody needs/uses it and it complicates the code and the setup (specially the uninstallation), but until then, it works with both IDEs.

While the VS IDE executable is devenv.exe, the macros (VSA) IDE is vsaenv.exe. From the automation (EnvDTE) point of view, the EnvDTE.DTE class has the EnvDTE.DTE.MacrosIDE() As EnvDTE.DTE property.

Until VS 2010, each VS IDE has its own macros IDE with matching versions. However, VS 2010 (VS 10.0) actually uses the VS 2008 Macros IDE (VSA 9.0), as you can see by the look and feel (not WPF-based) and in the About window.

VS 2010

No longer possible to create comboboxes on commandbars of VS 2010 through automation (EnvDTE), only through packages

1 Comment

Joginder Nahil (from Starprint Tools) has notified me about a breaking change that I was not aware in the new WPF-based commandbars of VS 2010: the lack of support to create comboboxes on commandbars. I have been fortunate enough to avoid the need to use that UI item in my MZ-Tools add-in (I haven’t even written an article about this), but I was aware that comboboxes and MRU lists were possible since VS 2005 because of this old post of Craig Skibo (former member of the automation team of Visual Studio):

Command Bar Types – Part 2
http://blogs.msdn.com/craigskibo/archive/2005/10/20/483133.aspx

Now, in VS 2010 comboboxes are no longer creatable through automation (EnvDTE), only through packages (SDK). Here is the report:

Exception DeprecatedException occurs when adding a combobox to vs2010 IDE toolbar
https://connect.microsoft.com/VisualStudio/feedback/details/532817/exception-deprecatedexception-occurs-when-adding-a-combobox-to-vs2010-ide-toolbar

Thanks Joginder, and I am sorry the bad news.

MZ-Tools Articles Series

Getting properties from the DTE.Properties collection

I have updated an article that I wrote back in 2005:

HOWTO: Getting properties from the DTE.Properties collection of Visual Studio .NET.
http://www.mztools.com/articles/2005/MZ2005008.aspx

And the reason is that I have found lately that guessing the names of properties to index DTE.Properties(category, page) is not as easy as reading the MSDN documentation (whose list may not be up-to-date) or using regedit.exe to inspect the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\<version>\AutomationProperties registry entry. Specifically I have found that:

– There is no way through automation (EnvDTE) to get the C# formatting options that were introduced by VS 2005.

– Text Editor XAML settings are not exposed through DTE.Properties in VS 2008 but they are in VS 2010 (something that the MSDN docs don’t reflect yet and I doubt they will)

– Text Editor XOML settings are not exposed through DTE.Properties even in VS 2010.

I guess that some SDK service can get that information, or maybe it is something not exposed by the owner package of those settings. So I am using the other way, which is to read directly the actual property values from the HKEY_CURRENT_USER hive. But it is also tricky, because the term “TextEditor” can become “Text Editor”, “PlainText” can become “Plain Text” and the C# formatting settings seem to be updated only when VS closes and not when the Options dialog is closed (and they seem to appear only if they differ from the defaults)…

Other

Different template names for text files in C# and VB.NET to use with Solution2.GetProjectItemTemplate

When you execute the following macro that gets the file templates for classes, forms and text files in C# and VB.NET:

Sub Macro1()

   Dim objSolution2 As EnvDTE80.Solution2

   objSolution2 = CType(DTE.Solution, EnvDTE80.Solution2)

   MsgBox(objSolution2.GetProjectItemTemplate("Class.zip","VisualBasic"))
   MsgBox(objSolution2.GetProjectItemTemplate("Form.zip", "VisualBasic"))
   MsgBox(objSolution2.GetProjectItemTemplate("Text.zip","VisualBasic"))

   MsgBox(objSolution2.GetProjectItemTemplate("Class.zip", "CSharp"))
   MsgBox(objSolution2.GetProjectItemTemplate("Form.zip", "CSharp"))
   MsgBox(objSolution2.GetProjectItemTemplate("Text.zip", "CSharp"))

End Sub

It fails for the 6th case:

objSolution2.GetProjectItemTemplate("Text.zip", "CSharp")

I thought it was a bug but it happens that the symmetric beauty of the code is broken because the actual name for the C# case is “TextFile.zip”, not  “Text.zip”:

objSolution2.GetProjectItemTemplate("TextFile.zip", "CSharp")

It seems that C#/VB.NET parity didn’t reach this point yet 😉

VS 2010

VS 2010 RC problems with CommandBar.RowIndex to position toolbars

1 Comment

These are two “minor” bugs that the new WPF-based commandbars of Visual Studio 2010 are going to have since won’t be fixed in this release:

VSIP: VS 2010 Dec LCTP: toolbar with CommandBar.RowIndex = -1 not created in new row
https://connect.microsoft.com/VisualStudio/feedback/details/518455

VSIP: VS 2010 Dec LCTP: CommandBar.RowIndex of toolbar not updated after creating and making it visible
https://connect.microsoft.com/VisualStudio/feedback/details/518452

If your add-in uses more than one toolbar, it can affect you. I found a workaround using big values for the RowIndex property rather than -1 to ensure that the toolbars appear below existing toolbars.

VS 2010

VS 2010 RC: EnvDTE.FontsAndColorsItems.Item(textEditorItem).Background returns 0 instead of actual background color

This is another issue that I can now make public since it won’t be fixed and I guess that VS 2010 RC has it too:

EnvDTE.FontsAndColorsItems.Item(textEditorItem).Background returns 0 instead of actual background color
https://connect.microsoft.com/VisualStudio/feedback/details/518919

This can affect you if your add-in uses RichTextBoxes to colorize code simulating a code window.

I think that VS 2010 uses the correct behavior, while VS 2008 used the convenient behavior…

VS 2010

VS 2010: Shift key no longer preventing the loading of add-ins (by design)

In VS 2005 and 2008 (but not in VS.NET 2002 or 2003), you could press the Shift key while VS was being launched to prevent the loading of add-ins that were marked to load on startup. This was very useful for developers of add-ins to prevent the following issue:

PRB: ‘Could not copy temporary files to the output directory’ error building Visual Studio .NET add-in.
http://www.mztools.com/articles/2005/MZ2005013.aspx

On Windows 7 and its new bar to launch/show running applications, the Shift key is used to launch a new application, so Microsoft removed that behavior of VS 2010. I reported it when I noticed it in the Jan LCTP build. The report is here:

VSIP: VS 2010 Jan LCTP: Shift key doesn’t prevent loading add-ins when VS is launched
https://connect.microsoft.com/VisualStudio/feedback/details/526271

The workaround is to use the /SafeMode command-line switch, I updated the article above.

VS 2010

VS 2010 RC: possible problem installing add-in for VS 2010 when VS 2010 is not installed yet

This is something that happened me three days ago when I installed VS 2010 RC for the first time. I have tried to reproduce it several times to no avail, so I haven’t opened a Microsoft Connect report. FWIW, I will post here what happened just in case some of you want to test.

First, some background: when you develop an add-in for commercial or freeware use (not for in-house) chances are that you want to target multiple Visual Studio IDEs, ideally with the same binary DLL, just registering the add-in for several hosts. For example, an add-in built using CLR 2.0/.NET Framework 2.0 can target VS 2005, VS 2008 and VS 2010 (even if VS 2010 doesn’t install CLR 2.0/.NET 2.0 but CLR 4.0 / .NET 4.0). When the setup of the add-in is run, it can do two things:

  • To install the add-in and register it only for the actual IDEs that are present on the machine. In this case, if the user later installs a new IDE version (supported by the add-in), he would be forced to run the setup again to get the add-in registration for that new IDE version.
  • To install the add-in and register it for all the IDEs supported, even if they are not installed.
    • For COM registration this dirties a bit the registry creating keys like HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\10.0\Addins\<addin> that should not be there if VS 2010 (10.0) is not installed yet, so I don’t like this very much.
    • For XML registration, it happens that you can have a single .AddIn file in a location whose content specifies multiple hosts, so you don’t dirty anything targeting IDEs that are not installed yet. When the user installs a new IDE, the next time that he launches it the add-in will be there. No need to re-run the add-in setup. This is cool and this is the scenario where the problem happened with VS 2010 RC, but only once.

I had a new version of my MZ-Tools add-in that uses XML registration and targets VS 2005, 2008 and 2010 using a single XML .AddIn file, and it is marked to load on startup, and then I installed VS 2010 RC for the first time in that particular machine. The installation went OK, and when I launched VS 2010 RC for the first time, VS showed the usual message asking for a profile and indicating that it was initializing for first use, which could take a few minutes. The add-in was loaded two (I know because it shows a welcome kind of message).

When VS 2010 RC was done, I noticed that most of the user interface of my add-in was duplicated: two main menus (one of it disabled), two toolbars, etc. I went to the Add-in Manager and unloaded it, which caused a crash in VS and finally I was able to delete by hand the toolbars, menus, etc. Once cleaned, next times the add-in loaded well as expected.

I don’t know for sure what happened there, but it seems as if VS 2010, as part of its initialization, tried to persist the menus, toolbars and buttons of my add-in (that uses temporary UI) on disk as it does with packages and add-ins that use permanent UI. So the IDE ended with duplicated UI.

To reproduce the problem, I thought that the same thing would happen if I created another user account and launch VS 2010 for that user, since VS will need to ask profile, initialize user settings, etc. But I was unable to reproduce the issue.

Then I went the long route of installing VS 2010 RC on virtual machines with the add-in already registered, and I was unable to reproduce it too.

So, I don’t know if it is a timing issue (when the add-in is loaded and when VS persists UI on disk) or what… but I know what I saw and there is a bug somewhere there…as I explained in other posts, VS doesn’t take much into account that buttons can belong to add-ins that use a temporary UI, not always to packages or add-ins using permanent UI.

To play safe maybe I will change the setup to not register the add-in for IDEs not installed yet, but I am almost sure that the problem should happen too if the VS is launched by a new user on the same machine

I hope this helps. Let me know if you encounter this issue to reproduce it and send it to Microsoft.

VS 2010

VS 2010 RC: Data Links button on Add Data Source dialog causes AccessViolationException

I noticed yesterday that an enhanced version of the ADO.NET Connection Assistant feature of my MZ-Tools add-in causes an exception for OLEDB connection in VS 2010 RC, not in VS 2008 or 2005. After a couple of hours debugging and trying to figure out why, I finally noticed that VS 2010 RC also suffers that problem in its own Add Data Source dialog. Here it is the bug report:

Data Links button on Add Data Source dialog causes AccessViolationException

https://connect.microsoft.com/VisualStudio/feedback/details/534307/

Other

I’m back

2 Comments

In the last couple of weeks two important things happened: after several secret LCTPs, Microsoft released a new public build of VS 2010 (the Release Candidate), and… I got married 🙂 I spent the honeymoon at Argentina, which has arguably the most impressive natural wonder of planet Earth (the Iguazu Falls), and impressive glaciers too (Perito Moreno). And if you like to eat meat, the beef is superb. Definitely a very recommendable traveling destination.

I have just downloaded VS 2010 RC and I am installing it. I don’t expect many changes from previous LCTPs since the focus of this build was only performance fixes, but it is a big change from the last public build (Beta 2), which was unusable for add-ins due to commandbar bugs (that I blogged a lot about in last months). All the critical bugs that I reported were fixed in LCTPs but not the minor bugs. I will change to “public” my private bugs to Microsoft for my next posts but basically VS 2010 will be a release with some bugs relating its new WPF-based commandbars. I was able to workaround most of them so Microsoft told me that they would prefer not to fix them, to avoid the risk of breaking something else.