I have a need to describe deployments/installs, and possibly uninstalls as well - but I don't want to use Windows Installer. At the same time, I don't want to completely re-invent the wheel.
It occurred to me that I could perhaps use the WIX declarative schema, but create my own "WIX interpreter" that will perform the install / uninstall steps (as described by a target WIX xml document) without using the windows installer.
It would be nice to go a step further, so that I achieve a cross-platform (Linux, MAC) installer-interpreter. Of course WIX did not have Linux and MAC in mind. In which case I either add xml namespaces to extend WIX, or use some other industry format (that I am yet unaware of).
But perhaps I'm stretching too far. At the very least it would be nice to have a WIX interpreter or a WIX install executable that does not create any records in the windows installer. It need not fulfill every capability of the windows installer. I'd just like to see some basic capabilities fulfilled.
Does anyone know of such a thing, so I can save myself the effort of making it myself?
Each operating system has their own means of managing installed packages.
That means that if you implement your own package management scheme, it will not integrate well with the current operating system standard. This has a number of very bad side effects, mainly the people maintaining the operating system through standard tools run a high risk of not knowing your software was installed because the standard tool didn't report it was installed.
Microsoft's installer is quite different than many other installers, and it supports extension via programming, which is typically done in the VB C++ language. Also, Microsoft supports the mixing of configuration and installation, while many other package managers see these as different functions to be performed at different times. Finally, Microsoft attempts to ask for the configuration information PRIOR to installation, while installers that separate out the role of configuration and installation typically request that the configuration be done AFTER the program is installed.
In truth, there are way too many different "assumptions" about what constitutes installation, and when / how to do said items, and what tools can be expected on particular platforms to easily merge "all items" into a single multiple-system installation tool without the vendors coordinating a little bit to allow for some compatibility.
Related
I have a quite complicated build process involving different directories (for plugins) ; currently using NSIS on Windows and PackageMaker on OSX but have issues improving them as my install / uninstall process is getting more complex with time.
The more I look into it, the more I feel like I should code my own cross platform installer with a cross platform GUI like wxWidgets (I've used it before) and copy myself the right files in the right directories because I cannot find any good cross platform software installer OR even programmatically customizable software installers for both platforms.
Has anyone gone down that path ? Does anyone know what are the hardest things to achieve, blocking everyone to produce good softwares installers and why doesn't this exists right now ?
Thanks in advance!
Does anyone know what are the hardest things to achieve
The hard part about installers is not wizard GUI, it’s OS integration. That integration is dramatically different across OSes.
On Windows, you need to use MSI. NSIS doesn’t do particularly good job, MSI enables repair/modify functionality, by default MSI can upgrade stuff even when old version is still running (and it continues running while being replaced), some MS libraries ship as *.MSM merge modules… BTW, I usually use WIX for that.
Similarly, on Debian and Ubuntu Linux you need to create .deb packages. Even if you’re making a GUI installer. They also support repair & upgrades, versioning, dependencies, but they do it in completely different way than MSI.
I don’t have much experience with OSX but I think it has some other installer infrastructure implemented by the OS.
What's the best way to distribute a windows application:
Which format should i use to distribute the application, an exe-file
or a zip-file?
Should i sign the application?
Are there any other points i should take into account?
I'm going to create an installer for the application using innosetup. The application is made using node-webkit.
(I'm not a Windows user, but) MSI package is better than both an exe-file and a zip-file. The freedom to choose interactive or unattended [un]installation, and the ability to handle dependencies and upgrades are enough to make it the best option. WiX makes MSI creation easier -- give it a try.
So long as the application deploys - it makes no functional difference the data format you choose to distribute in.
I will speak from a user perspective as opposed to a technical one here; please include a CLEARLY LABELED installer (MSI is the best for this; but if it is .exe, or .bat or whatever, label it as "Installer" or "Click to install" or something similar) and a useful readme, if you do choose to distribute in a .zip.
It all depends on what the exe entails. If it's just a simple .NET executable and it's self contained, all you need is the exe in a zip (pending it's < .NET 2.0 which is included). Each newer succeeding version of Windows has .NET runtimes built into the OS incrementing all the way up to 4.5 or 5.0?
So if you have the latest Windows, and it has the .NET 4.5 libraries on it, all you need is essentially the executable. However if it is an older OS, you may need to bundle or link the runtimes needed. Some apps need third party components installed and other DLL's. In which case your best bet would be to use a third party tool like Install Shield or Wise, or Orca, where you can customize the install and install third party components like SQL Server Personal, Oracle Personal or mySQL Database or Crystal report components.
Also if NTFS permissions and network permissions are required or registry values are required you'll need to script it with Wise, InstallShield, etc, and require elevated permissions. Microsoft also has some built in Deploy Once(?) tools that allows this to be done via the web, or network path or executable.
It all depends on the complexity of your exe, how much it effects your system etc. I've seen apps that require even firewall exceptions, etc. If you are in a corporate environment and have a domain you can deploy using SCCM/SMS or UniCenter. Like I said it all depends on complexity, and scope.
If it's a simple .NET 2.0 app, then all you need is the exe in a zip. The best way would be to copy the exe to a few different systems and test it.
MSI's are inherently able to execute from shell or run/explorer. Also you are allowed to compile your install into a self contained executable.
Bottom line, it all depends on your app :)
Does anyone know any good software packager other than InstallShield?
What software did MS use to create the Visual Studio 2005/2008 installers?
Also, does it make sense to just use a "general purpose" language like C# to create an installer rather than using software packagers?
Thanks!
Advanced Installer.
I have been using it for ages, and it works very well
I try much tools and programs to create a windows installer package and i concluded that
Advanced Installer is easiest ad intuitive to use!
I use it from several years and i've found few problems.
Another factor in his favor is a fast and efficient technical support.
I hope this help
NSIS has a front end app, which is now been distributed for free, called venis http://nsis.sourceforge.net/Venis_IX. venis abstracted the details of nsis.
Have a look at the nullsoft installer http://nsis.sourceforge.net/Main%5FPage , which is free.
It does not use the Microsoft MSI system which may (if you ask me) or may not be a good thing.
I use Inno setup , very nice.
and there is a GUI tool ISTool to help you write inno setup script.
I'm using NSIS or Inno Setup.
I wrote wpkg, that you can find here http://windowspackager.org/ (it is GPL) and is a clone of dpkg + APT both together. So it packages and then manages any number of packages in repositories that you can update + upgrade in an automated way. As long as you can install your project files (i.e. make install type of thing) then you'll be able to generate packages in no time.
If you know / use Linux and line their way of handling their software installations (dpkg + apt-get or rpm + yum) then you'll like wpkg since it is a duplicate of that sort of functionality.
The software version is still 0.x.x but it is already in production (very stable as I have strong unit tests to prove that a very large set of functions are working as expected.)
Note that wpkg not only works under Microsoft Windows to package binary objects, it also works under Linux, MacOS/X, and compiles + runs under a few other Unices.
The wpkg implementation includes full support for batch scripts (shell scripts for Unices) to automatically initialize or finalize package installations. This includes the ability (for example) to start a server automatically once the server binaries where installed.
We are also working on a graphical tool, pkg-explorer, that can be used to ease the management of an installation target (you can have as many installation targets on a single computer, as long as you don't install software that require the use of uniquely available resources such as a DVD writer or port 80 on your network.)
The project comes with different tools. One allows you to transform your list of projects in a graph representing the dependency tree of your repository. Another creates a list of HTML files so you can list in an easy to access all the packages that you have available in your repository.
I want to create an installer for my project, primarily to handle the external dependencies which are starting to grow in number.
The problem is most of these components seem to be distributed in different manners, so I need an installer that can cope with all the following. Ive looked at various things around, however many dont seem to cover all the things I need (like how to install directX using a Visual Studio setup project...), or dont even create a proper windows installer (eg .msi).
Copy all my apps files to the target directory
Create start menu and desktop shortcuts
Install direct x (ie call dxsetup.exe /silent)
Install the VC9 CRT redist (seems to be a "merge module" looking at msdn whatever that is...)
Only requires administrative rights if one of the following is true
DirectX and/or the VC9 CRT is not already present, or needs updating
Installing for all users
Installing to a directory the user doesnt have write permission for
Can roll back everything if installation is aborted before completion
Generates an uninstaller as well as an installer
Ensures the user accepts all required EULA's (my one, VC9 Redist, DirectX, etc)
For example I got the VS2008 Setp Project working for my app files and the VC9 CRT, however I dont see anyway to tell it to just run dxsetup.exe with the /silent argument and NOT extract it and all the other dx installer to the app directory or something...
EDIT:
Also it would be really nice if I could have a unified installer for x86 and x86-64, which installers the correct components (eg myapp_x86.exe or myapp_x64.exe) depending on if the OS is 64bit or not.
EDIT2:
Forgot to mention but either a free or low cost solution would be welcome as well, since I need a solution for some of my smaller personal stuff as well.
WiX is what you want. You'll want to read through the v3 documentation and examples, as it is not a simple thing to use. Once you get going, you'll have follow-up questions which you should post as new questions.
See also the WiX tutorial, but keep in mind it refers to v2, and a lot of it is out-of-date or obsolete in v3.
If you can afford it, Installshield does all this very well and professionally. It will include the merge file and seamlessly install as well. Installshield has its quirks, but it is incredibly easy to use and robust. Once you write your app, you don't want to think a lot about the installer.
Some nice features I liked
Creates patch installs by diff'ing the source so you can distribute patches with a small size.
Create upgrades that update the registry and version number of your app. Prevents older versions from being installed.
Creates an nice uninstaller.
It's Easy to add merge modules.
Scriptible if you need it to be, GUI if not (most of the time you don't need to script a thing).
If you can't afford that, go with NSIS. It is very powerful and well used, but prepared to write code in a text editor.
Follow these STeps
I've written an application using gtkmm and libpcap under Linux. Of course, gtkmm depends on GTK+.
After porting it to Windows and attempting to distribute it, the feedback I received is that there are too many dependencies to install.
The user has to run installers for the GTK+, gtkmm, and winpcap runtimes before they can run my little application, which admittedly is a pain.
GIMP for Windows seems to use an installer that launches a GTK+ installer if needed, but doing that for three different libraries seems a little excessive, especially in terms of the installer size.
Is there a better way to distribute this? I believe winpcap actually has to install a service, so it probably has to run the installer, but maybe I could bundle the GTK+/gtkmm libraries in the runtime folder?
I'm quite a bit more familiar with Linux development, so I'm not sure what the best course of action is.
I highly recommend using a tool like Advanced Installer to deal with this for you. Making a proper installer on windows is a real headache, so it's well worth your time to use a GUI tool to help you out. AI (and other installers, for that matter) can install and manage windows services, prerequisites, and so on, and in the long run you'll save a lot of time by using a tool like this to help with your deployment. Advanced Installer in particular has very good support for managing different dependencies, along with their associated versions, and it can also install a native Windows service during the install process. They have a freeware version, but depending on the nature of your product, you might want to spring for one of the commercial versions.
Basically, if you're serious about deploying on Windows, you should invest the time (and money, possibly) to make a proper MSI-style installer. Not to knock the NSIS crowd, but making non-standard Windows installers always results in a lot more work for the developer, and a more uncomfortable experience for the end user.
If you want to manually package the GTKmm runtime, see this link at gnome.org for more details (look under Redistributing). You can also silently run the GTKmm installer using the /S flag.