NSIS Integration with Visual Studio.NET

Based on the amount of traffic my blog post that talks about auto-generating NSIS scripts with iNSISt has generated, I’ve decided to go ahead and create a product that nicely integrates NSIS with Visual Studio.NET and allows people to use NSIS from within their Visual Studio projects. I’ve created similar things before and believe I can do it in a relatively short timeframe.

To those of you reading this because you stumbled upon this blog while looking for just such a product: Please leave a comment and tell me how you think a product like this should work! What would you like to see? What should it do? What features do you like or dislike about similar products for other installers (like Lexpa’s Inno Setup, for example)?

I can venture forth using my best guess and create something, but we all know as developers that products tend to be much more successful and useful when built upon a solid set of requirements.

Also, I’ll probably use this product as a springboard to get my software business up and running (even though I know it means I’ll probably be branching outside of only serving the travel industry like I had originally talked about). Along those lines, if you’re an experienced developer who would like to join me and help create this product, please leave a comment with a way to contact you and let me know. And since this product will most likely be developed as a Visual Studio Package, experience with VS packages and/or programming against COM interfaces would be a plus.

Auto-generate NSIS Scripts with iNSISt

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.