Although VS 2015 removed support for add-ins and the Tools > Add-In Manager of past versions was removed, there is still at least one place where its past existence surfaces:
Click the Tools > Customize… menu to show the Customize dialog and click the Commands tab:
Then click the Add Command… button and you will see the Addins item in the Categories list:
I have reported this minor bug on Microsoft Connect.
I have received a couple of issues in the last days from users of my MZ-Tools package, reporting that it keeps disabled, they have to enable it, and when restarting Visual Studio 2015 it happens again.
I haven’t seen that issue, so I could not investigate on my computer, but searching the web I found this post of MVP fellow David Gardiner that explains that the issue can happen to any extension and he provides a solution:
Web Essentials 2015 extension keeps being disabled
So far my users have confirmed the solution. Thanks David!
There is another very strange issue that I saw long time ago but until this week I hadn’t seen it again. It happens when you try to convert a Visual Studio 2010 package project to Visual Studio 2015. The steps to reproduce it are the following:
Interestingly, the problem doesn’t happen if you migrate first the VS Package project from VS 2010 to VS 2012, and then from VS 2012 to VS 2015 (I cannot test with VS 2013 because I cannot install the VS 2013 SDK on Windows 10). It doesn’t happen either if you create the package with VS 2012 and you migrate it to VS 2015.
As I said, I saw this problem for the first time long time ago (I think last year), migrating my own MZ-Tools package. I don’t remember how I solved it, but likely I created a new package with VS 2012 or VS 2013.
This week I received an email about converting the DAX editor for SQL Server, which is VS 2010-based, and whose code is available on CodePlex, to support SQL Server 2016. My first suggestion was to convert the VS package project to VS 2015. When I tried it, I got the error about .vsct file in use by another project. And this time I was decided to investigate the cause.
First, I tried to guess which was the other process that was preventing the Visual Studio process (devenv.exe) to migrate the project. Using Process Monitor or Process Explorer didn’t show any suspect. Being involved the .vsct file, my main suspect was the VS Command Table compiler (vsct.exe) but I couldn’t verify, and I was not sure if that VSCT compiler was involved in the migration phase (definitely it’s involved in the build phase).
Second, I compared patiently each line of the .csproj of the migrated package project with the .csproj of my own MZ-Tools package, removing or changing lines until both were virtually identical. Still the error.
Third, while the error was still shown, I tried to edit the .vsct file with a text editor and save it (successfully) and even rename the file (also successfully), so apparently the .vsct file was not in use at all.
Now what? Suddenly I had the magic idea of replacing the .vsct file of the migrated project by the one of my MZ-Tools package, and this time the project loaded, no longer “unavailable”. So the problem was inside the .vsct file. Again patiently I started to comment/remove sections of the .vsct file, and again and again, and the problem persisted. Eventually, the .vsct file had only 6 lines (the “extern href” lines) and the problem persisted!:
<?xml version="1.0" encoding="utf-8"?> <CommandTable xmlns="http://schemas.microsoft.com/VisualStudio/2005-10-18/CommandTable" xmlns:xs="http://www.w3.org/2001/XMLSchema"> <Extern href="stdidcmd.h"/> <Extern href="vsshlids.h"/> <Extern href="msobtnid.h"/> </CommandTable>
And finally, as soon as I removed the msobtnid.h extern declaration, the problem was solved. That file contains the “Definition of some VSCT specific constants. In this sample we use it for the IDs inside the guidOfficeIcon group”. The VS 2012 package wizard (and higher) no longer includes it in the .vsct file, which explains that migrating a package from VS 2012 to VS 2015 doesn’t suffer this issue. One thing remains: the migration to VS 2015 doesn’t remove that “extern href” (so the problem happens), but does the migration to VS 2012 remove it? The answer is yes, that line is commented after the migration from VS 2010 to VS 2012:
<!--Definition of some VSCT specific constants. In this sample we use it for the IDs inside the guidOfficeIcon group. --> <!--<Extern href="msobtnid.h" xmlns="http://schemas.microsoft.com/VisualStudio/2005-10-18/CommandTable" />-->
So, Microsoft knew about that problem in VS 2012, likely VS 2013 doesn’t suffer the problem either because the package wizard is the same, but somehow they forgot in VS 2015, which uses a different package wizard.
It remains to be explained why the error message is so misleading but my patience with this issue is depleted and now that I know the solution and it’s documented here for other VSX developers I am more than satisfied.
When Microsoft released Visual Studio 2010 with the new WPF-based toolbars and new look and feel, it didn’t update the Macros IDE to follow suit, keeping the same Macros IDE of Visual Studio 2008. Two years later, the Macros IDE was removed from Visual Studio 2012. Add-ins were deprecated in Visual Studio 2013 and removed in Visual Studio 2015. Add-ins are not going back (because they have packages as replacements) but macros didn’t have a simple replacement, and they filled a gap between having nothing and being forced to create an add-in even for the simplest automation task without user interface, that macros could create just recording actions. Add-ins were somewhat overkill for those tasks because even initializing them was tricky, not to mention if you wanted to create commands and buttons (if you have followed this blog all these years you already know). So, it’s not a surprise that the community used UserVoice, one of the channels to provide feedback to Microsoft, to open in 2012 this request to bring back Macros, which has now reached 6,000+ votes. In response, Microsoft created a Macros for Visual Studio extension for Visual Studio 2013 that now not only has been upgraded to support Visual Studio 2015, but also it’s open source. You have the code on GitHub and the official announcement on the Visual Studio blog here.
In my post Visual Studio extensions and DPI-awareness I introduced the basics that you need to know to become DPI-aware. The final step once all the user interface of your extension handles high-DPI gracefully is to provide high-DPI images for the toolbars, as Visual Studio 2015 does since CTP 3. Apparently, support for high-DPI images through a new image service was in the Visual Studio 2015 RTM release, but it hasn’t been until a couple of days ago that Microsoft has published the MSDN documentation. Here you have the resources to learn and use it:
UPDATE (Jan 26, 2016): The Visual Studio Image Library, which contains .zip files with VS images, has been updated with VS 2015 images.
After several days fixing bugs of my new MZ-Tools 8.0 version, today I have tried to run the build process that I have to generate the “Production” version and it has failed with this chain of errors:
Error 1 CreatePkgDef : error : ReflectionTypeLoadException: Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information. MZTools8VSPackage Error 2 at System.Reflection.RuntimeModule.GetTypes(RuntimeModule module) MZTools8VSPackage Error 3 at System.Reflection.RuntimeModule.GetTypes() MZTools8VSPackage Error 4 at System.Reflection.Assembly.GetTypes() MZTools8VSPackage Error 5 at Microsoft.VisualStudio.Tools.CreatePkgDef.ProcessAssembly(String fileName, Hive hive, PkgDefContext context, Boolean register, RegistrationMode mode) in f:\dd\VSSDK\VSIntegration\Tools\src\CreatePkgDef\CreatePkgDef.cs:line 260 MZTools8VSPackage Error 6 at Microsoft.VisualStudio.Tools.CreatePkgDef.DoCreatePkgDef(InputArguments inputArguments) in f:\dd\VSSDK\VSIntegration\Tools\src\CreatePkgDef\CreatePkgDef.cs:line 164 MZTools8VSPackage Error 7 at Microsoft.VisualStudio.Tools.CreatePkgDef.Main(String[] arguments) in f:\dd\VSSDK\VSIntegration\Tools\src\CreatePkgDef\CreatePkgDef.cs:line 85 MZTools8VSPackage Error 8 Could not load file or assembly 'MZTools8PlugIn, Version=8.0.0.0, Culture=neutral, PublicKeyToken=a756ad4bac8a0579' or one of its dependencies. Strong name validation failed. (Exception from HRESULT: 0x8013141A) MZTools8VSPackage
The first thing I noticed is that the errors show a location “f:\dd\VSSDK\VSIntegration\Tools\src” that is not on my hard disk. This is because the VS SDK tools (at C:\Program Files (x86)\Microsoft Visual Studio 12.0\VSSDK\VisualStudioIntegration\Tools\Bin) are shipped with the .pdb files for debugging.
The second thing that I noticed is that the CreatePkgDef.exe utility was failing because of a strong name validation that happened in the System.Reflection.RuntimeModule.GetTypes(RuntimeModule module) method of the .NET Framework. However, this had been working until a few days ago. My MZ-Tools package (MZTools8VSPackage.dll) uses .NET Framework 4.5 and it is not obfuscated, but it uses a core MZTools8PlugIn.dll that uses .NET Framework 2.0 and it is obfuscated. So, the things are arranged as follows:
So, in “Release” configuration, CreatePkgDef.exe is failing because the package assembly is loading a required assembly that doesn’t have a strong name yet (delay-sign). I was well aware that normally you need to instruct the .NET Framework to skip strong name validation using sn.exe -Vr (which for sn.exe 32-bit adds a special registry entry under HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\StrongName\Verification) but somehow the CreatePkgDef step of the package assembly compilation of my build process has been working for ages until a few days ago without that strong name validation skipping step.
What has changed in the last days? My only suspect was Visual Studio 2015 and .NET Framework 4.6, that I installed on my main dev machine once they got RTM status. Since .NET Framework 4.5, 4.5.1, 4.5.2 and 4.6 are “highly compatible” with .NET Framework 4.0, they are not installed “side by side” but “on top” of the previous version. But it could be that one version introduces a breaking change to existing apps. To verify this hypothesis, first on my main dev machine where the issue was happening I created a package with Visual Studio 2008 (which uses .NET Framework 3.5 and CLR 2.0) and it compiled even setting the following delay sign in the AssemblyInfo.cs file:
[assembly: AssemblyDelaySign(true)]
The same was not true if I used Visual Studio 2010 or higher (which use .NET Framework 4.0 / CLR 4.0 or higher), but it was true in the past. So the suspicion increases.
Then, I setup a new virtual machine with only Visual Studio 2013 (.NET Framework 4.5.2) and lo and behold, a package compiles even if you use delay sign:
As soon as I downloaded and installed only .NET Framework 4.6 (no need to install Visual Studio 2015), the same package compilation gets this error:
CreatePkgDef : error : FileLoadException: Could not load file or assembly 'VSPackage1, Version=1.0.0.0, Culture=neutral, PublicKeyToken=69b8a83eb37e3459' or one of its dependencies. Strong name validation failed. (Exception from HRESULT: 0x8013141A)
So, .NET Framework 4.6 introduces a breaking change that I have not seen documented.
Now, there is at least a couple of solutions:
sn.exe -Vr *,public_key_token
Finally Visual Studio 2015 RTM has been released today and I am installing now on my main dev machine, rather than on separate virtual machines as I have been doing until now. There is and there will be a lot of information about what’s new in this release, but as a developer of extensions for Visual Studio, this release introduces these changes that you must know:
I will elaborate on all these aspects in the next weeks (during my vacations, I’m afraid), and will provide new links on this site to VS 2015 specific stuff.
Did I mention that my extension MZ-Tools 8.0 is now a package for VS 2012, 2013 and 2015? It is also an add-in for VS 2005, 2008 and 2010, and they share 80% of code at binary level using the strategy of core plug-in + host adapters that I outlined here. I have even released in the last weeks a restricted Beta 2 of MZ-Tools 8.0 for the VBA editor of Office and even for VB6 / VB5 sharing the same 80% of binary .NET code. This is an example of a complex add-in migrated to a package with a new good underlying architecture to accommodate not only future changes in the extensibility model of Visual Studio, but also to support other Microsoft IDEs.
While a couple of days ago I was testing the last .vsix installer of my MZ-Tools extension, now converted to a package, with Visual Studio 2015 Release Candidate, I discovered that its large image was not shown in the Extension Manager. At first I thought that it was my fault, because the VS SDK doesn’t warn you that a resource included in the extension.vsixmanifest (such as the license agreement) isn’t actually included in the package project. After fixing another bugs that were my fault, today I investigated this one, and it happens with all installed extensions, not only with mine. So, while browsing the Visual Studio Gallery (“Online” node of the tree), the large image is shown as expected. Here you have the Developer Assistant, for example:
But once you install it (“Installed” node of the tree), its large image is not shown, the ugly default one is used:
I have opened a bug on Microsoft Connect:
Extension Manager doesn’t show large image for installed extensions
https://connect.microsoft.com/VisualStudio/feedback/details/1391193/extension-manager-doesnt-show-large-image-for-installed-extensions
Hopefully it will be fixed for VS 2015 RTM. You can vote for it to make it so.
I have been very stressed the last weeks in my spare time (nights and weekends) to ensure that the upcoming version 8.0 of my MZ-Tools extension works with Visual Studio 2015 CTPs and RC. This has been complicated because of these factors:
Today, VS 2015 RC has passed for the first time the 3,300+ automated tests of MZ-Tools. And they are integration tests (not unit tests), each one testing a whole user-simulated scenario: clicking the options window of MZ-Tools, setting some options, clicking the button of a feature, capturing the result (either contents of an output toolwindow or generated code) and comparing with the expected result. They are able to detect subtle changes in the behavior of VS 2015 such as different automatic formatting, automatic removal of line continuation character “_” in VB.NET, automatic addition of parenthesis “()” to parameter-less VB.NET methods if the test omitted them, namespaces omitted from types in the Error List after a build, etc. These are not really bugs but required to tweak the tests, in some cases maintaining backward compatibility with previous VS versions and in some cases detecting the VS version and using different code.
The tests also detected problems in the automation file code model (EnvDTE.ProjectItem.FileCodeModel), which I patiently isolated to root causes resulting in a total of 18 bugs that I have reported on GitHub, the last one, quite obscure, yesterday. At the time of this writing, at least 15 are fixed (or will be fixed for VS 2015 RTM) and the remaining three ones have workarounds that I have coded to pass the tests.
So, at this point, VS 2015 RC is good enough from my point of view.
In this post I blogged about nine bugs introduced in the FileCodeModel of Visual Studio 2015 by the new Roslyn-based implementation. Those bugs were “critical” (that is, no easy workaround) and were fixed in the next days.
Then I reported two additional bugs that were less critical for me since I could implement workarounds:
EnvDTE80.CodeProperty2.ReadWrite returns always read-write value for VB.NET body-less properties
Those were fixed too. And two days ago I reported a couple of new critical bugs (no workaround) that I discovered:
And those two have been already fixed on GitHub and will be in the some of the next Visual Studio 2015 CTPs.
It is also very incredible the level of transparency that Microsoft has now using open source for Roslyn on GitHub, where you can see the new code that fixes the bugs, the added unit tests, which MS developer is actually working on the fixes, who is reviewing them, etc.
So, thanks Microsoft for all!