Long story short, one of my my employer's clients has an aaS platform that relies on a piece of software that's a ClickOnce app. This particular app is developed by a 3rd party software developer, and licensed to my employer's client company. It also happens to have a large number of prerequisite/dependency applications that need to be installed in order for it to function, but are not deployed as part of the ClickOnce installation. Importantly, because it's developed by a 3rd party and licensed, it's not possible to make any changes to the application itself.
Thus far, actually installing the application on endpoints has been handled by the client company by providing a pre-imaged computer, or when their client wishes to use their own hardware, giving their customer service reps a large zip file containing a bunch of .bat scripts they have to run manually on any computer that's to be used as an endpoint for their service. The batch scripts basically do the job of a bootstrapper and install the prereqs, make necessary system configuration changes and checks, and then call the ClickOnce application installer.
As expected, they don't like this solution, and would like an actual installer, so I've set about creating a bootstrapper with WiX/Burn, but I'm now stuck on how to include the ClickOnce application in my bootstrapper project. I can't seem to find documentation on this online, prompting the question:
Can I bundle a ClickOnce application into a WiX bootstrapper? How?
If it makes a difference, the ClickOnce application is published from one of the client company's servers, so I have full access to both the ClickOnce manifest and all the .deploy files.
You can't make a silk purse of a sow's ear. I think the best you can do is make a dependency installer for a certain version of the ClickOnce installer. No one should expect that a future version of the application would have the same dependencies.
(By that time, though, maybe they'll fix their ClickOnce installer by including dependencies. Or, abandon dependencies that they are having trouble putting into ClickOnce, say those needed for obsolete versions of Windows.)
Once dependencies are installed, you can have the bootstrapper launch the application, which would install or update it. (Logically, this follows the Chain.)
<Variable Name="LaunchTarget" Value="http://example.com/path/product.application"/>
Backing up a bit, you could create an MsiPackage with all of the ClickOnce files, and use a "file://" URI for the LaunchTarget. This would require you to rebuild and redeploy each new version (defeating the nature of ClickOnce), but would isolate you from untested application updates.
Related
Our application is currently published via ClickOnce. Till now. Some of our clients requested a MSI package.
Is it possible to support both deployment strategies using the same code and same Visual Studio solution? How would you setup your projects within the solution in order to create clean ClickOnce and MSI packages?
Regards
Paul
It's one or the other, so you'd need to create an installer setup project (and you may need to download and install the installer project add in) and add it to your solution. Your app seems relatively straightforward if it can be deployed with ClickOnce, so you could start here for setup projects, old but still relevant:
https://www.simple-talk.com/dotnet/visual-studio/getting-started-with-setup-projects/
You could use WiX of course, but it's a steeper learning curve, and you'd need to look at upgrade strategies such as major upgrades.
ClickOnce deployments are per user, MSI can be per system or per user, so that may be a consideration. It may be part of the reason clients are asking for MSI files, or it may be that they are deploying with group policy. If it's group policy the general requirement is the MSI can be installed silently without user input.
Background
I'm currently triaging migrating an existing non-MSI setup to a Windows Installer based solution. The current solution is written in InnoSetup and I very much like it, however, customer IT departments start to require MSI, and where they do so, it is often the case, that many/some of the prerequisites and scripts we include in our setup.exe are not needed for their automated tasks (but, then, some are).
Therefore it seems a pure MSI wrapper doesn't make too much sense here, so I'm looking at (multiple?) MSI files plus a boostrapper.
Prior knowledge
I'm good an InnoSetup, but I'm just starting to read into the Windows Installer technology.
Question
As far as I can tell, for any multistep / "complicated" setup requirements including prerequisites and stuff, using just a bare MSI file is a no-go. (As evidenced by the existence of all the different boostrappers, including the one bundled with WiX, Burn)
Therefore, I would need to split our existing monolithic setup into several steps, some of which (mostly those that install our files) bundled into MSI databases and some of the steps just "scripted" in the bootstrapper.
And here is where I really could use some prior experience regarding setup packages: What parts of a (chained) setup go into the MSI package(s) and what part goes into the bootstrapper?
Should all the (normally visible) UI reside in the bootstrapper or do you put some of it into the MSI files?
How "dumb" should each MSI file ultimately be? That is, if using a bootstrapper and multiple MSI files anyway, should any individual MSI file contain any optional parts, or should all the options be factored out into separate MSI files (that just check for the existence of their respective prerequisites, but contain no logic to install them)?
Basically, the application (suite) needs to support a click-through average user scenario where the setup handles everything and for corporate clients needs to be able to be split up into MSI files that only contain our stuff minus dependencies like the .NET runtime, SQL Server, ... that'll be handled by the client's corporate IT and our software MSIs will be deployed by the client IT automagically.
So, should all the glue and dependency scripting go into the bootstrapper and only use very simple MSI files? Or should some "logic" go into (some) MSI files?
Short-ish answer:
When there are multiple MSI files it is normal for the UI to be handled by the Burn bootstrapper because you do want to see combined progress, not all the separate MSI UIs. You also should set up appropriate rollbacks of more than one MSI in the event of a failure of one if you are really packaging several MSIs as a product, so if one fails they all need backing out.
The bootstrapper contains detection logic that determines what needs installing, and can install prerequisites like SQL, NET etc, but must not otherwise change the system.
The MSI files contain all the files, service installation, COM registration and so on that is appropriate for the files being installed. Any custom action code you use that alters the system must be in the execute sequence, deferred, and have a corresponding rollback CA to undo whatever it does. The MSI should be capable of being run independently to install its content - I've found that to be a useful guideline. The MSI files will be installed without their UI, so ensure that they can be installed silently with parameters passed as property values on the command line, including install location.
Hard to answer this in brief. Do use Burn or a similar bootstrapper, and leave runtimes with their own deployment solution as a separate file to run - and run in silent mode by default.
For home users you should install everything without too many questions to avoid confusion.
For corporate deployment you should deploy only what is needed and make it clear what each included deployment file is for:
Write a one page PDF with deployment instructions describing what every file does and what runtime it relates to. Call it "DEPLOYMENT README.TXT" or similar. This is the best way to get your application approved for corporate deployment. It can be tiresome to analyze this.
Application packagers in the corporate environment will analyze the prerequisites and determine if your application will work well with their standard framework packages. These standard packages will be set as a prerequisite in the distribution system.
Document in particular what .NET framework version is needed and other runtime requirements in detail.
Don't install windows hotfixes, msiexec engine updates or .NET framework runtimes automatically. Document them as prerequisites in your text file. These runtimes are tightly controlled in corporate settings and they are deployed by customized corporate packages.
You can include merge modules of simple runtimes in your MSI, they can be easily removed by the application packaging team in the corporate setting.
This answer didn't get terribly good, but I am out of time. Perhaps check this answer as well:
MSI Reference Counting: Two products install the same MSIs
I have a small application that is designed to run under currently logged on, non-administrative workstation user. Application can be installed manually but I also made sure that it is compatible with Group Policy Objects (GPO) software distribution method - I have .msi files for old systems (XP/Vista): separate files for per machine and per user installations as well as .msi file that takes advantage of Windows 7 (and newer) compatibility with WIX Allusers=2 option to allow automatic registry and folder path redirection depending on the installation context.
All is good there, but I am just wondering, is there anything special I need to do to make my installer suitable for installation using Microsoft System Center Configuration Manager? I do not really have resources to just test such a scenario myself and would like to find out about theoretical requirements for installer files for SCCM.
At my day job I'm the Deployment Architect for a Fortune 50 company with an SCCM 2007 environment ( currently migrating to SCCM 2012 ) that has over 300,000 clients. Here's a few tips.
1) We don't do Per-User installs. They are impossible to manage and report on. If an installer must have Per-User resources and we can't get the application (typically vendor provided) we do this using an Active Setup technique where the first time each user logs on the MSI does a repair and populates the Per-User resources. Just realize you'll never get it off... it's essentially forever.
2) SCCM can handle non MSI deployment types but well written MSI's work the best.
3) Use snapshotted VM's to test your install in the SYSTEM context. (PSExec is your friend)
4) Test your install, uninstall, reinstall, upgrade, repair, change. Make sure everything is bulletproof.
5) Don't wrap up prereqs into a setup.exe bootstrapper. Decompose it and allow SCCM to package each of these items. You can then use package chains, task sequences or application model to allow SCCM to manage the chaining. You get better status, reporting and efficient use of the system.
Just a couple of thoughts if I remember these things correctly - the MSI should be capable of silent install, and among other things that means no custom actions exclusively in the UI sequence, because they will not be run at deployment time because you will probably suppress the UI. The execute sequence shouldn't have custom actions that might explicitly display messageboxes requiring acknowledgement unless they are based on calls to the Win32 MsiProcessMessage() API or equivalent.
I have the requirement as follows to create an installer for a Silverlight application that consumes WCF service and SQL Server as a database.
The goal is to create an all-in-one package that installs the application, the service and the SQL Server database on the server. Although the package should include all three the user should be able to install them separately as well. For ex. Silverlight application need not be installed on the server, and the WCF service not on the client and so on.
I'm right now trying with Wix installer, this is my first time using wix. It looks good so far, but I'm not sure if it complies with all the following requirements.
Requirement:
Customers should be confident that applications will install on Windows Server 2008 R2 without degrading the operating system or other applications.
Installer related requirements
Do not require server to restart during and after Install / uninstall
Uninstall cleanly
Comply with Windows Resource Protection (WRP)
Allow user control of installation location
Comply with Kernel mode component requirements
Install shared components to correct location
Do not overwrite non proprietary files with older Versions
Support User Account Control for installation
Correctly conñgure package identity
Follow Best Practices for creating custom actions
Follow component rules
Install / uninstall
Support command iine installation
Applications using Windows Installer must successfully install in quiet mode via a command line with /qn switch.
I would like to know if Wix is the right tool or is there any other better free tools. Visual Studio setup project doesn't seem to be flexible or may be I'm wrong.
If you want a free tool Wix should be your choice. Its no so easy to use it in the beginning, but it gets the job done. VS setup project is designed for small simple setup packages, you cannot consider it as an option based on the requirements you have.
Advanced Installer recently added dedicated support for Silverlight applications. It also covers your other requirements, including SQL Server databases. The only downside is that it's a commercial tool, so you need to get a license.
But if you want a free tool, WiX allows you to hack pretty much anything into your installer. So if you like it, you should stick with it and start implementing custom actions which cover the requirements which are not supported by Windows Installer.
Generally when I use ClickOnce when I build a VB.NET program but it has a few downsides. I've never really used anything else, so I'm not sure
what my options are.
Downsides to ClickOnce:
Consists of multiple files - Seems easier to distribute one file than manageing a bunch of file and the downloader to download those files.
You have to build it again for CD installations (for when the end user dosn't have internet)
Program does not end up in Program Files - It ends up hidden away in some application catch folder, making it much harder to shortcut to.
Pros to ClickOnce:
It works. Magically. And it's built
into VisualStudio 2008 express.
Makes it easy to upgrade the
application.
Does Windows Installer do these things as well? I know it dosen't have any of the ClickOnce cons, but It would be nice to know if it also has the ClickOnce pros.
Update:
I ended up using Wix 2 (Wix 3 was available but at the time I did the project, no one had a competent tutorial). It was nice because it supported the three things I (eventually) needed. An optional start-up-with-windows shortcut, a start-up-when-the-installer-is-done option, and three paragraphs of text that my boss thinks will keep uses from clicking the wrong option.
Have you seen WiX yet?
http://wix.sourceforge.net/
It builds windows installers using an XML file and has additional libraries to use if you want to fancify your installers and the like. I'll admit the learning curve for me was medium-high in getting things started, but afterwards I was able to build a second installer without any hassles.
It will handle updates and other items if you so desire, and you can apply folder permissions and the like to the installers. It also gives you greater control on where exactly you want to install files and is compatible with all the standardized Windows folder conventions, so you can specify "PROGRAM_DATA" or something to that effect and the installer knows to put it in C:\Documents and Settings\All Users\Application Data or C:\ProgramData depending on if you're running XP or Vista.
The rumor is that Office 2007 and Visual Studio 2008 used WiX to create their installer, but I haven't been able to verify that anywhere. I do believe is is developed by some Microsoft folks on the inside.
I agree with Joseph, my experience with ClickOnce is its great for the vast majority of projects especially in a corporate environment where it makes build, publish and deployment easy. Implementing the "forced upgrade" to ensure users have the latest version when running is so much easier in ClickOnce, and a main reason for my usage of it.
Issues with ClickOnce: In a corporate environment it has issues with proxy servers and the workarounds are less than ideal. I've had to deploy a few apps in those cases from UNC paths...but you can't do that all the time. Its "sandbox" is great, until you want to find the executable or create a desktop shortcut.
Have not deployed out of 2008 yet so not sure if those issues still exist.
Creating an installer project, with a dependency on your EXE (which in turn depends on whatever it needs) is a fairly straightforward process - but you'll need at least VS Standard Edition for that.
Inside the installer project, you can create custom tasks and dialog steps that allow you to do anything you code up.
What's missing is the auto-upgrade and version-checking magic you get with ClickOnce. You can still build it in, it's just not automatic.
I don't believe there is any easy way to make a Windows Installer project have the ease or upgradability of ClickOnce. I use ClickOnce for all the internal .NET apps I develop (with the exception of Console Apps). I find that in an enterprise environment, the ease of deployment outweighs the lack of flexibility.
ClickOnce can be problematic if you have 3rd party components that need to be installed along with your product. You can skirt this to some extent by creating installers for the components however with ClickOnce deployment you have to create the logic to update said component installers.
I've in a previous life used Wise For Windows Installer to create installation packages. While creating upgrades with it were not automatic like ClickOnce is, they were more precise and less headache filled when it came to other components that needed to be registered/added.