Visual Studio TFS with desktop applications deployment projects
Summary
With the rapid increase of changes and modifications required, being done in the software development industry, bottlenecks and issues regarding reviewing enhanced and modified code snippets in a consistent and speedy manner are raised. As a solution, usage of Team Foundation Server in Visual Studio was proposed. Adequate TFS features are not available in Visual Studio 2010, therefore using later versions of Visual Studio is required.
The upper solution itself has a limitation that affects a major area in desktop application development. That is, newer Visual Studio versions (2012 and greater) does not contain a complete deployment tool as there was in Visual Studio 2010.
Following is one of the common procedures on how such problems are being handled in starter level companies and some suggested solutions to overcome this problem.
Current common procedure for creating deployment projects within small scale companies for other desktop applications.
- Keeps a common source in Visual SourceSafe (VSS).
- Changes to the code are applied through different Visual Studio versions and changes are submitted to the common source in VSS.
- Does not manage a separate project for deployment setup.
- Once the changes are done, the built DLLs and other required files are extracted from assemblies in source in VSS to build the deployment project separately using Visual Studio 2010.
Currently, developers do not need to keep a deployment project added in their existing source in VSS as there is no requirement in editing/manipulating the deployment project for custom requirements such as adding custom tabs to the installation wizard and obtaining additional information from end-users.
Available solutions for deployment projects with team foundation server capability.
1. Visual Studio 2010
Visual Studio 2010 allows the user to create MSI executables via the “Visual Studio Installer” deployment project type (This is a current way we do it). VS 2010 supports the “Team Foundation Server” with some limitations.
Limitations and abilities in VS 2010
- Has the ability to generate an MSI setup with custom actions (current procedure)
- No capability to commit source code changes for review.
- Can commit changes without submitting for code review.
- Can identify edited, removed and inserted text in CS files as changed codes have changed colours.
- Can download source in server / get changes.
- Less user-friendly (compared with VS 2012 and 2013) and may occur incompatibility issues between TFS 2012, TFS 2013.
Solutions — Use third-party comparison tool, caters equivalent solution/ Settle for existing limited functionality.
i. Use third-party comparison tool
- Araxis Merge — A third-party comparison tool that can be used to compare the existing source and folders with existing data in the server. This indicates the changes between two sources in green, red colors. The tool itself seems has a limitation that is it cannot be used to commit changes directly to TFS within the comparison screen. (See last comment on the blog)
ii.Settle for existing limited functionality
- Microsoft claims they have a fix available for incompatibility issues and provided a downloadable fix.
- However Visual Studio 2010 service pack 1 has to be installed as a pre-requisite for this installation.
- The disability to submit codes for review will exist.
2. Microsoft Visual Studio 2012
This IDE includes user appealing richness, which might not be the best solution in all the cases.
Limitations and abilities in VS 2012
- Built-in support for sending code for review feature.
- User-friendliness in higher, compared with VS 2010.
- It does not contain a Setup project template provided by Microsoft.
- Third-party deployment project type as Install Shield Limited Edition is available.
- Could not build an *.MSI setup file, rather *.EXE setup files can be built in Install Shield (LE) deployment project (This will majorly affect products which were maintained in *.MSI extension in past.)
Solutions –Use other third party tool to build deployment project / Use Install Shield Limited Edition
- Use other third party tool to build deployment project
- Some recommended deployment tools by Microsoft and StackOverflow
- WIX , Advanced Installer, Windows Installer XML are some tools with a higher reputation.
- Use Install Shield Limited Edition
- Existing built deployment projects will be incompatible. Will require rebuilding the deployment projects for both 32-bit and 64-bit versions from the beginning. Some discussions are available in the point above.
3. Microsoft Visual Studio 2013
- Limitations and abilities are equivalent to visual studio 2012 regarding deployment project type as both versions of Visual Studio 2012 and 2013 use Install Shield Limited edition from Flexera. A considerable difference between VS 2012 and 2013 would be, VS 2013 needs a valid license key while VS 2012 does not require any. Team foundation server wise, features and functionality suits our current requirements just as Visual Studio 2012.
Solutions — Use third-party tool to build deployment project / Use Install Shield / Use Microsoft Visual Studio 2013 Installer Projects extension for VS 2013.
- Using a third party tool for creation of deployment project or using existing Install Shield Limited Edition from Flexera will provide as same experience as choosing these same options in visual studio 2012.
- Use Microsoft Visual Studio 2013 Installer Projects extension.
- Microsoft has released this extension for VS 2013 to bring back the same experience in creating deployment projects which existed in VS 2010. This enables the developer to get *.MSI installer setup files as the product. But the reliability of this extension is somewhat doubtful when referring to developer feedback on the visual studio gallery. Please refer to Visual Studio Gallery.
4. Microsoft Visual Studio 2012 + Microsoft Visual Studio 2010
Summary –Parallel use of VS 2010 and VS 2012 will be one solution in which the developers be able to overcome both deployment project and team foundation server issues. VS 2012 can be used to control a common source since TFS features and functionality in VS 2012 is adequate to the expecting level.
The build for the deployment is able to be done using the default Visual Studio Installer Deployment project, which gives an outcome for the current expected level and developer likings.
Limitations and abilities in VS 2012 + VS 2010
- Deployment project-related enhancements and modifications may still be needed to be done solely by using VS 2010.
- A source, once opened in Visual Studio 2012, cannot be opened directly in Visual Studio 2010 due to a compatibility issue (a minor modification in *.sln file is required).
- We will be able to submit code snippets for review via VS 2012.
- The identification of the modified code will be convenient.
- In a scenario where needs observing functionality in builds per- change, will not be as convenient as building releases solely using VS 2010.
- Free of cost and no additional third-party extensions required.
Conclusion
- Comparing with available options, the 3rd option (Using VS 2013 with Visual Studio 2013 Installer Projects extension ) will be able to be achieved easiest (assuming already built existing deployment projects will be compatible) without a hassle. The purchase of additional third-party tools will be completely eliminated.
But according to the developer reviews, there may be some limitations regarding customization in the UI. See user comments here.
- I propose 4th option secondly since usage of Microsoft products will be convenient even if 2 versions of Visual Studio had to be involved for development and for building deployment projects.
- Using third-party tools and extensions may have the risk of the active development and bug fixes of product being ceased eventually (Some of the tools once were reputed, are no longer being actively developed in present. : -WISE).
Choosing the best solution (Let’s take some risks! — personal opinion)
Let’s get rid of solution #1 as it is not rich in the TFS feature (This is exactly why we are doing this research!).
As pointed out, solution #4 is the easiest to implement, looking ahead it will not be feasible for you to continue using 2 different versions of Visual Studio for this.
You may not have that luxury to use option #3 initially, even though you have the same project extension in Microsoft gallery. But if you can, this is your solution. If not, we are left with solution #2.
Some available third-party tools exist and being compared against the current requirements. More information about deployment tools were fetched from this article as well. We are left with the following tools as mentioned.
Available Third-party tools and extensions
Install Shield Limited Edition — Install Shield is a powerful tool yet the limited edition snips off some vital features for projects require custom screens. User-friendly GUIs are available for composing the Deployment project, Adding dependencies can be done with ease. Custom banners, pre-requisites can be defined.
Custom actions and custom additional dialogs cannot be added to the deployment project within the limited edition, which makes ISLE useless for that required additional user inputs during installation.
Windows Installer XML (WIX) — A free tool, requires a considerable degree of knowledge to build the deployment project for user likings. However, allowing the user to install prerequisites before installation is not available.
Super Orca/ Orca — These tools are for editing a previously built *.MSI only. It allows users to view internal data of the *.MSI file in a tabled format. This tool does not serve our current requirements. Orca is a product of Microsoft and Super Orca is an application that gives the equivalent features as Orca but produced by another company. However, Microsoft no longer maintains Orca.
MakeMsi — Allows users to build *.MSI s using VB script. However, the changes done in script files are not validated, so the process of creating the MSI can fail due to wrong inputs. Therefore tasks related to this process have to carry out with 100% knowledge about it. Less user-friendly compared with ISLE and WIX.
A comparison
RequirementProductInstall Shield (LE)Windows Installer XMLSuper OrcaMakeMSICompatible with VS 2012YesYesWorks externallyWorks externallyCan create an *.MSIYesYesN/AYesCan create custom actions in installerNoYesN/AN/Adefine variables accepted by installerNoYesN/AN/AOpen sourceNoYesNoNoDocumentedYesYesYesYesComplexityLowHighMediumHighInstall pre-requisites (.Net frameworks)YesYesN/AN/AFree licenseLimitedYesYesYesAble to capture user inputsN/AYesN/AN/A
More findings!
- MakeMSI tool is an independently executable application with a higher complexity and less featured for the applications being built. A script file from Visual Basic has to be written in order to create an *.MSI installation file. Not the most suitable tool for application development since it may not be as reliable and efficient at usage.
- Super Orca only can be used to edit properties and internal data inside an *.MSI file. This tool cannot be used to create an *.MSI installation file from scratch.
- Windows Installer XML supports most of the development requirements for project development except for setting up pre-requisites before installation (absent .NET frameworks). Still, the creation of GUIs of the setup wizard is not automated, rather it has to code using XML and define the interfaces manually. This tool can be considered as the second-best option considering the drawbacks with pre-requisites, complexity, even it caters to most of the requirements.
- Install Shield is a decent tool that can be used along with Visual Studio 2012 for deployment project types. Equipped with a rich GUI and instructions to be taken in order to build the setup project with ease. The major drawback is that custom interfaces cannot be defined apart from the given set of interfaces (limitations in ISLE does not exist in premium and professional versions.). Plus custom actions cannot be defined in this limited edition.
Going for a premium or professional version of this tool may be the best option that can be taken to overcome application deployment project problems since Install Shield is actively being used in present and new releases of bug fixes are being released more often.
Final conclusion
The comparison chart says it all. Most of them pointed out compulsory features are available for no cost in WIX toolset. I suggest to use this tool if you can afford the time to learn it as this tool can be irritating if handled without knowing what you actually do. (I hope to upload you a re-usable solution in WIX)
Install shield hides the complexity, letting you to do what’s required using their rich IDE. This requires less time to get familiar with, comparing with WIX toolset.