/build/static/layout/Breadcrumb_cap_w.png

Wise not accepting uncompressed files

G'Day Everyone,

Really bizarre.
We use uncompressed files for our packages and in the last week we have been unable to add files to our packages referencing the uncompressed file location. We usually change the file attribute to 9216 for instance and leave the sequence number less than the maximum as stated in the media table.
However until recently the added files are failing to install unless they are compiled within a cab file. Otherwise the file fails to install and prompts for the source path in the root of our Project directory (in our dev lab) from where the msi is launched.

Any ideas on how to revert this?

TIA
Wayne

0 Comments   [ + ] Show comments

Answers (5)

Posted by: AngelD 16 years ago
Red Belt
0
leave the sequence number less than the maximum as stated in the media table
This sounds wrong but it would depend on how the Media.LastSequence and File.Sequence are "synced".

Try setting the external File.Sequence after the last Media.LastSequence number instead, that is how I usually do it.
Posted by: WayneB 16 years ago
Blue Belt
0
Thnaks Kim for the reply,

I have been following this method from the sdk File Table:
"For files that aren't compressed, the sequence numbers need not be unique. For instance, if all your files are uncompressed, and all reside on one disk, you could give all the files the same sequence number."

My workmate has been following the other method of increasing the Media.LastSequence number to greater than the last File.Sequence (which if I understand you correctly, is what you do) and we still get the same result.
The install fails to find the source file in the root of the project directory (where the launched msi resides). Checking that file paths are all relative and WiseSourcePath points to the correct folder path. However when we remove and re-add the file so that it creates a default cab file, the install finishes without problems.

Really our methodology hasn't changed in the last week (for either of us here) and we have had no issues with this before. I appreciate that it might not be an issue for most; and maybe we should just change our methodes, but I am curious to find out why it is now occuring.

If anyone has any ideas please reply.

TIA
Wayne
Posted by: AngelD 16 years ago
Red Belt
0
True, the File.Sequence is only vital for compressed files.

My workmate has been following the other method of increasing the Media.LastSequence number to greater than the last File.Sequence (which if I understand you correctly, is what you do) and we still get the same result.
I mean if Media.LastSequence is 10 the File.Sequence should be 11, there must always exist a Media table entry for all File.Sequence(s).

I would verify the following:
File.Attributes (msidbFileAttributesNoncompressed attribute bit is set)
Directory.DefaultDir ([targetname]:[sourcename] is valid and correct) for Component.Directory_ associated with File.Component_
Posted by: anonymous_9363 16 years ago
Red Belt
0
By the by, I *like* the notation of table_name[dot]column name. I'm going to use that from now on. Cheers!
Posted by: AngelD 16 years ago
Red Belt
0
Please do Ian

I think this was my first time using this notation and I think it's clearer while referring to a specific column and/or reference between two different tables/columns.

Cheers!
Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.
 
This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ