Update: Before you read the post below, you may want to look at this post that talks about integrating NSIS with Visual Studio.NET.
I’m feeling pretty happy right now because I posted my open-source iNSISt Framework on CodePlex only a few days ago and have already had 18 downloads!
And now a little background on what I’m talking about for those who don’t know…
NSIS stands for “Nullsoft Scriptable Install System” and is an open-source platform for creating installers (a.k.a. “setup wizards”) on the Windows platform. It competes with products like InstallShield and Wise. It’s stable, flexible, “lean” (the installers it creates are very small), and seems to be just starting to take off a little and gain a dedicated following.
As good as NSIS is, however, one of the drawbacks is that since it uses script files to create installers, those script files (in most cases) must be manually updated as projects change. For example, if you’re using Visual Studio.NET for your development but using NSIS to generate your installer, you must update your NSIS script(s) each time you add files to your project that need to be deployed, change a version number, etc. This gets a bit tedious. While there are “wizards” and code generators and so forth out there to auto-generate NSIS scripts, each one uses its own means to generate scripts, and none natively integrate with Visual Studio.
Since I use Visual Studio.NET myself for most of my development work, I decided to start writing a Visual Studio add-in that would automate the maintenance of NSIS scripts for a project. As I started doing so, I realized that the “back-end” of my product (i.e. the logic for generating an NSIS script) was something that could be re-used elsewhere and perhaps have different UIs put on it or be integrated with products other than Visual Studio to give developers some options.
Thus the iNSISt Framework was born. Check out the CodePlex site for the specifics, but essentially, the framework allows you to define your NSIS scripts as XML files, and then it translates those XML files (using XSLT) into the actual script files that NSIS uses to build an installer. The result is that when your project structure changes, now all that needs to change is the XML file that’s used to create your installer, and the framework can regenerate your script! Also, because XSLT is used to generate the resulting NSIS code, if you need to change the way the code is generated to suit your specific needs, then just change the XSLT!
What I’m hoping in making the framework “public domain” is that other developers will take an interest in it and start helping me maintain it so we end up with a framework that has a lot of flexibility and keeps up with the latest NSIS capabilities.
