I have an application which consists of 2 web sites, 3 Windows services (2 of them hosts WCF services) and 3 SQL databases.
It's likely that all system will be installed on 1 or 2 servers, but also possible that some services will be installed on separate machines if performance will be seriously affected by them.
I need to create WIX installer for all this staff. The thing is I'm not sure if it would be better to create single complicated installer which will be able to install whatever component set (some services may be installe), or few separate installers.
Single-installer approach has important advantage if the whole product is installed on the same machine - we will need only few dialogs shown to user and we will be able to setup connection configurations between components automatically. But of course development of such installer is very complicated: installer wizard pages should be shown based on features, installing currently on machine. There will be multiple conditions and testing all them will be a hell.
Multiple-installer approach is easier to implement and test. But of course it will be harder for user to install the product - he needs to set same service installation URLs few times (once per installer) - to setup connection configurations to WCF services.
I searched for best-practices in this area but looks like there is not a lot of information. Can anybody suggest which way is more appropriate?
If you design it correctly you can switch back and forth between the two approaches. Personally I've used InstallShield which has a feature called RELEASE flags and Product Configurations. It's basically a way of defining multiple builds that pull in different features and apply different branding (ProductName, ProductVersion, ProductCode, UpgradeCode, INSTALLDIR and so on.) This is how you'd make say a multiple single product installations and then build it again as a product family suite. This pattern applies to SOA very much. The same thing could be done in WiX using preprocessor statements to control compilation.
I once worked for a company that made an SOA based server product. The system had 26 installers of 5 catagories ( Win Client, Mobile Client, Service Layer, Web UI layer and SSRS Reports) I did each as it's own installer and it really helped cut down on the complexity. Each service had it's own database which made writing the SQL scripts to create and update the DB a lot easier. It also cut down on the amount of configuration each installation had to do since it only had to know how to set itself up and the other piece it communicated with.
The bootstrapper to bring all these pieces together may or may not be needed. Part of the reason we choose SOA is to give us complete control on how to scale the system out. This type of flexibility (26 pieces on 1 server, 1 piece on 26 servers, 2 tiers, 3 tiers, n tiers ) makes it difficult to encapsulate through a simple wizard UI.
I would go with multiple installers, bundled into a big single installer, this allows you to easily separate and test them. The bundle installer has the purpose of capturing the data from the user a single time and pass it to all installers selected for installation.
You can do this using Burn support from Wix or other setup authoring tools (that provide you with a GUI, allowing you create the projects and dialogs much easily). Wix is a very good tool, but the time you need to create the projects is too much, compared with the costs of a license for a good setup authoring tool that provides and drag and drop IDE to design dialogs and chain the installation of the separate installers.
EDIT
To pass values from the bootstrapper to the background installers is very easy, you don't need to write any custom code. This is handled directly from the setup authoring tool. All you need to do is to make sure the tool is capable to create Windows Installer compliant packages. This way, you can pass the selections made from the user to the background installers as property values, in the command lines of the installers.
The bootstrapper installer should not register with Windows Installer, so it does not appear in Control Panel, as a separate applications, there you should see only the separate background installers.
I'm providing a second answer to give a different perspective from my first. Microsoft Team Foundation Server installation is 1 single installer for different roles. You can scale out the various layers of the system but the install is all the same: install it all.
What they have chosen instead is to invest in a role configuration wizard that gets executed post installation to activate a given installed feature and configure it's settings and that of the next layer it needs to communicate with.
This is a very good way to go also.
Related
Why is it a good idea to limit deployment of files to the user-profile or HKCU from my MSI or setup file?
Deployment is a crucial part of most development. Please give this content a chance. It is my firm belief that software quality can be dramatically improved by small changes in application design to make deployment more logical and more reliable - that is what this "answer" is all about - software development.
This is a Q/A-style question split from an answer that became too long: How do I avoid common design flaws in my WiX / MSI deployment solution?.
As stated above this section was split from an existing answer with broader scope: How do I avoid common design flaws in my WiX / MSI deployment solution? (an answer intended to help developers make better deployment decisions).
9. Overuse of per-user file and registry deployment.
Some applications won't run correctly for all users on a machine, because the user-specific data added during installation isn't correctly added to other user's profiles and registry. In other words the application just works for the user who installed the software. This is obviously a serious design error.
There are several ways to "fix" this, but the whole issue of deployment of per-user files and settings is somewhat messy for a few fundamental reasons:
How do you reference count components installed multiple times? (for each user on the machine)
What do you do with the installed data and settings on uninstall?
How do you deal with new files and settings to install that differ from the ones that are on disk and in the registry and have user-made changes? Surely you don't overwrite automatically?
There are no real clear cut answers, but there are several alternative ways to deal with the "problems". My preferred options are 2 & 3 since I don't think Windows installer should deploy, track or attempt to modify or worse yet, uninstall user data and settings at all - it is user data that shouldn't be meddled with:
9.1 Using Windows Installer Self-Repair or similar
The first option is to get settings and files and HKCU registry keys deployed properly via the setup itself or setup-like features. There are two major ways to do this: relying on Windows Installer "self-repair" generally triggered by an advertised shortcut, or using Microsoft Active Setup.
Self-repair is what happens when you launch a shortcut to start your application, and Windows Installer kicks in and you see a progress bar whilst "something" is being installed. What is typically added are HKCU registry entries and user-profile files.
There is also another alternative to achieve this, it is called Active Setup and is also a Microsoft feature. It essentially registers "something runnable" to run once per user on logon. This can be used to set up per-user data. Active Setup allows "anything runnable" to be executed - for example a copy of files to the user-profile. .
Both of these options mean that the user data and settings are copied in place once - and from then on they are not generally touched, but in the case of "self-repair" might get uninstalled for any user who actually runs the uninstall of the application (unless the setup is designed not to do so).
Although setting up user data with self-repair and Active Setup are "established" methods to get applications running properly, it seems wrong to track user data with Windows Installer components. Why? Because it is really user data that shouldn't be meddled with once initialized.
Accordingly my honest take on the whole issue is to try to avoid deploying user specific data or registry keys and values altogether, and this is what is described next as two other user-data deployment methods.
9.2 Application Initialization of User Data
The second alternative, and one that I find much cleaner, is to change your application executable to be able to initialize all per-user settings and files based on default setting and templates copied from a per-machine location or based on application internal defaults (from the source code) instead of writing them via your setup.
In this scenario Windows Installer will not track the files or settings that are copied to each user. It is treated as user data that should not be interfered with at all. This avoids all interference such as reset or overwritten user data during upgrades and self-repair (and manual uninstall and reinstall).
If there are cases where "fixes" must be made to application settings, this can be achieved by having the application executable update the settings for each users on launch, and then tag the registry that the update has been completed.
The overall "conclusion" is that your setup should prepare your application for first launch, it should not set up the user data and settings environment. All user-profile files and HKCU settings should be defaulted by the application in case they are missing on launch - this yields a much more robust application that is easier to test for QA personnel as well. This is particularly important for Terminal Servers where self-repair is not allowed to run at all. In such cases the application data will be missing if you rely on self-repair to put user data in place.
9.3 "Cloud" or Database Storage of User Settings
To take things a step further in today's "cloud environment" - and this is in my opinion the preferred option. Why should your application be restricted to files and registry keys and values? Why not store all user specific settings in the solution's database?
Full access, control and persistence for all settings without any deployment issues at all.
You do get new management issues though, and they must be shared between developers, system administrators and database administrators. But isn't the cloud pretty much the industry standard by now?
We have been struggling long enough with roaming profiles, corrupted user registry, mishandled user-profile data files, etc.... Developers, save yourself a lot of trouble, and create yourself some new database management issues instead of deployment issues - and start yelling at a whole new bunch of people! :-).
Settings in databases are:
Not suffering from "dual source problems". There is one instance, and it is updated in real time. Not like the synchronization problems seen with user-profile and "roaming".
Inspectable, manageable and patchable
Revisable (version control - can revert older settings)
You could even "tweak" all the user settings from your setup still by running database scripts as part of deployment, but if you are in a corporate environment - isn't the thought of just raising a ticket and then have your database administrator run the maintenance scripts with proper transaction support and rollback much more appealing?
Even if you are delivering a large, fat-client vendor application for general distribution and third party use (in other words not a tailored, corporate client/server solution where you are guaranteed to have a back end database), one should consider cloud storage of user settings by having users log on to a cloud using their email or similar and then synchronize settings in real time.
Such large applications generally always need to "cache" some settings files on the computer and in HKCU, but it seems more and more possible to save all settings in a single temporary file in the user profile area which is entirely "sacrificial" and even possible to delete if it is corrupted and then download the last saved settings.
Instead of hosting the cloud yourself, it is obviously possible to use company DBOs to configure their own company-wide cloud where they have full control of all settings, and can also enforce mandatory policies and restrictions for your software's operation. Not to mention the proper backup that is possible for all user settings.
We have developed a software in vb.net using Visual Studio 2013. Now we want to build a custom installer with following steps/features:
User Start to install our software.
At 'Enter Serial Key' option, user enters the 16 digit Serial which have we provided.
When clicking 'OK' button, our software connect to our IP and save the Serial Key with some other user's information to our database.
A confirmation Key is returned back to our software.
Software writes a file and save it to the system folder.
It is almost like Adobe or Corel registration process.
We are open to other techniques also which must secure that our software must install on a single machine only.
Please be noted that we are a group of novice programmers(not so advance level), so; if the process is elaborated, it will be very helpful to us.
One-Shot Setups: "A setup is run once, an application can be started again - in order to resolve and debug problems interactively - with meaningful error messages show to the user."
Hence: avoid license validation in the setup.
Short version on licensing.
License Key: Preferring to deal with license keys in your application seems logical for several reasons: the one-shot nature of setups
yields poor reliability (no interactive debugging - poor ability
to resolve problems). The end result is lots of support calls for something very trivial.
Further, the risk of piracy and hacking is a major concern when
exposing a license validation DLL in the setup. And finally
communication over the Internet is difficult with today's setups (proxies, firewalls, etc...) - which is a modern way to validate license
keys (in the future setups might have full Internet access, but be careful assuming too much since corporate users may have lots of restrictions and poor deployment could hurt sales and acceptance of the software for corporate use).
Finally your application must usually support a trial version,
and then you need a license dialog in your application anyway.
Why complicate your setup too?
CAs: Custom actions are complex and vulnerable to failure in general - due to complex sequencing-, conditioning- and
impersonation issues and overall poor debugability. More information:
Why is it a good idea to limit the use of custom actions in my WiX / MSI setups?
Overall Complexity of Deployment: A short, attempted summary of the overall complexity of deployment:
Windows Installer and the creation of WiX
(section "The Complexity of Deployment").
I would remove all licensing features from the setup and add them to the application. Your setup can still write a license to disk or to the registry by passing it to msiexec.exe as a public property -
UPPERCASE properties (or you can "hide" things a little more by using a transform to apply the serial property - it has exactly the same effect as setting the property on the command line). You can also set the LICENSE property from a dialog in the setup when it is run interactively, but my favorite approach is to allow adding the license key unvalidated to the registry in silent deployment mode, and to instead enter the license key directly in the application, and not the setup, for interactive deployments (the above description is for silent deployment):
msiexec.exe /I "C:\Install.msi" /QN /L*V "C:\msilog.log" LICENSE="123-456-789"
This will allow the license to be easily added to each machine in a corporate deployment scenario. The license value is simply written to disk or registry without validation. The application will verify it (more secure than a validation dll in the setup).
There is no need to mess with any complex setup dialogs, but you will need a license dialog in your application as explained below.
As a setup developer you should offer to help implement the feature in the application instead of the setup so it doesn't seem like a case of "passing the buck". This is all for overall software reliability and foolproofness - and several reasons are listed below.
Almost all large corporations deploy MSI files silently, so the setup GUI will be ignored most of the time anyway. You are then simply adding risk and wasting resources if you deal with licenses in the setup.
One drawback: An application run as a non-admin user after installation can not write to HKLM to share a serial between all users on the computer (a setup running with elevated rights can). It must either write to HKCU or the setup must have prepared write access to a specific HKLM location in the registry for the application to write to. I prefer writing to HKCU for each user since the license is then less available for copying by others, and it is kept as user specific data (allows roaming, though that is a hated feature by most IT professionals). However, a HKLM license key written by the application or the setup during installation (as explained above with a public property set) allows all users to share a license when launching the application.
There are several more concrete reasons to keep license handling and validation out of your setup:
A significant number of support requests always result from people who have problems registering their license keys in the setup. A setup is run once, an application can be started again if there are problems. This is more important than you might think for inexperienced users. You also have better features available to handle exceptions and error conditions and whatever unexpected problems may occur in the application.
Serial validation in the setup exposes a validation dll / method that is easily cracked by pirates. You won't prevent piracy by eliminating it from your setup, but at least you make it more difficult. It is more secure in the application if you cloak things a bit (static linking, encryption, obfuscation, putting the validation process online, and / or whatever is done by security professionals that I am unfamiliar with).
Allow application trial version: If the setup needs to support a trial version of the application, you should allow the user to enter a license key if they end up buying the product - preferably without having to re-run the setup or uninstall / reinstall just to add the license key. In other words you will likely need to deal with licensing in your application anyway, why complicate your setup too? More risk, more QA, more potential support requests and potential for multiple required fixes in both setup and application. High total cost?
If your application runs with different editions, what if the user buys an upgraded license? They should just be able to enter it into the license dialog and unlock features if possible and not uninstall and reinstall with all the clunk that involves. For some upgrades this is hard to achieve though, and you often end up with separate setups for different editions.
If the network is using a proxy server for Internet access, you will have problems registering the license over the Internet during the setup (often asked for by marketing). You have more features to check and deal with this in the application - it can try again and wait for access (generally you hook up to IE for automagic proxy configuration if possible). For corporate deployment you need a silent install option too which doesn't validate the key but just writes it to the registry. Trying to access the Internet from a silent install of an MSI is in my opinion a rather extreme deployment anti-pattern. I find it dubious in the setup GUI as well. Do the registration in the application - much less controversial, and you can set up firewall rules to allow it to access the Internet (msiexec.exe is likely blocked - and for good reason). There could also be hardware firewalls and / or security software to deal with that makes Internet access difficult or even impossible without some clunky admin server configuration. This could kill your software from consideration is my experience: "Just get this off our network and application estate - there must be better options - far too clunky and error prone".
UPDATE: As deployment technology matures and becomes more "Internet based" this "truth" may change, and we could end up doing everything "online" with deployment designed specifically to run via online "repositories" for example. We will have to wait and see. For now my opinion is that any setup Internet access requirements are erroneous and undesirable.
Setups that mess with licensing may sometimes cause license data to be deleted during upgrades, patching and migration scenarios due to bugs in the setup. This is a lot more serious at times than you would think - the package might hit thousands of workstations in large companies and be cumbersome to fix.
There is a rather bad "anti-pattern" in the MSI technology itself whereby self-repair or manually triggered repair will reset values in the registry that has been changed by the application. This can wipe out license keys. We see this all the time, and it is the technology's fault. It is just not logical in this area.
There are some fixes - or rather workarounds - for this (use a permanent component, write license from a custom action instead of from a component, etc...), but I find them quite clunky and you have to have a lot of experience to know all the pitfalls - and even experienced users mess this up.
Licensing is a huge corporate headache - often what is desired by a company or corporation is that licensing is centrally managed on a server, and not based on text serial numbers at all (for example concurrent or floating licenses acquired on application launch via the network). Just mentioning this though it is sort of out of scope for the question. In these cases what you specify during installation is generally an IP address pointing to the license server, or just a regular host name to be resolved by WINS or DNS.
As you might have already guessed Windows Installer doesn't provide any out the box feature to handle licencing. But there are commercial licencing solutions which you can go for if affordable.
LogicNP
DESAWARE
Since this is very broad question difficult to explain low level implementation details. I can give you a direction.
First of all you will need a custom UI where user can type in the License/Activation key. There are ways to incorporate a custom UI into windows installer, I have already explained few approaches in SO, refer to the following threads.
Show custom Form during installation
How to add additional custom window to VS setup projects UI flow
By following above approaches you should be able to add a UI where user will type in a key. Once user added the key, he will press Activate button on the custom UI, Button click event handler will invoke the necessary logic to Insert/Validate the activation key entered by the user.
Maybe you could try Inno Setup which is free (even open source) installation system.
It is script based which allows you to tune your installer and perform in it everything!
Creating custom page with entering serial number is really easy, see this example: CustomPage for Serial Number in Inno Setup
and there is also integration for Visual Studio.
I want to know if I can distribute a copy of a Windows 8 App using some form of package file, avoiding the need to get it from the Store. I want to target average users, not developers.
If you're targeting end users, i.e. consumers, then the answer would be no. I don't even see the advantage of bypassing the store in this case, since it only brings you a larger potential market for your application.
Sideloading of applications (the name used for installing them without publishing to the store) is supported only for the enterprise scenario to allow companies to install their own line of business applications which they don't want to publish in the store. There are multiple requirements for this to work which are not feasible for individual end users.
That being said, nothing prevents you from creating the appx package (Project > Store > Create App Packages... menu in Visual Studio) and distribute it to your users. Along wih the package a PowerShell script is generated (Add-AppDevPackage.ps1) which takes care of installing the application on another machine, including installing the certificate and obtaining the deceloper license (for which he will need a Live account). The user will require administrative privileges to run the script. And he will have to renew the developer licence every 30 day for the app to continue working. Because of all that this process is really only suitable for a small number of users who can test your app before you submit it to the store.
I found the link below as an answer to a previous question. It seems that you could easily install it using the temp folder and NSIS.
How to install a Windows 8 App Without Submitting to Store
The Windows Store is exactly the mechanism you'd want to use to target average users; it's the place they will go to discover and install new applications.
Technically, you can sideload applications; however, that mechanism is for distributing line-of-business applications within an enterprise. You can also install an application package directly on an end-user machine, but that will require a developer license on that machine, and that's explicitly contrary to your goals.
The problem is that recently on my company we need to make an installer, since anyone haven't worked with InstallShield Before we have a lot of questions about it.
So here are the questions:
Am I able to restore a database using InstallShield? I mean, giving to it the path of the .bak file and then run a script and recover the database on mssql?
Does Install Shield have configuration files, so I'm able to change the files that are going to be used, depending on the client and the software version we are installing? Nowadays we use our own setup, but we have to select the files manually, so when a client whants to install a software we have to go with them and do it, because is really complex. Now we need to change that by making an installer that can be configured here in our company by and IT member, then send the files and the installer to the client and he only press "Next, Next..."
Sorry for my bad english
You might find that treating the front-end software and database as two separate items is easier for you and your clients. While many vendors offer the ability to run scripts against SQL Server (and other databases) during the course of the installation, you'll find that there are all kinds of issues you need to contend with (do you need to first install SQL Server, does the user have permission to access the SQL Server, what if they are installing the software on a new pc but don't need the database created again, etc). None of these are showstoppers, but they do create headaches that you need to deal with.
By treating the database and front-end separately, you can build an installation package that installs your front-end software and related components on the target machine. This in and of itself can be tricky to deal with depending upon how complex your software is and the amount of references and prerequisites you need to manage.
When it comes time to manage the database aspect of the program, you may find that the majority of your clients are capable of restoring a .bak file to their SQL Server, and the ones that aren't can always be assisted (probably remotely) by your staff.
If you discover that this isn't the case, you can always create a separate "Server" installation package that manages the database aspect of the installation.
With regards to your question about InstallShield, you'll probably find better information from their website and \ or sales staff, but here's a list of their current features.
There are other vendors in the space as well, so look at all of them including InstallAware and my personal favorite Advanced Installer. Pick the one in your budget that offers the features you need. They all should offer trials as well. Download and use them before you buy to find one that works best for you.
Yes installshield can call a script that will restore a db, you just need
to do so in silent mode. and yes there is a cfg file for install shield.
the documentation will show this in detail
here is some documentation for version 12
http://kb.flexerasoftware.com/doc/Helpnet/installs hield12helplib/IHelpContents.htm
they are currently on version 2012, however if you are doing this
crossplatform, don't use installshield, but use installanywhere. it is cross
platform.
There was a challenging situation happened when i was working with install to provide product key validation. I had to use C++ unmanaged code to validate the key. Actually we had the main validation logic written in C# and I had to create a mixed project. Problem was not stopped only with these, it continued. Since I used VC++ code, it expected atleast the VC++ runtime redistributable to be installed in the client machine. I thought of dropping the plan to migrate our install to Wix because of these kind of problems.
But I came to know that there is a nice and very cool feature that DTF is available in Wix to integrate any kind of actions in C#. I used it and could integrate the key validation in couple of hours and till now it is working fine in all client machine I implemented before 6 month.
Do you have any interesting moment or nice experience with DTF?
Search my blog at http://blog.deploymentengineering.com for DTF and you'll find a lot of useful content. I love DTF but I still believe that the best solution is to avoid a CA whenever possible in the first place. C#, like VBScript before it, is so luring that it tends to suck imperative thinking developers into writing CAs when not needed. I believe this is the reason DTF wasn't released for so long.
At my day job my approval is required for anyone who believes they need a CA. I instruct the developers on basic MSI philosphy, how to use DTF, how to attach a debugger and I make it clear that they are on the hook if it ever has any issues. The result is very few but well written CAs in our product line.
I have written several .NET CAs to support our WiX based installs:
Managed Wrapper around HTTPAPI.DLL - supports creating IP/Port SSL bindings and HTTP Url ACLs for use in deploying WCF services. I plan to turn this one into a Wix Extension. It was very interesting learning how to properly handle rollbacks, etc.
SSL Picker dialog that displays all the SSL certificates on the system and allows you to pick one.
SQL Server browser dialog - lets you browse your network for SQL Servers and then browse SQL Servers for Databases. Optionally uses impersonation. This is for crafting a connection string.
I am in the process of writing a set of CAs that will use the Microsoft.Web.Administration assembly to do native installs of web applications on IIS 7 (without requiring the IIS 6 Metabase Compatibilty feature be installed).
First off, the C#/DTF custom actions are still custom actions (no magic here :-)), so you should follow all the various CA guidelines working with this kind as well. It simplifies most of MSI tasks by abstracting low-level API behind the high level well-designed classes. Also, keep in mind that you can use managed code CA only in case the target machine has .NET installed (or install it as a prerequisite). Finally, the dtf.chm documentation which is distributed along with WiX toolset has some simple, but self-explanatory examples.
Hope this helps.