I'm working on an installation and configuration application in C# for a project I'm working on, and I'm wondering what the best method of internally organising everything is.
Requirements:
Single executable for deployment, no other files bundled with it.
Has to support custom config steps on each panel, which contribute to a generated XML config file at the end.
Certain steps may be skipped based on certain choices made within the installer flow.
Must support dynamic config screens based on information fed back from classes in one of my libraries.
Here's a description of my prototype:
A large form with a bunch of Panel controls, each representing one "screen" of the wizard. Each is named appropriately.
A class for each "screen", deriving from a base type I defined. I call specific methods of it (e.g. Enter, Back, Forward) when certain events occur.
State is stored as a Dictionary<string,object>, which is passed to each screen. The final screen (the actual "Installing..." screen) reads config out of this and dumps it into the XML file.
Each screen's code is responsible for handling the "Next" and "Prev" buttons, so I can control where it jumps to based on settings in the current screen.
A number of modules are stored in my library which provide information about extra config steps that need to be taken. I'm implementing this through reflection and automated UI generation.
Assets are stored in the resources of the executable.
I don't want to use a generic installer package (e.g. InstallShield) because the logic is totally custom and calls upon one of my class libraries. What I would like to know is - am I setting this out in a really circuitous way? Is there a simpler or more standard way to wizard-style applications?
Here's the short answer:
A commercial tool is perfect for what you need because it supports both custom installation UI and dynamic XML files. Anything else requires a lot of learning and hard work.
And the long explanation:
A custom installation UI is not an easy task. Windows Installer offers built-in dialogs and controls, so it's usually the best solution. You could also try a proprietary installation engine, but you will need to learn it.
You're also taking an incorrect approach by trying to control everything with custom code and classes. Most setup authoring tools offer direct support for handling the installation UI and XML files. Why try reinventing the wheel?
So you basically need to find the setup authoring tool which is best for you. Here is a general list:
http://en.wikipedia.org/wiki/List_of_installation_software
The tools are either MSI-based or proprietary. Personally I prefer Windows Installer (MSI packages).
Trying to implement all your tasks with custom code is just not worth it.
The only proper way to install software on Windows (which I assume is your target platform) is using Windows Installer. Simplifying a bit Windows Installer is based on the concept of a installation package (a database file) that in a transactional way can be added or removed from the system.
If you write your own installation logic you will not be able to participate in the transactional handling of software installation. If your uninstaller gets deleted there is no way the user can uninstall your software. Also, Windows Installer knows A LOT about the quirks of Windows which you may not be aware of.
Windows Installer provides a somewhat cryptic API for creating packages but you can also use then open source WiX toolset which is quite powerful or any commercial installer like InstallShield.
If you decide to go the Windows Installer way you should try to avoid custom actions if possible. Custom actions suffer from the same "transaction rollback" problem as a custom installer. You create the code for the custom action rollback/uninstall say in a DLL and if that DLL is lost there is no way Windows Installer can undo your custom action.
Windows Installer is actually quite powerful. You havn't given any specific information about the "custom stuff" you need to do but perhaps Windows Installer already has a table for that?
Use InstallShield or the MSI installer. Seriously. In addition to being able to support all kinds of custom logic (including code you specify), the generic installer wizards do things you're not even thinking about, like, say, listing the installed app in Programs and Features, and performing repair installs/uninstalls.
With the level of custom logic you're looking at, I would fork out for the latest InstallShield installer builder; the VS Install project builds into a pretty simple dialog set.
EDIT: Fair enough, been in that position before.
I would still HIGHLY recommend using any generic installer tools you have available, like VS's Install project, for the reasons I stated above; the install packages do things you aren't even thinking about in your design, and you get all of it for free.
Instead of putting this logic to customize your XML config file in the installer, how about putting it in your executable, as a "run-once" configuration wizard that the user will see when they start the application after installing it? It shouldn't be too off-putting to your users, and it should work well if the actual application is also a WinForms app (even if it isn't; you could compile the configurator into a different app and have your main app launch the configurator if it doesn't have an XML file).
Single executable for deployment, no other files bundled with it.
This might of some interest to you : http://blogs.msdn.com/b/microsoft_press/archive/2010/02/03/jeffrey-richter-excerpt-2-from-clr-via-c-third-edition.aspx
Related
I need to create a custom installer to deploy a specific program. But there are a few checks and balances that needs take place during intallation, and even though I have an Advanced Installer license, it just struggles to do everything I need.
I'm looking for a way to create my own msi file using c#. Running the msi file it will then start a win forms wizard, which in turn will do a number of items, including copying files to the host PC.
I'm not sure how I can "include" my set of files into a single msi file. How to you "copy" files into an msi and how can you read again from it?
I can't even give a proper sample code of what I've tried as I don't know where to start.
This just feels like it should be a duplicate question, but I can't find it.
I work at Advanced Installer, since you said you already have a license let's help you get a return of investment on that ;)
First of all, I seriously doubt you need to reinvent the wheel and write your own code that installs/copies files on the machine. This is a basic action performed by all installer authoring tools, and even though it seems simple when you first think about it, it is not. You don't want to write code that handles rollbacks (if your install fails), reference counts (if a file is shared somehow), repair/self-healing operations (if somehow a DLL gets corrupted or missing post-install), or cover other standard Windows Installer scenarios.
Since you didn't explain with full details what you are trying to do I will give you some short example on how to do each of the steps you mentioned:
Adding files in a setup package - this is a link to a tutorial created with a free edition, but the same steps apply for Professional and Enterprise editions.
Searching files on a disk and retrieving values from them. - for this, you need to use the built-in support from Search page. There you can either simply search for a file and return its path or search for an element inside an INI or XML file and return its value inside a property.
Windows Installer properties are the equivalent of variables in your code. You can use them all over the installer project to pass/get/validate values.
Designing custom dialogs. Most professional installer authoring tools have support to build custom dialogs. The previous link is for a tutorial on how you can do that with Advanced Installer.
During the UI stages, you can include and custom C# code to perform additional validations or data retrieval operations and pass that to or from the installer using properties. if you need it.
The custom installer dialogs support is available starting with the Enterprise edition. The Professional and Free editions include the standard dialogs, but with no options to customize them.
Another way to interact with users is to design an UI experience inside your application that is visible only when the users launch the application for the first time. So, this is not a part of your installer. It will be code that you write inside your application and you can provide a first-launch experience similar to what you see when you install Office for example. If you can give me more details on what you want to do/capture in those custom dialogs, I will try to recommend you the best approach.
For a testing usage of not very complex WPF applications I often don't make installer - just, after building project, copy Bin>Debug folder content of a VS2008 project folder to a hard drive of a user computer and put an icon to a desktop. No records to windows registry.
Are there any drawbacks of such a way of using windows applications for testing period?
There's nothing wrong with this approach at all - it is what's called xcopy deployment. You don't get a few things doing it this way:
an entry in the add/remove programs for users to uninstall with
the ability to add shortcuts to desktop/start menu/quick launch
any changes to the registry for settings etc...
Another benefit is that you can get your application onto a computer by a user who does not need administrative privileges to install.
It really comes down to your requirements. If you don't need any features of an installer, then just copying the files is a good approach.
I'd agree with the other comments about using a release build though - especially if you are deploying for real use and not just testing.
The only change you might want to make is to build the app in Release rather than Debug and take the files from the Bin>Release folder.
more info: http://haacked.com/archive/2004/02/14/difference-between-debug-vs-release-build.aspx
When you have multiple files to deploy along with your exe, dll's to register, file associations to set up, then an installer is a neat way to deliver all of that in a reliable manner. If you don't do this with an installer the user could easily screw things up.
In addition to that, the installer is sometimes used as a means to ensure the computer is truly ready for the application. For example, the installers I've written check to ensure the proper version of .NET is installed, and will download & install it if necessary.
However, there are many times when these characteristics are simply not worth it and deploying a standalone application in a single exe is perfectly acceptable. Simple applications that don't need to store a lot of settings on your computer and don't have a lot of prerequisites are perfect examples. The first thing that comes to mind are all the utilities from Sysinternals.
I see only one potencial drawback. There is nowthing wrong in your approach as long as you don't have more than 1 to 3 users and changes during test session are not often.
When changes are often and you have to copy library to more than 3 users (hosts etc.) the drawbac I mean is maintenance time. I know what I'm talking about because in place where I work, we have such issue.
Last time I've started to more taking care about maintaining our application and copying files from one host to another than coding. :(
In my honest opinion sometimes is better to invest your time on the beggining and write an installer than have a lot mainteneance and copy things later.
To solve the number of users problem, there's a very simple solution that does not require to setup a full installer.
Basic setup for multi-users xcopy/.bat deployment:
A shared drive, with one folder for the .bat files, one for the binaries.
Upload the binaries to the shared
drive and update the install script
if needed.
Have every user run the install script.
By the way, some very complex information systems are ENTIRELY deployed by .bat files (even when not testing!).
I need to create a patching routine for my application,
it's really small but I need to update it daily or weekly
how does the xdelta and the others work?
i've read around about those but I didn't understand much of it
the user shouldn't be prompted at all
Ok this post got flagged on meta for the answers given, so I'm going to weigh in on this.
xdelta is a binary difference program that, rather than providing you with a full image, only gives you what has changed and where. An example of a text diff will have + and - signs before lines of text showing you that these have been added or removed in the new version.
There are two ways to update a binary image: replace it using your own program or replace it using some form of package management. For example, Linux Systems use rpm etc to push out updates to packages. In a windows environment your options are limited by what is installed if you're not on a corporate network. If you are, try WSUS and MSI packaging. That'll give you an easier life, or ClickOnce as someone has mentioned.
If you're not however, you will need to bear in mind the following:
You need to be an administrator to update anything in certain folders as others have said. I would strongly encourage you to accept this behaviour.
If the user is an administrator, you can offer to check for updates. Then, you can do one of two things. You can download a whole new version of your application and write it over the image on the hard disk (i.e. the file - remember images are loaded into memory so you can re-write your own program file). You then need to tell the user the update has succeeded and reload the program as the new image will be different.
Or, you can apply a diff if bandwidth is a concern. Probably not in your case but you will need to know from the client program the two versions to diff between so that the update server gives you the correct patch. Otherwise, the diff might not succeed.
I don't think for your purposes xdelta is going to give you much gain anyway. Just replace the entire image.
Edit if the user must not be prompted at all, just reload the app. However, I would strongly encourage informing the user you are talking on their network and ask permission to do so / enable a manual update mode, otherwise people like me will block it.
What kind of application is this ? Perhaps you could use clickonce to deploy your application. Clickonce very easily allows you to push updates to your users.
The short story is, Clickonce creates an installation that allows your users to install the application from a web server or a file share, you enable automatic updates, and whenever you place a new version of the app on the server the app will automatically(or ask the user wether to) update the app. The clickonce framework takes care of the rest - fetching the update , figure out which files have changed and need to be downloaded again and performs the update. You can also check/perform the update programatically.
That said, clickonce leaves you with little control over the actual installation procedure, and you have nowhere close to the freedom of building your own .msi.
I wouldn't go with a patching solution, since it really complicates things when you have a lot of revisions. How will the patching solution handle different versions asking to be updated? What if user A is 10 revisions behind the current revision? Or 100 revisions, etc? It would probably be best to just download the latest exe(s) and dll(s) and replace them.
That said, I think this SO question on silent updates might help you.
There is a solution for efficient patching - it works on all platforms and can run in completely silent mode, without the user noticing anything. On .NET, it provides seamless integration of the update process using a custom UserControl declaratively bound to events from your own UI.
It's called wyUpdate.
While the updating client (wyUpdate) is open source, a paid for wybuild tool is used to build and publish the patches.
Depending on the size of your application, you'd probably have it split up into several dll's, an exe, and other files.
What you could do is have the main program check for updates. If updates are available, the main program would close and the update program would take over - updating old files, creating new ones, and deleting current files as specified by the instructions sent along with a patch file (probably a compressed format such as .zip) downloaded by the updater.
If your application is small (say, a single exe) it would suffice to simply have the updater replace that one exe.
Edit:
Another way to do this would be to (upon compilation of the new exe), compare the new one to the old one, and just send the differences over to the updater. It would then make the appropriate adjustments.
You can make your function reside in a separate DLL. So you can just replace the DLL instead of patching the whole program. (Assuming Windows as the target platform for a C# program.)
Just a quick question:
I'm in the finalizing state of my current C# project, and I'd like to send a version out to people that has 90% of the features initially requested, but it'll be a version of the software that will do all they need - they need the software as soon as possible, basically.
Therefore I'm going to be using the online install option in VS2008 that will use updating to add the final few features, as well as additional things, later. What I'm wondering is the following:
The program will come packaged with a .mdf file. When I create a new version of the program however, I don't want to change all of the data that has been added to the database already. My question is how do I go about doing this?
Thanks!
How are you planning to distribute the update? An installer will have flags indicating when a file should be replaced. (Date, version etc)
One-Click installation has the ability to check for changes on program startup.
I'm attempting to write a custom uninstaller script; however, I'm stuck at the "programs, and features" dialog. Are there any written documentation as to what registry keys do I need to add in order for my application to be displayed there? Or -alternatively- are there any native WINAPI / .NET functions to create a shurtcut there directly?
Addendum: there are business requirements disallowing me the use of third-party tools, such as the default MSI installer. Provided answer should work on a clean XP virtual machine, w/ .NET 2.0 installed, without referencing to any external .dlls. Thank you.
I would imagine MSI installer is the best solution, but if you must, the registry key which is the source of items in add/remove programs dialog is here:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall
I don't know if there's a good documentation about structure of this key, but I'm sure you can figure it out, it's not so hard