Thanks for the suggestion, but so far that doesn't appear to be it. The MIME
type is the (I presume) default of "application/octet-stream". Moreover, on
most workstations it works fine. The problem is sporadic; that is, it is
consistent on the machines on which it occurs, but it occurs inconsistently
between machines and network connection types.
We're a small office so I don't have a lot of systems to try this on, but on
3 of 3 XP boxes in the office, it fails with the corrupt CAB error. On 1 of 1
W2K boxes, it works fine. All three boxes are inside our domain. Implication:
on XP, inside our domain, it fails consistently.
When I set up the W2K to dial in through AOL so that it is outside of the
domain, it works fine. When I run it outside of the domain, on 1 out of about
5 or so (so far) it failed; on the rest (4) it worked fine. The one that
failed is XP, but the other computers were a mix of W2K and XP. Implication:
XP outside the domain is 50/50, W2K outside the domain is 100% OK.
So, it seems to be related to XP on the client, since all the failures so
far are XP client workstations. Some have SP2, some don't; some are inside
the domain, some aren't.
The installation is a simple "xcopy install" kind of thing; there is an EXE
(VB.Net) and several dozen graphic files. There are two DLLs;
AxInterop.MediaPlayer.DLL and Interop.MediaPlayer.DLL, because the
application embeds MP 6.4 to play video files served from the server. The app
sends queries to an MS SQL Server DB and receives results via an HTTP
interface (to avoid conflict with blocked ports at our user's locations).
Nothing all that complicated in the install itself, it seems to me.
I could provide the fc.exe (file compare) results, if that would mean
anything to anyone who's reading this. The msi file is 2.8 Mb (file
properties reports identical results). When the IE-downloaded file and a
simple copy of the file are compared via file compare (fc), fc's output isn't
all that vast; 12K of gobbledygook text. A casual visual inspection of the fc
output reveals almost nothing meaningful to me; I can't see anything
different even where it reports differences. But then, it's a text
interpretation of binary data (compressed, binaries at that), so I wouldn't
expect to see much obvious unless the file had been majorly transformed.
Clearly, nothing major changed -- it's something subtle, and baffling so far.
I appreciate any ideas anyone can suggest. I'm astounded that no one else
has had a similar problem! This is our first attempt at a .net application
and the problem appeared almost immediately.
"Jon Skeet [C# MVP]" wrote:
SS <SS@discussions.microsoft.com> wrote: We built an MSI file to deploy a .net app to the workstation. We created an
HTML page that has a link to the MSI file.
On a very sporadic basis, when the MSI is run we get the following message:
The cabinet file '_blahblahblah' required for this installation is corrupt
and cannot be used. This could indicate a newtwork error, an error reading
from the CD-ROM, or a problem with this package.
The MSI file fails consistently on some computers but not others. The file
only fails when it was downloaded through IE. If the file was copied in
Windows Explorer to the local machine, it works fine.
I tried a quick test as follows: I put the MSI file in the root folder on
our website, which is hosted on our local server. I created a dummy HTML page
that has a link to the file. When I open the HTML page in IE and click on
that link, it asks if I want to run or save the file. I saved the file to a
folder on my local drive. Then I used Windows Explorer and copied the same
exact file to the same folder (after renaming the first copy of it, of
course). Then I used file compare to see if the files were different.
Lo and behold to my great surprise, they ARE different according to FC. What
the heck? Why did IE change the MSI file when it was "downloaded"?? What can
be done to work around this wierdness?
Check what mime type IIS is reporting the MSI file as having. If it's
anything to do with text, that could well be a problem.
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
