Tuesday, May 28, 2013

VS.NET 2012 Missing Setup and Deployment Project Type

Well it is difficult to keep up with all of the news going on in and surrounding .NET, but I missed the news (from a couple of years ago) that new versions of VS.NET would no longer have the deployment/installer package as a project type. I was a bit shocked when I was looking for a setup project for my Windows Service and the old 'Setup' project type was no longer listed in VS.NET 2012.

A more official source of this information can be found on this MSDN blog post by Buck Hodges:
Visual Studio setup projects (vdproj) will not ship with future versions of VS

As for a quick install of a Windows Service for developement scenarios, just use the 'installutil.exe' installer tool (this tool is automatically installed with Visual Studio and with the Windows SDK) using the following command:

>installutill.exe C:\MyWindowsService.exe

Alternatives? WiX and NSIS are good alternatives. WiX allows creation of .msi packages for silent deployments (if required or desired) and NSIS creates a .exe and offers a straight forward to use scripting language to build deployment packages. Both have a ton of documentation and support. I have used NSIS only briefly, but it offers a low level richness that will suffice for any size deployment needed. Here are some links to each product:


A quick word if anyone is upset at Microsoft for this - don't be. We all have to yield to the massive open source communities with their maturing and robust products that just overall trump anything a little sector within the tools section of the VS.NET team can produce and support on an ongoing basis. It's better to become familiar with one of these well known and stable open source deployment products and begin using them anyway.


  1. Hey Allen,

    You know, we developers out there who are responsible for dozens of real world customer applications, notice such changes in VS 2012 immediately - as soon as we try to port those projects... And migrating all those existing projects generates costs without benefits for the customers.

    "It's better to become familiar with one of these well known and stable open source deployment products and begin using them anyway."

    For new projects, yes. I don't know if that's a generation thing, but currently Microsoft is about to completely loose its former strength, which is BACKWARDS COMPATIBILITY. They do it on Windows 8, VS, .NET (Silverlight). The good thing is: Microsoft will remark this in their sales numbers (the only language the top management understands), because business just stops moving forward to the new products. We had this with Vista, now with Windows 8, and VS 2012/AppStore. Will they learn? I don't know...

    Thanks for the NSIS-hint, will try that one.


  2. @Tom - Yes I agree my comments might have been a bit harsh about abandoning a project type or even a technology that one has been invested in for many years. From that angle I definitely get it and see your frustration. From what I see, Microsoft is trying not to invest in development components that co-exist in the open source community and dwarf their own functionality. I believe the installer situation was one of those cases.

    Your comments about Silverlight, Windows 7/8, etc. were spot on and see my other post entitled "Where are we Headed with .NET? It's Anyone's Guess". My recommendation is to tune into the Build conference this year to see how MSFT pulls the development community back together without alienating so many people because of its recent decisions.