Are there any limitations that I might face when using VS Setup Projects?
I plan to use them, but am not sure if this would be a good idea.
Well, in a more advanced setting: VS Setup Projects cannot be automated, e.g. you cannot put your project and the VS Setup Project on a build server and have them built automatically. This might not be an issue for a smaller shop or a single developer, but for a larger enterprise-level development environment, this alone can be quite a killer criteria.
In order to get around this, we use WiX for our setups - more work once up front, but works nicely with continuous integration.
Marc
They are OK, if your starting from scratch I would say look into WIX, or even pony up the cash for Install Shield or one of the other commercial ones, would save you time and money in the long run.
Builds can be very slow, especially if you have a lot of binary files. I have a project with a lot of product images that get packed into the install package, this takes a LONG time, even on a fast machine.
Visual Studio Setup projects lacks a number of key features that Windows Installer Provides. Most notable of these is the 'Feature' feature that allows you to setup several tools that the user can choose to install or exclude. As already recommended, use WiX or a 3rd party full-featured installer tool.
It depends on your project I suppose. It used to be a pain to use to set up web projects, but I think there is an addin now that makes creating a web app setup a lot easier.
More limitations...
There is no way in setup project to perform validation on data that has
been provided by the user on the UI dialogs (acquisition phase).
There is no way to designate a custom action to run with elevated
privileges(System account).
There is no way to make your custom action execute during UI sequence.
Related
I have a few (3) core projects I want to share across many solutions (12+).
So, say I have 12 websites and they use some shared back end core code (in this case I'm not talking about shared js, css or views - I'm talking about business objects, entity stuff, etc.).
I need to be able to identify which site has which version of the shared code in dev, test, prod, etc. so a developer can get the website code and get the right version of the shared code to develop or patch the website.
And then the MS build server needs to know which version of the shared code to get for the deployment.
To solve this, I'm seeing people branch that core code - which seems absurd to do 12+ times. (I do expect to branch the core code sometimes for things like hot fixes and long running projects.)
I'm also seeing people copy DLLs of the core code and check those in.
I would think I would list the dependencies for my solutions based on TFS label names somewhere so developers can easily get the apps running with the right code and given a tfs label the build server can get the code for the website and the proper version of the core code. I'm using TFS & VS 2013 at the moment too, so there's that.
So, is there a way to do this that's straightforward, supportable/scale-able and intuitive? Thanks - Peter
Labels in TFS is very limited. For example once the label created you couldn't change and update it. If one of your core projects updated, did you need to create a new label for it. If you did and use the new label for one of your solution. However you found there are some bugs in this update, you need a newer update of your core project to fix the bug. Then a newer label created, you need to manually maintain the dependencies which seems not to be an easy job.
Moreover how to list the dependencies for your solutions based on TFS label names? TFS don't have this built-in option, seems the only way is store it in a txt or someother files and check in the source control. Every time the developer open a website application need to check it first and get label from server to their workspace and work on it.
Usually the purpose of sharing code between projects is reducing maintenance. There’s two main code sharing paths: source and binary. The difference between them you could take a look at this blog: Code Sharing in Team Foundation Server
Sharing code between products is a primary cause of quality erosion and elevated bug counts. I would recommend you to build separately and sharing binary output through NuGet which use preferable.
Also take a look below similar questions:
Sharing code between solutions in TFS
TFS 2010 Branch Across Team Projects - Best Practices
Over the years our InstallShield code has grown un-manageable and messy. We're about to design an InstallShield 2015 installation from scratch for a new major release, and I was wondering if there's any way to automatically capture a set of system changes to use as a cleaner starting point for developing a new install package. Ideally, I would like to turn on some capturing software, install the oldest release from which we support an upgrade, install the latest service packs, and then apply the manual changes that will get the new release running on the system. Then I would turn off the capturing software, and it would provide an InstallShield project pre-loaded with all the files and registry entries (GAC changes, .NET assemblies, etc) that were created as part of that install. Then I could add steps to delete those that we no longer needed and do some other clean-up and refinements. Does such a thing exist?
Yes, this is called a repackager most often, in the enterprise world where sys admin and packagers prepare applications for deployment on the company machines.
Flexera has one that can create a project for InstallShield, but it is sold together with their AdminStudio solution, which is not cheap.
We (at Caphyon) have a repackager included in Advanced Installer (the architect edition) which also requires you purchase license. And of course the generated project will be compatible only with Advanced Installer, where you can configure your installers as you wish.
I think there is also a free repackager, AppDeploy from Dell, but I never used it, so I don't know how accurate it is and if you can use the results created into InstallShield or if it generates directly an MSI.
If you started looking more careful you will probably find other repackager tools, but you should know that building such a tool is not an easy task so choose carefully. Also probably only the one from AdminStudio will be able to generate a project that can be read by InstallShield.
If you already have the source projects from the older editions I would personally not try using a repackager. Instead I would go for cleaning up all the configurations which you do not understand and re-build them from scratch.
A repackager as good as it can be still has some problems. It can capture incomplete data, for example if you have a custom action that runs different code based on the OS where the installer is running the repackager will capture only its effects on the OS where you run it. On another one might run differently and have another output.
Also if your installer has prerequisites and you run the repackager on a machine where those prerequisites are installed then the repackager will not capture anything related to this, so by accident you can forget to include required prerequisites in the new package.
There is also the things like meta-information which few repackagers can detect. For example files associations which are actually a set of file and registry entries connected together or environment variables, scheduled tasks, etc...
Most repackagers capture all this data and simply show it to you as configuration files and registry entries, instead of creating the correct entities in your projects, i.e. files associations, environment variables or scheduled tasks in their correspondent views.
I just discovered (the hard way) that if you deploy your application to a device after doing a "Rebuild" or a "Clean -> Build" from Visual Studio your app is first uninstalled and then reinstalled resulting in the isolated storage files being wiped.
The Application Deployment Tool always seems to do uninstall - reinstall irrespective of whether it was an incremental build or not.
Has anybody found a workaround to this? Of course, the most obvious one is never to rebuild your application, but what if you accidentally do? Currently, I don't have all the generated files under source control, so if I were to try to build the app on another computer it would be a rebuild (maybe I will add all the generated junk into source control if no one has a workaround)
If I can suggest an alternative appraoch.. I think you will find it beneficial in other situations as well if you can introduce a little process to the generation of your test data so that it is easier to either a) restore or b) generate.
You could for example have a debug build only feature to upload/download the files on the device to a wcf service running locally on your PC (a simplified version of what Rongchaua did here).
Or, more work, if you are willing, but offering even more additional benefits would be to develop some automated testing capability into your app.. starting with generation of initial test data. Here's something you could look at to get started on that path.
Claus Konrad Blog: WP7: How to unit test a MVVM Light WP7-application
Granted these would take a bit of effort, but it's an approach that gives you some independence from manually generated test data, which in my experience invariably turns out to be a hassle at various times. And once solved, you find all sorts of reasons to thank yourself for doing it later.. whether it be saved time, or more robust testing because you can afford to be more aggresive with your test data/test execution and manage multiple test data configurations.
There is a a workaround:
open the solution configuration manager
next to build is a deploy column, uncheck your project
press F5
This will launch the app that is already on the device without overwriting it (and deleting its storage).
Are "Visual Studio Setup" projects suitable for complex setups in different versions?
The application is rather large (> 500,000 lines of code) and is under continuous development. Every 6 to 10 months a new version gets released. We have multiple configuration files (INI and XML), registry keys, database migration scripts, etc. The application is in the progress of being migrated from Visual Basic 6.0 to .NET. The old installer was build with Installshield. The feedback to Installshield is: Bad adaptability, bad reuse - that's why we are evaluating "Visual Studio Setup" as an alternative.
Other products we consider:
Free Solutions
WiX
NSIS
Commercial Solutions
Installshield (again...)
Wise
Advanced Installer
Is Something missing?
Solutions we don't like to consider:
Inno Setup (it just doesn't feel right)
No, no, no and no to Visual Studio Deployment projects. I've been there on "large" projects (15,000 files with thousands of merge modules and hundreds of InstallUtil custom actions because VDPROJ exposes almost nothing of the underlying MSI such as creating services). I could go on for hours about how horrible it truly is.
I have a team of four installation developers and we use a mix of WiX and InstallShield. Our typical install has nearly 100 features, 800 merge modules and 15,000 files. We deploy nearly every type of resource you can imagine including chaining third-party installs to create complete products or systems. We are able to do this for over a dozen products each building off of multiple integration, release and maintenance branches. The four of us support an organization of over 400 people with around 250 developers.
We are able to do this because InstallShield actually can give you a fair amount of reuse. You use product configurations and features / merge modules to create encapsulations of groups of files and business logic. Still, WiX does a better job (although much harder to learn and feature holes here and there that we still need InstallShield for), so we have been slowly transitioning our baseline over to WiX where possible.
Don't go there!! We thought it was feasible for a few simple installers but it has turned out to be a nightmare... At a first glance the VS setup projects look ok, but soon you'll realize the various deficiencies - meaning that you'll write a bunch of custom action code for accomplishing just the simplest tasks (e.g., service handling and installation into well-defined special directories that are just not accessible from the "nice" setup project GUI).
You can only use some very basic forms to get user input (password input is for instance not possible). There is no automatic incrementing of installer version numbers. The file handling is horrible - you manually have to pick each and every file. That is, you cannot just say "install all files in this directory into that directory" - fantastic task to sit and manually scan for new files in a directory with hundreds of files.
No, go for WiX, although the learning curve might seem slightly worse than for the VS installers - but I have regretted it many times that we didn't do that.
I need to create an install for my app that executes the following actions:
Copies files
Writes registry settings
Registers a windows service
Writes an XML app.config file (based on user supplied info during install--a connection string)
Executes SQL scripts against a remote database (connection info obtained in #4)
Installs and registers a COM dll
Adds entry to Control Panel>Add/Remove programs for uninstall
I don't need any fancy logic to allow the user to customize these steps--I can hard-code them with user-supplied info injected where appropriate.
I looked at Wix but found the documentation and examples don't line up well with recent releases.
I also looked at NSIS but found support for writing XML to be too limited (the plugin for this can only handle strings up to 64 bytes).
I initially brushed off the VS2005 built in Setup project as incapable of handling these tasks but I'm ready to reconsider after stumbling with what I thought were better options.
Any suggestions?
I would still recommend looking into WiX a bit more. We use it to do everything but #6 on that list and while there is a small learning curve. We've been using WiX v3 for almost 3 years, and I haven't found too many places where the docs/tutorial is that far out of place. And usually where it is its because they cleaned up the syntax and made it better.
Also, as of the next release of Visual Studio (2010/Rosario) WiX is being build directly into Visual Studio, I'm not sure if in parallel with the current Setup Projects or replacing them completely.
A Visual Studio Installer project can do whatever custom code you want; wouldn't see why any of your requirements would be a problem.
I have used Visual Studio (2005) and Wise and can recommend both. You didn't mention if the tool had to be free, and if so that rules out Wise. Nevertheless Wise has a dead easy learning curve and is very powerful and well documented. I have had a few weird things happen to me with Visual Studio. One time I had to delete my project and start over (possibly due to stupidity on my part - never figured it out), but overall I have been using it for a couple years at my current job and it works for me.
You can use just Visual Studio and Windows without commercial tools to achieve what you need.
First, check out the answer to create a single installer file.
Then, you can research how to create a Custom Action class that can perform registry, read/write files and register COM dll's separately.