I think I never reported this problem, neither on Microsoft Connect nor on this blog (it seems that I have been very busy last months…), but I have reproduced it on my two Windows 10 machines. When I try to install the VS 2013 SDK on Windows 10, I get the following error:
“Windows Program Compatibility mode is on. Turn it off and then try Setup again.”
And here it is the screenshot:
The Compatibility Mode is not activated:
When I activate it, running the vssdk2013_full.exe setup with the “Troubleshoot compatibility” context menu, the setup is run with Windows 8 compatibility but still I get the same error.
I don’t know if I am the only VSX developer in the world with this problem (I haven’t seen it reported) but anyway today I have opened a bug report on Microsoft Connect, which includes the screenshot and the log file. If this problem happens to you, now you know you are not alone. I don’t have a solution or workaround, though.
UPDATE (Jun 16): Thanks to Mister Magoo for pointing in the comments that the problem is that I renamed the setup file from vssdk_full.exe to vssdk2013_full.exe.
One of the things that I do from time to time is to take a question in the MSDN Visual Studio Integrate or StackOverflow forums about a subject of VSX that I am not very familiar with, and try to investigate and provide an answer. The other day I picked this one about extending the Solution Explorer filter with a custom filter, something that I didn’t know.
The question was that following the MSDN Walkthrough: Extending the Solution Explorer Filter the sample didn’t work for VS 2013 Update 4. I reproduced the issue and after some investigation I concluded that it was a bug in VS 2013, because the version of the Walkthrough for VS 2012 actually worked. I reported it to Microsoft Connect (the report seems to have been deleted now) and actually what was wrong was the MSDN sample, which should use the SVsServiceProvider parameter type (instead of IServiceProvider type) in this constructor:
public FileNameFilterProvider(SVsServiceProvider serviceProvider, ...)
There is now a MSDN feature suggestion to fix the code sample. But the sample has other two bugs:
- The Utilities.cs class is no longer required, you can use the provided HierarchyUtilities class.
- The command should not be bound with an event handler in the Initialize() method of the package. Its command guid/id are used as parameters in the SolutionTreeFilterProvider attribute to bind the command with the filter.
Unless you have been out of the (programming) world the last couple of days, you already now that Microsoft has made the biggest announcements in years regarding the .NET Framework and Visual Studio. Concerning developers of Visual Studio extensions, four of the announcements will have a big impact:
These changes respond to the strategy of Microsoft for the next years (mobile-first, cloud-first), which pivots around three pillars:
- Windows: on desktop (specially enterprise desktops, less likely to move to non-desktop or to non-Windows desktops such as Linux or Mac OS X), on tablets (Surface or otherwise) and on smartphones.
- Office 365: on every possible device, Windows-based or not (web-based, iOS, Android, Mac OS X, etc.).
- Windows Azure: cloud computing for client apps that run everywhere.
And for that strategy to succeed, Microsoft needs, you know, developers, developers, developers, like Windows on desktop many years ago.
So, let’s examine how each of the announcements above will impact you as a developer of Visual Studio extensions today and in the distant future:
- The new Visual Studio 2013 named “Community Edition” with full extensibility is already available. Microsoft could have waited until Visual Studio 2015 next year to provide it, but it has preferred to provide it now. The Community Edition is basically the Professional Edition and as such it supports any kind of extension: packages, MEF, templates, and still add-ins without any need to update extensions. It replaces the former Express editions, which lacked extensibility at least for non-Microsoft extensions, despite being very requested. This yields to a bit bizarre VS 2013 offering that previously included paid “Professional”, “Premium”, “Test Professional” and “Ultimate” editions, free “Express” editions for Web, Windows (Phone and Store apps) and Windows Desktop and now the “Community” edition. I guess this offering will be cleared with Visual Studio 2015, hopefully with just two editions “Community” and “Enterprise”, given that the new VS 2013 Community Edition is free for up to 5 users for commercial/non-commercial development but it is not valid for enterprise use. So, regarding this announcement, you just need to test that your extension works with the VS 2013 Community Edition (as expected).
- The new “Preview”, rather than “CTP” (Community Technology Preview”), of Visual Studio “14” has now the official and expected name “Visual Studio 2015” (likely you will need to refer to this name in your documentation, web site and maybe setup and even in the extension itself). If you are a developer of packages, templates or MEF extensions this new version will not have as much impact (except some details such as high-resolution icons) as if you are still a developer of add-ins, which in Visual Studio 2013 were deprecated but present, and in Visual Studio 2015 they are gone (no “Tools” > “Add-In Manager” menu). So, you have to migrate your add-in to a package, which can be quite a daunting task depending on the size and complexity of your add-in (only alleviated by the fact that you can still use the automation model (EnvDTE) from a package.
- The .NET Framework being now open source will benefit any .NET developer, not just developers of Visual Studio extensions. The most important thing here is the hope that some day Visual Studio may be open source too. To have access to the source code (and even with debugging) of the host where an extension is loaded is a huge time-saver when problems arise (and they do).
- The .NET Framework being now cross-platform could have a huge impact for Visual Studio in the future, because there will be an increasing demand for Visual Studio to be cross-platform too (Linux, Mac OS X). There is already an increasing demand for Visual Studio to be a portable app (runnable from a thumb-drive without installation). Both things are impossible in the current incarnation of Visual Studio, which is COM-based, requires admin rights to install (although not to run) and it’s basically a monster of technologies (COM/.Net, Windows Forms/WPF, etc.), and languages (C++, C#) with a mess of awful APIs for extensibility and so on. All this has an impact on performance, starting with the installation of the product (which currently takes longer than installing the Windows OS). My guess is that at some point Microsoft is going to need to start from scratch with a new IDE which is “performant”, modular, portable, cross-platform, designed to be beautifully extensible, etc. Such endeavor may take years, but that’s not a deterrent for Microsoft: creating the .NET platform took years, as well as creating the new .NET-based compilers for C# and VB.NET, and Office is today multi-platform (Windows, Mac OS X, iOS) although not with the same binaries. Of course, it won’t be backwards compatible and extensions will need to be rewritten, so maybe this new IDE will have a different name and could coexist with Visual Studio for some time. Here you have an strategy that you can start adopting to mitigate this scenario.
As I explained in the following article:
HOWTO: Testing add-ins in localized versions of Visual Studio
Visual Studio 2012 and higher allows to install additional languages (“Tools”, “Options” window, “Environment”, “International Settings” section) through language packs, rather than installing localized full versions of Visual Studio (as in previous versions):
Microsoft Visual Studio 2012 Language Pack
Microsoft Visual Studio 2013 Language Pack
When selecting a language other than English, you may find running the downloaded vs_langpack.exe setup the following error:
“The language pack is already installed. To install an additional language, please install the language pack for that language”
The problem is happening because you are actually installing the English language pack on an English Visual Studio (notice the title 2013 Language Pack – ENU). It happens that those download pages need some long seconds since you select a language in the dropdown list until the page is refreshed with the corresponding downloadable setup. If you click the “Download” button just after selecting a language in the dropdown list, you actually download the (original) English language pack. Once the page is refreshed, the whole page is localized (including the “Download” button) and then you can download the correct vs_langpack.exe setup.
Notice the amount of unfortunate events in this scenario that can confuse many people:
- The page needs many seconds to switch the language – a bad design -.
- No clear indication is provided to the user. The Download button is still visible and enabled.
- The downloaded setup has the same name “vs_langpack.exe” that doesn’t include the language.
- The setup error doesn’t say the language that you are trying to install (only the title states the “ENU” language).
Add-ins for Visual Studio have become so irrelevant for Microsoft that apparently they don’t even deserve a post in the Visual Studio blog to announce that they are officially deprecated in Visual Studio 2013. So I only became aware through this thread in the MSDN VSX forum that points to this MSDN documentation:
Automation and Extensibility for Visual Studio
“Visual Studio add-ins are deprecated in Visual Studio 2013. You should upgrade your add-ins to VSPackage extensions.”
That means that at some point the Add-In Manager will be removed from Visual Studio. This was expected as I posted here and I have already planned to move my MZ-Tools add-in to a package as I announced here, along with a new series of articles about creating packages (next year) once I learn the stuff more deeply.
I have updated the page Resources about Visual Studio .NET extensibility to include the download links to:
- Visual Studio 2013 SDK
- Visual Studio 2013 Isolated Shell
- Visual Studio 2013 Integrated Shell
and to include the link to the Visual Studio 2013 SDK MSDN documentation.
Remember that the VS 2013 SDK is now required to get the template for add-ins, as I explained here.
Finally (well, after 6 releases and 10+ years…) the Options window of Visual Studio 2013 will be resizable (at least in VS 2013 Preview it is), and of course it will remember the size between sessions. This opens an opportunity for better integration of “heavy” Visual Studio extensions (ie, with lots of options) that previously used its own Options window because they required more room or wanted to provide resizable listviews (like my MZ-Tools add-in).
The built-in VS options window has always provided a two-level navigation tree so, with the new resizing capability, it should meet the needs of most extensions, if not all. However:
– While many extensions need only “personal” settings, some extensions (like mine) provide also shared “team” settings, that are stored in a shared network folder and allow “read-only” access for team members that are not team leaders. This is because, as you know if you are a team leader, you may desire to enforce team settings, rather than just documenting and “telling” the team members the settings that they should use (ex: this company uses 3 spaces indentation, rather than the default 4). Visual Studio doesn’t provide this capability.
– If your extension targets several Visual Studio versions, you need to wait some years until VS 2013 is the lowest one that your extension supports.
The question that I raised one month ago about support for add-ins in Visual Studio 2013 already has an answer: they will be supported. If you install the Visual Studio 2013 Preview or set a virtual machine in Windows Azure with the Visual Studio 2013 Ultimate preview image (my approach), your will notice two things:
1) The Add-in Manager is still there.
2) In the New Project dialog, the “Other Project Types” “Extensibility” node doesn’t exist (nor the “Visual Studio Add-in” template).
About this second fact, I guess that now I can reveal this: Microsoft consulted me confidentially many months ago about moving the “Visual Studio Add-in” template to the Visual Studio SDK and I thought that it would be a good idea, a more natural place with other Visual Studio Extensibility (VSX) templates. And certainly, if you install the Visual Studio 2013 Preview SDK, the “Other Project Types” “Extensibility” node appears with the “Visual Studio Add-in” template and others for “Visual Studio Package” and “Visual Studio Shell Isolated”. BTW, I requested Microsoft support for add-ins in the Extension Manager (removing Add-in Manager), VSIX, etc. as other extensions (to gain parity) but it seems that to no avail. Add-ins will remain as second- class citizens in the VSX ecosystem.