Questions about windows installer

[Dan Ullman]

Is there any SF 7.x to Windows Installer migration information/documentation?

Edit: Never mind, found the answer. You folks really need to start offering migration tools.

[Brett]

Dan,

The problem in this case is that migration would be nearly impossible. The products are just way to different in their nature and underlying technologies. For example, all of the scripted logic in SUF70 would not translate well to SUFWI. However, perhaps we can develop a migration guide in the help file to help point you in the right direction.

[ebts]

Our company has been working with SF since version 5 (we've also recently purchased one of your media products). We've been quite happy with the product and have invested significant time and effort in creating some sophisticated installations for a range of products. We considered switching to another installation product when we moved from SF6 to SF7, since we would have to re-write all the scripts anyway. We eventually decided on SF7 because it was relatively easy to use, yet powerful enough to handle all of our needs. Now that we're faced with re-writing everything again in order to move to MSI installers, I'm reluctant to buy another SF product.
I realize the technical challenge of making the scripts work in an MSI database is pretty steep, but I believe it should be possible, at least to some extent. We went as far as to wrap a SF7 installer into an MSI database for one of our recent products, so I know it's possible to have the MSI installer launch a compiled lua script. I'm prepared to believe that it's not worth the development effort for you. But it is going to cost you some customers, and we'll likely be one of them. We just don't have the resources to keep re-writing all of our installers.
Ed Bradshaw
Transoft Solutions

[Dan Ullman]

Which is also my problem. The upgrade from 5 to 6 was easy. Between 6 and 7 it was cost a bundle in my time to convert the projects. It looks like the upgrade between SF7 and Windows installer is going to be much the same.

A tool that could do even 30% of the work would be welcomed.

[Ted Sullivan]

Thank you for your input on this. If enough people find it would be helpful to at least bring your file list in, we'll definitely do it. That's not a problem. To be clear, the problem is that the MSI format is fundamentally less flexible that a "scripted" installer like Setup Factory 7.0. Setup Factory for Windows Installer isn't an upgrade or replacement for Setup Factory 7.0 - it's more an issue of whether or not you need to create MSI format installers. They're simply too important to ignore, despite them being fundamentally different.

Please keep those suggestions coming. We'll do everything we can to help ease you into Setup Factory for Windows Installer.

[JXBURNS]

To put my oar in here Windows Installer is notoriously difficult to control and SUFWI has done a very good job at controlling the beast with, I'm sure, much more to come as it is updated.

Although I too initially thought we were getting a product that may supplement SUF7 I quickly realised this could not be done due to the very nature of Windows Installer requirements which is basically a serial, start at the top and end at the bottom approach and don't even think about looping around.

During product development there were a number of items added following suggestions from users, available in SUF7, which helped no end with creating a project; registry import & class automation being a couple of examples. The bootstrapper element itself introduced a whole new programming control language similar to the LUA in SUF7.

I have used most of the Windows Installer packages available on the market and I have to say that SUFWI is now my installer of choice as I have been able to build installers extremely quickly compared to other software. Most importantly they work which I have been frustrated with on certain products.

Personally I think SUFWI needs to be treated as a brand new product nothing to do with SUF7. Perhaps the naming of the product has produced some confusion as to what it really is.

Rgds John

[Lorne]

In many ways Windows Installer is a big, ugly, complicated mess of a technology. Although we've put a lot of effort into making Setup Factory for Windows Installer as easy and approachable as Setup Factory 7, on the inside it's a paradigm shift.

Windows Installer as a technology provides some key advantages, but it comes with a lot of rules and restrictions.

When you don't need to create an MSI installer, using a scripted or "procedural" installation technology like Setup Factory 7 can be much easier. It avoids all the complexity of the Windows Installer technology, and just lets you get the job done.

When you want or need to create an MSI installer, using a tool like Setup Factory for Windows Installer is a smart choice, because it tries to make it as easy as possible to cut through all the complexity. Of course, building an MSI installer means you need to follow all of the rules that MSI installers are supposed to follow.

I think it would be almost impossible to automatically convert a procedural SF7 installer project into a declarative one for Windows Installer without stepping all over the rules and guidelines for a best-practice MSI setup.

As for adding a Lua custom action, we've actually given that a lot of thought, and we may still add one in the future. However, many of the things that are done with Lua in SF7 should really be done declaratively in MSI so they can be properly undoable and transformable etc.

[Dan Ullman]

Another question. I keep seeing this: "Plus, you'll get a FREE 1 Year Maintenance Plan which includes access to all major and minor updates as well as technical support."

I cannot find any information about on going support. I am assuming you are going to offer another Maintenance plan after one year. Do you have any idea about pricing? Also, after one year will access to all updates stop if you don't purchase a new plan or will it just mean you are not entitled to free support?

[Ted Sullivan]

Hi Dan,

Here's the info on the maintenance plan:
http://www.indigorose.com/setup-fact...er/support.php

The unique thing that we're doing with Setup Factory for Windows Installer is the Rapid Release Program. Rather than putting out a few minor updates and fixes, and holding off on major features until a major version number change (and hence an upgrade fee), we'll be putting new things into the product on a regular basis.

Renewal pricing for maintance plan (after the first year) hasn't been fixed in stone yet. The expectation though is that it will follow industry norms and be a fraction of the cost of a new license.

[Tuberculosis]

Originally Posted by Ted Sullivan

Renewal pricing for maintance plan (after the first year) hasn't been fixed in stone yet. The expectation though is that it will follow industry norms and be a fraction of the cost of a new license.

I HATE renewal license... much better to be able to skip a version here and there and then upgrade, in many cases. I've always found to skip a version works better for me most of the time anyway. Renewal locks you in no matter if the company throws in a bunch of stuff you don't need and call it an upgrade.

Anyway.... windows installer... I don't think I need to develop msi files just yet, but I'm not sure. I purchased SF 7 last august, so I'm really confused if I need SF 8 or move to WI 1... the only thing I see so far is that it allows for some type of registration in vista.... I don't understand how that would impact a small company, like mine. Would it? So far all of my products seem to install fine....

Many of the products here have made me confused though.... like the patch line and such. Guess I'll have to read on each one to make sure I'm understanding the different lines... seems like a blur when you read at 3000 feet.

[Lorne]

Originally Posted by Tuberculosis

I HATE renewal license... much better to be able to skip a version here and there and then upgrade, in many cases. I've always found to skip a version works better for me most of the time anyway. Renewal locks you in no matter if the company throws in a bunch of stuff you don't need and call it an upgrade.

This isn't that kind of renewal license. Our subscription gives you full access to all of the versions (including major versions, minor updates, bug fixes, etc.) that were released during your subscription, even after your subscription lapses -- so essentially forever. In addition, we're following a different release model for this product. Instead of building version 1.0, then waiting a year and packing everything into a "version 2.0," we're just going to keep working on it from this point on, making it faster/better/easier to use/whatever our customers need it to be. Any version numbers from this point on are largely irrelevant -- the version numbers are just a communication tool to show you how much progress has been made, so you can judge for yourselves whether you want or need to extend your subscription.

Although I'm sure we'll be offering a good deal when it's time to renew, you will be able to restart a lapsed subscription at any time, so if for some reason you want to wait for a few versions at the end of your year, you'll be able to do so. Our job is to prove that it's worth keeping your subscription active to benefit from the ongoing development.

The new subscription model really isn't much different from our existing model, and if you examine it closely you'll see that the changes actually benefit the user quite a bit. This isn't some greedy corporate money grab -- we're just trying to simplify things so we can focus our efforts where they need to be, and keep providing our customers with tools that help them work smarter.

[Tuberculosis]

Originally Posted by Lorne

This isn't some greedy corporate money grab.

Sorry... no, I did not suggest that... but the only renewal I've dealt with was (is) handled very bad... if you don't get a new contract at the end of the year, and wait two years, the customer still has to pay the last two years or full price for the product, whatever is cheaper.

When the term "upgrade" goes away, things get sticky, from my experience... but maybe you guys/gals will be different. I've already recommended your products to several people already... after seeing what I've done with ams, I had one person purchase the product... I also commend your company for not releasing a "vista" update for the heck of it... instead doing a free upgrade.... I've seen many companies simply release a paid upgrade to move to vista.

Guess I'll just have to wait and see what happens with your new price structure.

[ebts]

Originally Posted by Lorne

I think it would be almost impossible to automatically convert a procedural SF7 installer project into a declarative one for Windows Installer without stepping all over the rules and guidelines for a best-practice MSI setup.

As for adding a Lua custom action, we've actually given that a lot of thought, and we may still add one in the future. However, many of the things that are done with Lua in SF7 should really be done declaratively in MSI so they can be properly undoable and transformable etc.

I accept the first point. Automatically converting from a scripted SF7 installer to an MSI setup would be nearly impossible and I can't imagine that it would work very well.

Adding a Lua custom action would be helpful in the transition though. As I mentioned earlier, we have lots of custom lua code that would take a long time to reproduce in an MSI installer, if it could be reproduced at all.

[Lorne]

Originally Posted by ebts

Adding a Lua custom action would be helpful in the transition though. As I mentioned earlier, we have lots of custom lua code that would take a long time to reproduce in an MSI installer, if it could be reproduced at all.

Noted, and thanks for the feedback, it's very helpful.

If the Lua code doesn't involve anything that needs to be undone during uninstallation, you could put it in the bootstrapper. The bootstrapper supports almost all of the actions that SF7 does.

Another way around it would be to run a silent SF7 setup from the MSI using a custom action. This kind of "Trojan horse installer" is generally frowned upon because it circumvents a lot of the benefits of MSI (such as being modifiable using transforms, etc.), but it would get the job done.

[ebts]

Originally Posted by Lorne

If the Lua code doesn't involve anything that needs to be undone during uninstallation, you could put it in the bootstrapper. The bootstrapper supports almost all of the actions that SF7 does.

Most of the more complicated scripting happens around the SF7 dialogs. The scripts are used to control the dialog sequence and do error checking of user input. We have a number of different installation configurations, so the dialog sequence and installed components can vary widely.
I'm assuming there's no way to show dialogs with the bootstrapper. But maybe we could use the bootstrapper to launch the old SF7 installer for the dialog portion of the installation, then use the MSI installer to do the actual installation work.

Originally Posted by Lorne

Another way around it would be to run a silent SF7 setup from the MSI using a custom action. This kind of "Trojan horse installer" is generally frowned upon because it circumvents a lot of the benefits of MSI (such as being modifiable using transforms, etc.), but it would get the job done.

This is what we've done in the past. As you say, it works, but it's not really an MSI installer. It's not really a viable long term solution.