How to deploy and register a VSPackage supporting multiple versions of Visual Studio (2005, 2008, 2010)? - visual-studio

I have an open source VSPackage that I would like to release with support for Visual Studio 2005, Visual Studio 2008, and Visual Studio 2010. I'm trying to figure out how to create the installer and how to perform the package registration with each edition of Visual Studio.
The deployment research I've done indicates my best bet for an installer is a VSIX inside an MSI.
The registration research I've done is a lot less clear. VSPackage registration seems to differ for every edition (VS2005 uses regpkg, VS2008 uses pkgdef, VS2010 uses VSIX).
Can anyone share their experiences and/or point me towards any information about the best approach for targeting multiple versions of Visual Studio? I'm looking for the easiest implementation and preferably keeping it in a single installer if reasonably feasible.
Any help would be greatly appreciated!

Short Answer: If you want a single installer that targets/registers with 2005, 2008, & 2010, the choice is quite simple actually. You should create a MSI-based installer and register to HKLM\Software\Microsoft\VisualStudio\(8.0|9.0|10.0).
Explanation: For the MSI/VSIX question...remember that VSIX is new for 2010. A machine with VS 2005/2008 won't know what to do with a VSIX file.
A side note on VSIX....you shouldn't ever put a VSIX file (i.e. the zip container) inside a MSI. If you want a MSI-based extension that also appears in the Extension Manager dialog, you should include a <InstalledByMSI> tag in your extension.vsixmanifest file, and lay down the files already expanded under <VisualStudio2010InstallDir>\Common7\IDE\Extensions\<YourExtensionDirectory>.
As far as registration goes...you have a few things incorrect in your question. For both 2005 and 2008, installers that register packages with Visual Studio should always register under HKEY_LOCAL_MACHINE. (PKgdef in 2008 was only for "Isolated Shell" based applications.) Laying down a pkgdef file is now a supported option in addition to the registry in Visual Studio 2010.
RegPkg is a utility included in the Visual Studio SDK for 2005/2008/2010 that reflects over your package assembly and outputs the appropriate registration information in several different formats. It's meant to be used at development/build time to generate your registration information and shouldn't be used as part of an installer.
CreatePkgDef.exe is a tool in 2010 that is essentially the same as RegPkg.exe, but it only outputs pkgdef files.

Related

Are we still stuck with installer projects .vdrpoj or WiX in Visual Studio 2013?

Is there no better Installer project in Visual Studio 2013 than the Setup projects or WiX?
I have a .vdproj and some WiX projects since Visual Studio 2008 which I now need to migrate to Visual Studio 2013. Do I still have to use the same two project types or is there a better solution?
Setup projects are still not supported with MSBuild and the WiX projects are still XML (although I see a visual designer is now available to purchase).
I am sick of both of them. I need something that is visual and that is supported by MSBuild. We have many custom actions too.
There is also Advanced Installer which have a Visual Studio Installer extension (with UI) which is available in their free edition (from what I know). Their Installer extension for VS is also MSBuild compatible.
WiX is the default way to go for free solutions that need to do advanced steps and must be able to integrate into Team Build and MSBuild.
Product Free/Paid VS designer MsBuild Support
InstallShield LE free yes yes
InstallShield Pro paid yes yes
InstallAware paid yes yes 3)
Advanced Installer free yes yes
NSIS free no no
MS VS Installer Projects free yes no
Wix Toolset free no 1) yes
InnoSetup free no no
PS App Deploy Toolkit free no 2) no
Remarks:
There is an extension that seems to support a user interface for WiX
Since it's PowerShell based you could use the Visual Studio PowerShell Tools.
Advanced Installer can generate an MSBuild compatible .*proj file on request.
Links to products:
InstallShield
Install Aware
Advanced Installer
Microsoft Visual Studio Installer Projects 2013
WiX Toolset
WiX Visual Studio extension
NSIS
InnoSetup
PS AppDeploy Toolkit
Remember that Team Build 2013 has a set of native extension points that allow you to execute PowerShell scripts after build which can trigger pretty much every type of installer project you need. Non-MSBuild-based systems like the PS AppDeploy Toolkit or NSIS can be triggered with relative ease this way.
XML and script-based UI's are generally easier to merge and branch and provide better maintainability over time as you're pretty much free to define the modules in separate files and provide comments on why certain files are deployed where or which commands are executed when.
I used the extension Visual Studio Installer Projects Extension: VSI_Bundle.
See the The Visual Studio Blog
It worked good for me.

Installer for Visual Studio 2010

I need to create a setup for installing my project. I meant to try both WIX both native visual studio installer, but i don't know how, when i go to new project there isn't such option. I figured out that WIX don't add templates on 2010, but why there isn't one for visual studio installer?
I would also like to know if there are any other simple installers worth trouble?
Visual Studio 2010 was the last version to support Visual Studio Installer (.vdproj) projects. Many teams use WiX Toolset instead. [UPDATE: There is now a VS extension that provides Visual Studio Installer support to later versions.]
WiX Toolset is a Visual Studio extension. Express versions don't allow extensions so that might be a reason you don't see templates. Another reason is that for the WiX installer to register templates, Visual Studio 2010 must be installed first. You can try repairing the WiX installation.
Another IDE for WiX is SharpDevelop. (It's free.)
Both Visual Studio Installer and WiX Toolset create Windows Installer packages. It's important to understand what Windows Installer does. If you are trying them to compare them, you might be interested in this related question.
NSIS is another technology entirely. It gives complete control over what's put the target system, including whether to have an uninstaller at all. Many projects use it as a bundler for Windows Installer packages. (But, note that WiX now has a bundler [called burn].)

How to Add Controls To The Visual Studio 2010 Express Toolbox (Code, System Files, etc)?

We need to enhance the installer for our WindowsForms.NET grid component: we should have the ability to add it to the Toolbox in a VS 2010/2012 Express edition (VB, C#, ...) while installing the product. We can do that for all non-Express editions using the well-known EnvDTE.DTE object, but this does not work for Express.
Is there an approach to achieve the goal? Say, change some system files (system for VS)? I.e., maybe, VS stores the toolbox item list somewhere in a file so we can access it and change accordingly? And maybe, this way can be used for all non-Express editions too?
Yes, there is a multitude of approaches:
manual installation
Toolbox Controls Installer (TCI)
Visual Studio Automation Object Model (DTE)
VSI, VSIX packages
VSPackage
I wrote a tutorial article discussing them in more detail:
Visual Studio Toolbox Control Integration
I think the TCI approach would work with the Express edition of Visual Studio. Also the VSI and VSIX packages are quite convenient way to make sure the components get installed.

Create MSI or setup project with Visual Studio 2012

I create a small application and I would like to create one MSI file.
In Visual Studio 2010 you have this project type under:
Other Project Types -> Setup and Deployment -> Visual studio Installer -> Setup Project
But the only thing you got in Visual Studio 2012 is "Enable InstallShield Limited Edition".
You can change the .NET Framework, but nothing changes.
Why is it not there any more? And how can I get it back? Is there a new way to do this?
Please see:
Visual Studio setup projects (vdproj) will not ship with future versions of VS
Windows Installer Deployment
It was announced 1 1/2 years ago that the project types were being killed. Alternatives are:
Use A VS2008/2010 Solution to build your installer
Switch to another tool such as InstallShield or Windows Installer XML
To create setup projects in Visual Studio 2012 with InstallShield Limited Edition, watch this video.
The InstallShield limited edition that cannot install services.
"ISLE is by far the worst installer option and the upgraded, read -
paid for, version is cumbersome to use at best and impossible in most
situations. InnoSetup, Nullsoft, Advanced, WiX, or just about any
other installer is better. If you did a survey you would see that
nobody is using ISLE. I don't know why you guys continue to associate
with InstallShield. It damages your credibility. Any developer worth
half his weight in salt knows ISLE is worthless and when you stand
behind it we have to question Microsoft's judgment."
By Edward Miller (comments in Visual Studio Installer Projects Extension).
The WiX Toolset, which, while powerful is exceeding user-unfriendly and has a steep learning curve. There is even a downloadable template for installing Windows services (ref. VS2012: Installer for Windows services?).
For Visual Studio 2013, see blog post Creating installers with Visual Studio.
Have you tried the "Publish" method? You just right click on the project file in the solution explorer and select "Publish" from the pop-up menu. This creates an installer in a few very simple steps.
You can do more configuration of the installer from the Publish tab in the project properties window.
NB: This method only works for WPF & Windows Forms apps.
Microsoft has listened to the cry for supporting installers (MSI) in Visual Studio and released the Visual Studio Installer Projects Extension. You can now create installers in Visual Studio 2013; download the extension here from the visualstudiogallery.
ISLE (InstallShield Limited Edition) is the "replacement" of the Visual Studio Setup and Deploy project, but many users think Microsoft took wrong step with removing .vdproj support from Visual Studio 2012 (and later ones) and supporting third-party company software.
Many people asked for returning it back (Bring back the basic setup and deployment project type Visual Studio Installer), but Microsoft is deaf to our voices... really sad.
As WiX is really complicated, I think it is worth to try some free installation systems - NSIS or Inno Setup. Both are scriptable and easy to learn - but powerful as original SADP.
I have created a really nice Visual Studio extension for NSIS and Inno Setup with many features (intellisense, syntax highlighting, navigation bars, compilation directly from Visual Studio, etc.). You can try it at www.visual-installer.com (sorry for self promo :)
Download Inno Setup (jrsoftware.org/isdl.php) or NSIS (nsis.sourceforge.net/Download) and install V&I (unsigned-softworks.sk/visual-installer/downloads.html).
All installers are simple Next/Next/Next...
In Visual Studio, select menu File -> New -> Project, choose NSISProject or Inno Setup, and a new project will be created (with full sources).
There is some progress for Visual studio 2013 developers :-D woot woot! See blog post Visual Studio Installer Projects Extension.
Link and information were retrieved from Brian Harry's blog post Creating installers with Visual Studio.
Have a look at the article Visual Studio Installer Deployment. It will surely help you.
You can choose the correct version of .NET framework on the page.
So for you, make it .NET 4.5. I guess that would be there for Visual Studio 2012.
I think that Deploying an Office Solution by Using ClickOnce (MSDN) can be useful.
After creating an Outlook plugin for Office 2010 the problem was to install it on the customer's computer, without using ISLE or other complex tools (or expensive).
The solution was to use the publish instrument of the Visual Studio project, as described in the link. Just two things to be done before the setup will work:
Install the PIA (Primary Interop Assembly) of Office 2010
Install the VSTO 2010 runtime

Why do Visual Studio solutions need to be upgraded with every release of Visual Studio?

This is easily one of the most annoying "features" of Visual Studio in its history and I don't understand why it exists -- ever.
Why would a CodePlex project need to care what version of Visual Studio I am using?
Off the top of my head, the only thing I can think of is that some versions of Visual Studio might introspect assemblies searching for attributes to determine what to display in "Visual Designers" and "Property Editors". But why would that cause Visual Studio to not be able to open the project and allow me to browse its contents and compile?
It seems to me like Open Source in .NET is somewhat limited by the stupid dependency management exhibited by Visual Studio. In other words, if I am using Visual Studio 2008 and you are using Visual Studio 2010, then we have different solution files.
http://blogs.msdn.com/b/visualstudio/archive/2010/03/15/why-does-visual-studio-2010-convert-my-projects.aspx
Here's an example from the site as to why Visual Studio converts your projects to 2010 format.
For instance, Visual Studio runs
custom tools such as single file
generators for designers in order to
output code representing the changes
made to the designer. Many of these
custom tools are upgraded or
completely replaced in the newer IDE.
During conversion, the IDE knows which
custom tools to replace or upgrade. In
order to make round-tripping work, VS
would need old and new custom tools to
understand each other so as to ensure
that old and new designers can work
side by side. Other than designers,
the following files would also be
affected: resource editors, wizards,
code snippets, item and project
templates, diagramming and modeling
tools, and many more.tools, and many more.
Since 2010 knows about what tools 2008 has, it can convert forward to be compatible with the custom tools 2010 uses. 2008 has no idea about what 2010 is using, how could it? Therefore, it is impossible to convert backwards since it doesn't know what it needs to convert, nor how to.
I believe the purpose of this touches on what you stated in your comments. If you are using 2008 and I 2010 and I compile it, how could you possibly run it again? 2010 is backwards compatible but 2008 has no way to make itself forward compatible.
Thus, by recompiling the project in 2010 I ensure that no 2008 user may mistakenly think they can compile it.

Resources