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)
Tracking
(Not tracked)
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
Comment 2•23 years ago
|
||
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.
Comment 4•23 years ago
|
||
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
Updated•23 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 5•23 years ago
|
||
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
Updated•21 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•