After almost a decade of working with all sorts of software developers, from small ISVs up to Fortune 500 companies, I can confidently say I have found a method to predict the quality of the software they build. It is based on two simple criteria:
- The competency/experience level of the team in charge of the packaging and deployment process.
- The priority the packaging and deployment process has on the team’s road map.
These two factors set the ground for high-quality software or lots of support tickets coming back to the team.
Successful packaging and deployment teams get the benefit of their experienced leaders guiding the way.
They include packaging and deployment in their planning from the start, when they have their first running builds, never the week before the release.
The outcome of the packaging and deployment process is dependent on its every step: from choosing the right tools that can integrate within the development build system to following best practice guidelines.
The process approach makes your software deployment a smooth experience for your enterprise customers. Remember, the deployment/installation phase is the first interaction your customers have with your product.
You have no idea how often I get the request from development companies to help them package their software products just days before a release.
I’ve put in place a full set of recommendations that will definitely help you control your release process in order to get the best outcome:
- Follow the platform vendor standards (anchor).
- Make your design enterprise-ready.
- Isolate and document the prerequisites.
- Mind the application data.
Be aware of the future of software development.
Advanced Installer Setup
Follow the platform vendor standards
If you take a look at Microsoft’s tools, most of them are packaged as MSI (sometimes wrapped by an EXE bootstrapper to provide additional functionality).
We know that choosing to build self-extractable EXEs or providing a simple ZIP file to your customers is not a sign of high-quality work, and you can be sure your customers will notice this.
Microsoft has multiple packaging technologies but the most used and well known one is the MSI package. This package format was introduced with the release of Office 2000 and has ruled the kingdom ever since.
A properly authored MSI package has built-in functionalities not only for the installation of that package, but also for its repair, modification, or removal, which you would otherwise need to re-invent, wasting precious time and development resources.
Practically, it’s the same advantage you get when you start using the UI controls built by the Syncfusion team. Of course you could build a similar custom control, but your time is more valuable when you use it to work on your app, and choose to use a solid solution trusted and validated by the .NET community instead of reinventing the wheel for every new UI control you need.
It’s the same with Windows Installer (MSI) packages. You could write your own EXE to take care of the installation or use other’s nonstandard solutions, but is it worth it?
Every time I see an uninstall.exe file in the installation folder of an application, it gives me the creeps (Middle Ages flashbacks). Upgrade your benchmark. Adopt one of the free or paid tools (Advanced Installer, Visual Studio Setup Project, Wix Toolset, etc.) to build standard MSI packages and improve the packaging standards for everybody, both developers and the users of your application.
Let’s take a simple MSI package built with any of the above-mentioned tools. The IT pros in enterprises will be happy to find out they can:
- Deploy it silently to all users from the company (using SCCM or similar tools).
- Easily configure the package using standard Windows Installer properties.
- Customize its contents to meet their internal company policies using standard MSI editing tools (customizing shortcuts, adding company templates, etc.).
- Automatically leverage the Windows built-in support for system restore points and automatic repairs for broken installations.
- Generate verbose logging for debugging purposes, if needed.
All this is thanks to the native support from Windows Installer. It requires you, as a developer, to write zero lines of code to get all this good stuff. It’s all there, and the MSI package is what allows your clients to leverage it and improve their business, instead of wasting their time with strange problems arising from non-standard deployment tools.
The Seemingly Magical MSI Package
Enterprise-ready design
If you thought that all your users install your software with full UI—i.e. double-click the installer and click Next through its configuration dialogs—I have a surprise for you.
Large and medium-sized companies deploy their software using remote management tools, like SCCM and others. It’s far from scalable to manually configure each machine, and these companies will kill you with support tickets if your installer is not ready for this type of deployment.
If you plan to make your deployment enterprise-ready, make sure you check these points:
- Your installer provides a command-line switch for silent installation (no UI). This is native for MSI packages. As long as you build one correctly, it will install silently.
- The package is prepared for per-machine deployments. Per-user installs are not feasible for enterprise deployment. (MSIX plans to change this in the future).
- If the package requires user input, make sure that input can also be given as a command-line parameter and note it in your documentation.
- Any custom actions scheduled on InstallExecute sequence must not have user interaction. This can block the installation.
- Avoid triggering restarts during the installation by all means.
- Product activation (license key or file) should be available from the command line, with a transform (MST) or by the end user. If the product needs activation at the end-user level, make sure to avoid requiring administrator elevation, as all enterprise users run with limited rights, having no access to per-machine resources like the Program Files folder or HKLM hive.
- Also build a full offline version of your installer, in case you plan for your default to be a web-based installer (where users download just a small launcher that downloads the full installer package at install-time).
As a final item, but not related to the package contents itself, I recommend a small article on your website as an alternative download page for IT administrators. Here, you should provide a download link for the offline installer that contains only your app, a list of prerequisites (if necessary) and their download links, and the command lines (configurations) for silent deployment.
At Advanced Installer, we’ve prepared this checklist to help you improve your discipline/technique and simplify your packaging process. Give it a try:
Prerequisites
Windows 10 and Windows 7 come with .NET 4.6 (or higher) and 3.5.1 respectively. With these OS defaults, prerequisite distribution might not always be required for your applications.
However, if you have this requirement, make sure you cover it in your documentation as I mentioned in the previous section.
Remember to configure/enable launch conditions in your MSI to stop the installation if any of the prerequisites required by your app are not installed on the system. This will save you lots of support tickets from newbie users.
As a side note, IT admins prefer to install separate packages for the main application and each of its prerequisites. This gives them more flexibility in managing updates for each package separately, and also allows them to share a common prerequisite between multiple applications. The .NET Framework is an example of the latter scenario.
Prerequisites Handled by an Installer
Application data
All packages deployed automatically into an enterprise are installed under the SYSTEM account. This is how SCCM and other deployment systems work.
Bearing this in mind, you should always test your package through an install under the SYSTEM account; you can do this using the free tool PsExec.exe (from the Sysinternals kit).
Deploying packages under the SYSTEM account can affect one major component of the package: the per-user resources that you’re installing. If you are installing such resources as files in the user profile folder or registry under the HKCU hive, these will be installed only for the SYSTEM account under which the installation runs.
To make sure these resources are available for all users running the application, you have two options:
- Install these resources in a per-machine location (Program Files folder or HKLM hive) and copy them to a per-user location the first time your application is launched for that user.
- Install them in a per-user location directly from your installer and then leverage the self-healing support from Windows Installer for the system to automatically copy these resources for every user launching the app.
Both methods are used today throughout the industry, but my recommendation for you, as developers, is to install these resources per-machine and copy per-user for each new user. History has proven that self-healing can lead to unexpected behaviors for some packages incorrectly configured (a little deeper knowledge of Windows Installer is required for correctly configuring setup packages that rely heavily on the self-healing mechanism).
Roaming is one of the most important items on your checklist when it comes to application data. Every Windows user account can store the application data in any of the following two locations:
- Local profile (%localappdata%)
- Roaming profile (type %appdata% in File Explorer)
Most applications use the roaming profile because this profile, as its name implies, “roams” together with the user credentials within the enterprise environment. For users changing workstations, this means that all their app data will be available on any machine they log in to from their domain.
In the case of the local profile, the application data will stay only on the machine where it was created, i.e. it will not be backed up on the company servers and restored on another machine where the user logs in.
The Application Data from Advanced Installer is the equivalent of a roaming folder, which we recommend for obvious reasons, if you choose to implement the self-healing support and deploy per-user resources at install time.
The future of software deployment
Although it is based on the legacy Windows Installer technology, MSI is the most widespread and well-known package format. However, Windows 10 and the Universal Windows Platform (UWP) are setting up the scene for the biggest change in the package and deployment area.
Microsoft already gave us the ability to get current desktop apps into the Microsoft Store without rewriting our code with the MSIX package. This is just the beginning of a new journey for Windows developers. I will share more details about what the future holds and how we get there in a future article.
If you have any questions please let me know in the comments below, or reach out to me on Twitter.
ABOUT THE AUTHOR
Bogdan Mitrache is the VP of Product at Advanced Installer. He can be found on Twitter at @BogdanMitrache.
The post Guest Blog: Packaging and Deploying .NET Apps for Enterprise Customers appeared first on Syncfusion Blogs.
Top comments (0)