Can I do this?

[sabarnett]

I'm looking to replace Wise for WIndows Installer (9) and have download the trial of Setup Factory. Two things have jumped out at me as possible problems and I wondered whether anyone could tell me if these would be issues:

a) I store my files with version numbers in the distribution folder, ipmeuk_3621.dll for example. When installed, I install the file with a different name with the version number removed, resulting in a file called ipmeuk.dll in this case. I can't see how to do this with Setup Factory. I tried specifying a file name in the destination, but it told me it could not create the destination folder.

b) When I install, I check to see if the app has been previously installed by checking a registry key. If the app has been installed before, I do not prompt the user for the install folder, but overwrite the existing code.

I can see how to write a script to use Registry.GetValue and SessionVar.Set to retrieve the install folder, but how can I use this to bypass the folder selection window if I have already determined where the software is or to display it if the app has not been installed before.

Sorry if this is a bit basic - I've only been playing for 20 minutes now, so may have missed something obvious.

Thanks
Steve

[jassing]

a) I store my files with version numbers in the distribution folder, ipmeuk_3621.dll for example. When installed, I install the file with a different name with the version number removed, resulting in a file called ipmeuk.dll in this case. I can't see how to do this with Setup Factory. I tried specifying a file name in the destination, but it told me it could not create the destination folder.

I have one client that does this as well -- The installer I wrote for them does this:
Install the file to the Temp Launch Directory, then use file.install() action to install it as you want.

b) When I install, I check to see if the app has been previously installed by checking a registry key. If the app has been installed before, I do not prompt the user for the install folder, but overwrite the existing code.

I can see how to write a script to use Registry.GetValue and SessionVar.Set to retrieve the install folder, but how can I use this to bypass the folder selection window if I have already determined where the software is or to display it if the app has not been installed before.

You can do a couple of things.
in both instances, you would use the screen "preload" event.

one is to "jump" or "skip" the screen if there is already a value loaded.
The other is to disable the text box& browse button so the user can at least see it.


Sorry if this is a bit basic - I've only been playing for 20 minutes now, so may have missed something obvious.

Where here to help -- anytime you move from one product to another; there's going to be a learning curve.

-josh

[sabarnett]

Much appreciated. Not sure how I feel about having to effectively install my files twice.

It looks like I'm going to have to write more script than I had hoped, but I suppose that's the 'fun' part.

Steve

[jassing]

Much appreciated. Not sure how I feel about having to effectively install my files twice.

It looks like I'm going to have to write more script than I had hoped, but I suppose that's the 'fun' part.

Steve

You're doing things "non standard" so you've got to have a workaround -- you can install the file to the app folder, then rename it. Then you're only installing it once.

If that is such a big deal, then perhaps, SUF isn't a solution for you....

Personally, I find handling my version # in source control over renaming files easier way to go -- too much manual process is bound to create problems down the road.

[sabarnett]

You're doing things "non standard" so you've got to have a workaround -- you can install the file to the app folder, then rename it. Then you're only installing it once.


Not sure how "standard" it is. Wise lets me specify the name of the file I want to install and what I want it to be called on the destination PC. Seemed like a reasonable thing to do to me. For example, as well as the version number in the DLLs I have client specific data files that get distributed. I need to give these a client specific name in the install and an app specific name once installed. As I say, seems quite reasonable.

We also have a facility to be able to re-create the install of any previous version of the software, as we have the previous versions of the files and can specify the version number we want to create. That suits our customers who do no always want to upgrade to the latest version.

If that is such a big deal, then perhaps, SUF isn't a solution for you....

Guess you're right. I was looking for something with similar functionality to Wise and Setup Factory looked like it was what I was looking for; simple installs with scripting. On your advice, I'll go look for something else.

Personally, I find handling my version # in source control over renaming files easier way to go -- too much manual process is bound to create problems down the road.

That's fine if you're only supporting the "latest" version. Some of our clients have to pay third party organisations vast amounts of money when they upgrade an application, so much prefer it if we can deliver fresh install media for older versions of the software. Saves them a fortune.

We've been operating this system for the last 12 years and have not had any versioning issues in all that time. It just takes a little organisation and strict controls over when software gets released from the developer to the installer. No big deal, especially considering the flexibility it gives our customers.

Steve

[jassing]

Guess you're right. I was looking for something with similar functionality to Wise and Setup Factory looked like it was what I was looking for; simple installs with scripting. On your advice, I'll go look for something else.

For some reason "if it walks like a duck, it sounds like a duck, it probably is a duck" comes to mind..

if you want all the functionality of wise, then you should stick with wise, if you want something different, then you should find something different. Gave you two ways to do what you want, but neither worked -- personally; I find suf more powerful and easier to deal with than wise -- but then again; I use suf not wise.

Good luck and sorry to see you go.

-josh

[Lorne]

I'm looking to replace Wise for WIndows Installer (9) and have download the trial of Setup Factory.Just to clarify, you are using the Setup Factory 7.0 trial, and not the Setup Factory for Windows Installer trial, correct?
Two things have jumped out at me as possible problems and I wondered whether anyone could tell me if these would be issues:

a) I store my files with version numbers in the distribution folder, ipmeuk_3621.dll for example. When installed, I install the file with a different name with the version number removed, resulting in a file called ipmeuk.dll in this case. I can't see how to do this with Setup Factory. I tried specifying a file name in the destination, but it told me it could not create the destination folder.That should be fairly easy to do. I can think of a few different ways to approach it:

Use the destination filename in SF7 (e.g. ipmeuk.dll), and rename the file at your end before the setup is built. You could even do this from a batch file using a pre-build step (Build > Settings > Pre/Post Build).
Keep copies of the different versions of that DLL in different folders, with the version number in the folder names, and have SF7 get them from there. In those folders, give the files their destination filenames (e.g. ipmeuk.dll). That way you don't need any pre-build step at all -- you just need to set the correct source and destination folder paths in the file properties.
Install the file with the version number in the name, then use a File.Rename action to rename it in the On Post Install event (Project > Actions). If you have a lot of files with different destination names, there are ways to make this more manageable, such as using a table defined in an external .lua script, or reading in design-time constants.
Install the file to a temporary location and then install it from there with a File.Install action, or copy it over with a File.Copy action, giving it the appropriate name.

Being able to specify a different destination filename might not be a bad option to add, so I've logged it for consideration: 16559.

b) When I install, I check to see if the app has been previously installed by checking a registry key. If the app has been installed before, I do not prompt the user for the install folder, but overwrite the existing code.

I can see how to write a script to use Registry.GetValue and SessionVar.Set to retrieve the install folder, but how can I use this to bypass the folder selection window if I have already determined where the software is or to display it if the app has not been installed before.That is possible as well, as one of our users (jassing) pointed out above.

If you have any other questions, feel free to ask here in our user forums, or contact our support department. (Although we try to monitor these forums daily, they aren't our primary support avenue and we can't always guarantee a response.)

[sabarnett]

Thanks for the response and yes, I am using the SF7 trial.

My issue with the suggestions on the rename is that it gives me too much scope for error. I add a file to the files list and must then go edit the script to do the rename.

In reality, it's also a little more complicated than that. When a user installs a new version of the app, they're not required to delete the old one; they can install over the top, so I would also need code to delete the original file before doing the rename... that leads to mode code to check that the file exists (it won't for a clean install).

I guess I'm looking for the "new Wise" and I though SF7 would be it. I accept that I'll have to change the way things work, but not so radically (I have some very complicated scripts to convert). Still, if there is a chance of adding even this one feature, I can always re-evaluate at a later date. I'm not going to jump ship to the first product I find and there is a lot to like about SF7.

[Lorne]

Thanks for the response and yes, I am using the SF7 trial.

My issue with the suggestions on the rename is that it gives me too much scope for error. I add a file to the files list and must then go edit the script to do the rename.Yep, perfectly understandable. If it were me, I'd use the second method I mentioned above:

Put a copy of ipmeuk_3621.dll in another folder on your system, call it "Renamed DLLs" or something. Rename the file to ipmeuk.dll in that folder. Add that file to SF7 instead of the one named ipmeuk_3621.dll. That removes the need to rename anything, except one copy of the file at your end whenever you build a new version of that DLL.

In SF7, make sure the destination field -- which contains the destination folder path, not including the filename -- points to the location you want.

In reality, it's also a little more complicated than that. When a user installs a new version of the app, they're not required to delete the old one; they can install over the top, so I would also need code to delete the original file before doing the rename... that leads to mode code to check that the file exists (it won't for a clean install).The File.Install action would take care of that for you. However, the method I described above makes that point moot, since there is no more renaming necessary, except once at your end (where it is much easier to manage :)).

I guess I'm looking for the "new Wise" and I though SF7 would be it. I accept that I'll have to change the way things work, but not so radically (I have some very complicated scripts to convert). Still, if there is a chance of adding even this one feature, I can always re-evaluate at a later date. I'm not going to jump ship to the first product I find and there is a lot to like about SF7.With Vista the industry seems to be shifting more attention on MSI installers, but we're still getting a lot of users choosing SF7. And it makes sense. If the project doesn't require MSI, SF7 is just a lot easier to use...you can just get stuff done quickly, and you never have to worry about breaking some obscure MSI rule that will come back and bite you in the butt later.