We are very pleased and excited to announce the availability of the Project System Extensibility SDK. With it, you can define a new project type and begin writing extensions to customize the user experience or add features in just a few minutes while owning very little code. Gone are the days where you have to create or maintain an entire project system (usually a fork based on MPFproj) often containing well over 100K lines of code. Instead, you'll be building on the Common Project System (CPS) that ships with Visual Studio and is already used by C++, JavaScript, and ASP.NET 5. Here is a short video to help get you started.

 We built CPS to address the scalability, performance, responsiveness and rehost-ability aspects that modern customers demand while decreasing your time to market.

Differences between Project System Extensibility SDK and MPFproj

If you have ever written a project system for Visual Studio, you very likely are familiar with MPFproj and may have even used it as the basis for your project system. MPFproj follows a source code distribution model where you must fork the entire source tree, customize it, and build it into binaries that you ship.

The problem with this approach is that if the MPFproj base is updated to fix bugs or add features, you manually merge those changes into your code base and re-ship your project system. MPFproj itself is a huge codebase with more than its fair share of bugs and less features in common with C#/VB. Using MPFproj as the basis for your project system is a daunting task and can take many engineer-months to get to a shippable state.

In contrast, with the Visual Studio Project System Extensibility SDK, you write extensions for the project system that is built into Visual Studio. Specifically, you don’t develop an entire project system any more. Rather, you simply compile your project system extensions against our reference assemblies and then ship your extension.

When Visual Studio loads one of your projects it also loads all extensions that apply to that project so that whatever features you’ve added, or behavior you’ve tweaked, are seen by your customer. Later, when we fix bugs in the Visual Studio project system, those fixes will automatically apply to your project types as well simply because your customers took the VS Update or upgraded to a newer version of Visual Studio.

Another drawback with MPFproj and most other project systems is that the project system is a black box at runtime. Thus, anyone who wants to reuse and change it must resort to COM aggregation. This is where you pretend to be the project system entirely, yet you’ve only implemented a small part of it, and you must forward all other functionality requests to the “inner” project system. This approach is complex and easily leads to subtle bugs when the outer “flavor” changes behavior such that the inner project system’s internal state becomes corrupted.

With the Project System Extensibility SDK we no longer use (or support) COM aggregation to flavor an existing project type. Instead, you just write a MEF extension and tag it with an attribute that describes which projects it should apply to. Read more about this in our open source documentation.

That’s great, but I already have a project system. What do I get if I migrate?

The Visual Studio project system is designed from the ground up to be performant, scalable, and responsive – much more so than MPFproj. To close the gap between your project system and other project systems that Microsoft ships, it can be less costly to migrate first and then simply turn those features on, rather than re-implement and maintain those features in your own project system. As new features are added to the Visual Studio project system, you’ll be able to activate those features when necessary in your own project types.

On the “less is more” side, your code size after migration is expected to be much smaller than before migration. For example, the set of extensions for the Windows 8 JavaScript project type is about 15K lines of code, which is 62% less than MPFproj which starts at 40K. And certainly your project extensions can be much less than 15K if you’re not customizing as much.

If and when you migrate, you shouldn’t rush into converting your existing MPFproj code base to the project system extensibility SDK. Rather, start with a new project type or flavor using the SDK, then add extensions to reproduce the unique behaviors that your MPFproj-based project system used to provide, migrating just those portions of code over as necessary. You may find in some cases that behaviors cannot be brought directly over without a rewrite, which often leads to code that is much smaller and more maintainable than what you had before.

Is the Project System Extensibility SDK right for me? Why is it in Preview?

With all this simplification, you’d think that our answer would be “Yes!” (And for most devs we think that will be the answer.) However, it might not be the right choice for you! Perhaps you do not want to require Visual Studio 2012 or earlier. Or perhaps your project type requires customizing behaviors of the project system that are not yet exposed as extensibility points. Either way, we’d love to hear from you about your intentions and any blockers you might have.

Right now, in Visual Studio 2015, the Project System Extensibility SDK is in Preview. We will keep it stable going forward in VS 2015 itself (VS Updates won’t break you as a project system extension author), but in the next major release of Visual Studio after 2015, breaking changes will be made one final time. We are taking the VS 2015 release (starting with RC) as an opportunity to get feedback from the community which may include API changes, along with some changes we already have in mind, so that we can aim for the next version to be the last one with breaking changes.

While the new Visual Studio project system has been proven for Visual C++’s limited use (C++ still implements half of its own project system), and for JavaScript and ASP.NET vNext, it does not necessarily hold for all scenarios that we ship across other project systems. In fact, we know there are bugs in some of these other scenarios that we’re still working through. As you evaluate when to switch to the Project System Extensibility SDK, consider both the risk of hitting bugs and the opportunity you have to provide those bugs and other feedback to us early on so we can fix it either in a VS 2015 Update or the next major version. We hope many of you will decide to pilot a migration that will lead to feedback and possibly a success story from you.

For more guidance on determining whether now is the right time to migrate to the Project System Extensibility SDK, review our Introduction Docs.

Our roadmap for the project system

We anticipate most or all new project types that ship from Microsoft will be based on this SDK. We also look forward to migrating some of the existing project systems to this SDK in upcoming versions of Visual Studio.

With every feature we ship, we try to define the primary measure of success. For this new project system platform, success is when our customers forget what a project system is. It should feel like just another part of Visual Studio and extending or tweaking it should be as easy as extending the editor, the new C#/VB language service (Roslyn), or any other modern component of the IDE. To achieve this, we just defined new project types, or extensions to “flavor” existing ones, rather than creating whole new project systems. We want you to focus on what makes your project types or flavors unique and valuable to your customers rather than spending most of your time fixing bugs and re-implementing features that we added to C# or C++ in the latest version. Also, we want to make as many features as possible from our own project types available to you to use in yours. Try out the new Project System Extensibility SDK and share your feedback with us via the channels prescribed in our README or leave a comment below!

Thanks,

Andrew

Andrew Arnott, Principal Software Engineer, Visual Studio IDE @aarnott, MSDN Blog, Private Blog, StackExchange Andrew has been at Microsoft for 9 years and has contributed to the Visual Studio platform, project & build systems, and the .NET Compact Framework. He is also a father of 3 kids with one more on the way.