Closed Bug 182422 Opened 23 years ago Closed 23 years ago

Version all Win32 .dlls and .exes because MSI repackaging, etc requires it

Categories

(SeaMonkey :: Build Config, defect)

x86
Windows 2000
defect
Not set
normal

Tracking

(Not tracked)

VERIFIED DUPLICATE of bug 50627

People

(Reporter: patpaul, Assigned: netscape)

Details

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2) Gecko/20021126 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2) Gecko/20021126 We use MSI technology, from MS. This lets us deploy Mozilla automatically on machines when they boot. We use an MSI repackager(Wise Package Studio) to do this. This repackager captures the installation, and converts it to MSI(with some handholding). Now, this step works, and we've been using it since 1.0. When 1.1 came out, we did the same thing. We repackaged 1.1, and told Active Directory to upgrade the 1.0 package. This didn't work. The reason, we found out, is that MSI's need all the exes and dlls to be versioned. So, with 1.2, we have(one example) the file nsldap32v50.dll. Since it's not versioned, it wouldn't upgrade the previous version, causing much problems. I would love to be able to put these(more or less) solid MSI's on one of our websites to help fellow administrators who would like to have Mozilla installed automatically on machines, but I can't until this is resolved. The workaround currently is to tell Active Directory that "previous version of program cannot be upgrade; uninstall previous version, install new version", which has not been smooth at all. Reproducible: Always Steps to Reproduce: 1. 2. 3.
*** This bug has been marked as a duplicate of 53727 ***
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
Hilarious that it's a Micro$oft product that complains about the lack of versioning - they invented DLL-hell after all. Ok, we might try to fix this, but in the meantime you'll to delete the entire Mozilla-directory and install a new copy. It doesn't make sense trying to determine which file needs to be changed, and which not. Replace ALL, or you'll have a lot of trouble : 50% of the people with a problem after an upgrade, never read the installation guide, and installed a new copy on top of the old one. The only sub-directory that might need to be saved, is the plugins-directory. Unless you always want to start from fresh and install all the latest versions for your users. PS : in my company, we install Netscape 7 like this. It's not MSI, though (it's from Computer Associcates). We'll wipe out the entire directory, plugins included (we're not allowed to install new plugins anyway), and install a new copy. No problems so far. In fact, I'm doing it myself once or twice every week or so (latest nightly), for the last 1.5 years. I swear I never had any problem with the installation, except with a corrupt xul.mfl file once in a while (which is in the profile-directory). The build could have been a bad one, but I was always able to downgrade to a previous version, which I always saved in a winzip archive.
v dup.
Status: RESOLVED → VERIFIED
This isn't a dupe of a bug about .so versions on Linux because this is about Windows versioning which isn't identical.
Status: VERIFIED → UNCONFIRMED
Resolution: DUPLICATE → ---
Summary: many dlls and exes in distribution are not versioned, which breaks MSI repackaging attempts → Version all Win32 .dlls and .exes because MSI repackaging, etc requires it
Status: UNCONFIRMED → NEW
Ever confirmed: true
Dupe of 50627 *** This bug has been marked as a duplicate of 50627 ***
Status: NEW → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → DUPLICATE
verified
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.