About mlerch

mlerch · ‎Aug 05, 2013

Ah..now that is excellent information I never considered. Thank you, I'll have to reconsider.

mlerch · ‎Aug 02, 2013

For anyone stumbling here in the future, what I did was use the -z flag of the command-line builder to set a custom MSI property. Each of my builds is controlled by a line in a batch file, and each line now has a new -z "RELEASETYPE=FREEWARE" (or "TRIAL" etc.), e.g. "C:\Program Files (x86)\InstallShield\2013\System\IsCmdBld.exe" -c COMP -p "C:\work\...MyProject.ism" -r ReleaseName -y 1.0.0.1 -z "RELEASETYPE=READONLY" My Component Condition then checks that custom property to know if it should be excluded by a specific build, e.g. RELEASETYPE<>"READONLY" This allows me to keep my current Function structure and not get excessive with duplicating Components across Features, whose size is not insignificant. Works like a charm. Mark

mlerch · ‎Aug 02, 2013

> Since you can specify more than one release flag in any specific build, combined with the conditional and platform testing at the component level, there are a lot of ways to approach these issues. Right. I'm already doing it Feature based (same as you), it would be a lot more efficient if I could employ use of the Condition property at the Component level, which is specifically what I'm trying to find out how to do.

mlerch · ‎Aug 02, 2013

Under Help for Configuring Component Conditions it states: > Conditional installation of your components can be useful if you are creating different versions of the same product—for example, a trial version and a full version. You might not want to provide full functionality in the trial version, therefore you would not install all of the components. That's exactly what I need to do. I build a Full product msi and a Trial msi. I currently use two different project files. They each contain 3 features: "Common," "32 bit Files" and "64 bit Files." Some of the Components under "32 bit Files" and "64 bit Files" should not be installed for the Trial version. How exactly can I accomplish that? Currently, the "32 bit Files" Feature has a Release Flags of "x86" and the "64 bit Files" Feature has a Release Flags of "x64." Those Release Flags are referenced in the Project Configuration Flags of my Release Configurations, which match my 32bit builds and my 64bit builds. Rather than adding new Features which are essentially "Exclusion" Features which I would exclude for the Trial release, I'd like to simply mark some of the Components under my current "32 bit Files" and "64 bit Files" as "NOT Trial" and add "Trial" as a Release Flag in my Trial Release Configuration. Can this be accomplished? According to the documentation sentences as mentioned above, that's precisely how the Condition property at the Component level can be used. I'm just not sure of the syntax. Thanks!

mlerch · ‎Oct 28, 2009

bryanwolf wrote: Changing the 4th field of a file should result in the file being upgraded. While MSI doesn't recognize the 4th field of a Product Version, the File Version is compared using a separate set of rules described here: http://msdn.microsoft.com/en-us/library/aa368599(VS.85).aspx Thank you Bryan, your post came in right after I posted mine. I wish I had known this earlier, I was under the assumption it was requiring the fourth element, due to the warning appearing in IS. I did seem to have an error in how I was designing my patch. Good stuff - thanks everyone. Mark

mlerch · ‎Oct 28, 2009

Well, despite the warning, it is now replacing the file correctly. I don't know why. I do have a minor upgrade item in place, and changed the ProductCode from the original. Perhaps it is going only on the file timestamp. I'd like to understand why but it's more important that it works. This stuff is confusing when you only do it two weeks out of the year. thanks, Mark

mlerch · ‎Oct 28, 2009

I have been using a minor upgrade, it doesn't work with that. I guess I need to either change the version schema for just our beta or go with a major upgrade, if that will even work.

mlerch · ‎Oct 27, 2009

Hi Cary, I am targeting only the base release. I turned on the "Minor Update to RTM Version" setting in the Patch configuration. However I still see the message, and the file is still not getting updated. It gets updated if I change any but the fourth element of the executable version. Hopefully this is not an msi limitation thanks, Mark

mlerch · ‎Oct 27, 2009

We use them as Major.Minor.Patch.Build, e.g. 9.0.0.138 - major commercial release of 9.0 9.1.0.54 - minor commercial release, 9.1 9.1.1.3 - patch 1 of 9.1 9.1.2.7 - patch 2 of 9.1 now I'm preparing our beta program, and our betas differ only on the fourth number - the build number in our case, and I'm getting complaints about msi not handling file version numbers out to the fourth element. and it's also not working; the file is not getting updated. yet. 🙂

mlerch · ‎Oct 27, 2009

I'm trying to provide customers continual updates on a product executable which will differ on what we use as the build number - the fourth number, for instance: 10.2.0.1 10.2.0.2 10.2.0.3 When building my patch I get this: The product version '10.2.0.2' differs from the product version '10.2.0.1' but only past the third element. The Windows Installer does not detect version differences past the third version element. Is this possible?

mlerch · ‎Oct 22, 2009

This was it! When I would change ProductName, it created the msi filename based on that, and threw the error. To fix it, I changed ProductName to what it should have been, matching the previous msi ProductName. I then went into the Releases View > Product Configuration properties and set the "MSI Package File Name" to match the msi filename of what I was upgrading. This created proper release msi's with the right filename, but with the 'friendly' ProductName of the previous release, thus showing it properly in Add/Remove Programs. Yes! My one remaining bug now fixed. Beers all around. 🙂 Lurean wrote: On the releases view under the configuration settings you can set the product name, but further down the list you can specify the MSI Package File name, this is the name you need to make sure matches the old MSI filename.

mlerch · ‎Oct 22, 2009

That's very helpful, and makes perfect sense. Thanks much. Mark

mlerch · ‎Oct 21, 2009

Thanks. Yeah, at first I assumed I wouldn't have had to do anything, that it would simply use the previous value. Only when I noticed it as wrong in ARP did I set about trying to fix it and - no dice. I do have paid support. Unfortunately for me it has been abysmal. I emailed them last Friday, they got back to me today - 6 days later - with a "send us a screenshot of the ARP window." Um? This was after I went into great detail talking about the contents of my tables, etc. So I tried to bite my tongue and reply as politely as possible. Haven't heard back yet, but these forums are far better. We turn out product twice a week, I need support in a day, not once a week. Mark

mlerch · ‎Oct 21, 2009

Why is the default value of REINSTALLMODE "omus" when you create a new Patch Configuration, but the recommended value when executing msiexec on the command line "vomus?"

mlerch · ‎Oct 21, 2009

The new msi filename does match the old msi filename. That isn't the problem. The problem is with the Product Name as it is appearing in Add/Remove Programs. What shows up there when I run the Upgrade is the msi filename. If I try to change anything in the Upgrade project file (which is Basic MSI) to correct it, it is then that I get the error about the product name not matching the previous installation. When I open the msi file used in the previous installation, the Product Name is as it should be. When I open the upgrade msi and view the Property table, the "ProductName" field contains the msi filename, not the product name as it does in the prior msi. If I try to correct it, I get the error about Product Name mismatch.

Online Status	Offline
Date Last Visited	‎Mar 18, 2019 12:10 PM

Re: Conditionally installing Components based on Release Flags

Re: Conditionally installing Components based on Release Flags

Re: Conditionally installing Components based on Release Flags

Conditionally installing Components based on Release Flags

Re: Using the fourth version element on patches

Re: Using the fourth version element on patches

Re: Using the fourth version element on patches

Re: Using the fourth version element on patches

Re: Beta versioning best practice?

Using the fourth version element on patches

Re: Product Name on Upgrades for ARP

Re: REINSTALLMODE "v" not used in IDE?

Re: Product Name on Upgrades for ARP

REINSTALLMODE "v" not used in IDE?

Re: Product Name on Upgrades for ARP

Re: Conditionally installing Components based on Release Flags

Re: Conditionally installing Components based on Release Flags

Re: Conditionally installing Components based on Release Flags

Conditionally installing Components based on Release Flags

Re: Using the fourth version element on patches

Re: Using the fourth version element on patches

Re: Using the fourth version element on patches

Re: Using the fourth version element on patches

Re: Beta versioning best practice?

Using the fourth version element on patches