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

Comments

Please log in to comment

Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.

Answers

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.
Answered 03/19/2008 by: AngelD
Red Belt

Please log in to comment
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
Answered 03/19/2008 by: WayneB
Blue Belt

Please log in to comment
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_
Answered 03/20/2008 by: AngelD
Red Belt

Please log in to comment
0
By the by, I *like* the notation of table_name[dot]column name. I'm going to use that from now on. Cheers!
Answered 03/20/2008 by: VBScab
Red Belt

Please log in to comment
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!
Answered 03/20/2008 by: AngelD
Red Belt

Please log in to comment
Answer this question or Comment on this question for clarity