trying to package software app to .msi w/o corrupting .ini and .dat files
Hello
I am trying to package a software application that is used for data entry into a library catalog database. I am using Wise version 7 but have also attempted to package the application using AppDeploy's new msi packaging utility. However I have run into the same difficulty using either packaging software.
The problem is that during the process of packing the application into a .msi file the .dat and .ini files that are part of the software become corrupted.
The person who held my job in the past created VBscripts that would find the .ini and .dat files and rename them to something other than .ini and .dat. He then was able to modify the .msi file so that once it had installed the software another set of vbscripts ran so that the .ini and .dat files were renamed again so that they were once again .ini and .dat files.
Looking back at the .msi files he created in the past I can see how he did this and it does work.
So here I am packaging the latest release of the client and I can run his script that renames the .ini files and .dat files into something else before I compile the software into a .msi. All the files are renamed. Then I compile the software into an .msi using Wise 7 and then I can edit the .msi in the MSI Scripts portion of WISE to add in lines to run the vbscripts that should rename all the files back to .dat and .ini files. Then recompile the .msi
The problem is that when I run the .msi instead of renaming ALL the files back to .ini and .dat file extensions - maybe one file will be renamed to its proper name.
If I repeatedly run the vbscripts ... each time another file seems to get renamed back to the .ini or .dat file extension. So I jumped into command line and re-ran the scripts about a hundred times and saw each time that one maybe two files would be properly renamed.
After doing this the software did run properly.
I am wondering a couple of things. I know there is an upgrade to Wise -- version 8 and I am trying to get that. I wonder if there is a way to tell Wise not to mess with the .ini and .dat files. The other thing I wonder is why the vbscript isn't renaming all the files back to their respective .ini or .dat files.
I am trying to deploy this in an .msi format using group policy to about 150 computers.
I can post the scripts I am running:
{scripts removed}
I am trying to package a software application that is used for data entry into a library catalog database. I am using Wise version 7 but have also attempted to package the application using AppDeploy's new msi packaging utility. However I have run into the same difficulty using either packaging software.
The problem is that during the process of packing the application into a .msi file the .dat and .ini files that are part of the software become corrupted.
The person who held my job in the past created VBscripts that would find the .ini and .dat files and rename them to something other than .ini and .dat. He then was able to modify the .msi file so that once it had installed the software another set of vbscripts ran so that the .ini and .dat files were renamed again so that they were once again .ini and .dat files.
Looking back at the .msi files he created in the past I can see how he did this and it does work.
So here I am packaging the latest release of the client and I can run his script that renames the .ini files and .dat files into something else before I compile the software into a .msi. All the files are renamed. Then I compile the software into an .msi using Wise 7 and then I can edit the .msi in the MSI Scripts portion of WISE to add in lines to run the vbscripts that should rename all the files back to .dat and .ini files. Then recompile the .msi
The problem is that when I run the .msi instead of renaming ALL the files back to .ini and .dat file extensions - maybe one file will be renamed to its proper name.
If I repeatedly run the vbscripts ... each time another file seems to get renamed back to the .ini or .dat file extension. So I jumped into command line and re-ran the scripts about a hundred times and saw each time that one maybe two files would be properly renamed.
After doing this the software did run properly.
I am wondering a couple of things. I know there is an upgrade to Wise -- version 8 and I am trying to get that. I wonder if there is a way to tell Wise not to mess with the .ini and .dat files. The other thing I wonder is why the vbscript isn't renaming all the files back to their respective .ini or .dat files.
I am trying to deploy this in an .msi format using group policy to about 150 computers.
I can post the scripts I am running:
{scripts removed}
0 Comments
[ + ] Show comments
Answers (8)
Please log in to answer
Posted by:
Cybermage
13 years ago
maybe a suggestion that wil help.
Not importing ini en dat file by capaturing but included manualy afther the capturing.
so it will be treaded like normale file and not placed in the msi tables.
Not importing ini en dat file by capaturing but included manualy afther the capturing.
so it will be treaded like normale file and not placed in the msi tables.
Posted by:
anonymous_9363
13 years ago
TBH, in all the years I've been doing this job, I've never seen Wise corrupt ANY file. With the INI files, are they definitely in INI format? I've come across a few apps whose files have the INI extension but are not in standard INI format.
As to the scripts...they are truly awful. Their functionality could be combined into a single function in one script. Indeed, I'm pretty sure you could find a script which loops through a folder renaming files as it goes. If not, you could find one which renames and one which recurses through a folder and combine the two.
As to the scripts...they are truly awful. Their functionality could be combined into a single function in one script. Indeed, I'm pretty sure you could find a script which loops through a folder renaming files as it goes. If not, you could find one which renames and one which recurses through a folder and combine the two.
Posted by:
anonymous_9363
13 years ago
Sorry, I should have elaborated. When you capture an app with Wise, if it comes across a file with an INI extension, it will treat it as an INI: it doesn't do any parsing of the file to see if it's in the proper format. So, the suggestion to treat it as a normal file is a good one. When SetupCapture has done its thing, highlight the INI and click 'Treat as File'.
Posted by:
anonymous_9363
13 years ago
I can see no way that Wise would even care about DAT files, since there's no specific handling for such files.
Could the DAT files be encoded with, say, the computername you built the package with? When you install MACHINE_A's DAT file to MACHINE_B, the app whinges and exits? I think you probably need to consult with the vendor on this one.
Could the DAT files be encoded with, say, the computername you built the package with? When you install MACHINE_A's DAT file to MACHINE_B, the app whinges and exits? I think you probably need to consult with the vendor on this one.
Posted by:
bearden3
13 years ago
skay,
If you have a way to get a list of the date/timestamp on the dat files, try installing the package you have created, then look at the date/timestamp on the same dat files to see if any of them changed. You could then at least pinpoint which dat files you need to look at, as those would be the ones that were changed during installation and might have something like machine specific information in them as VBScab said.
Or you could look to see if there are new dat files created at install time that aren't part of your package and you could look at those.
Another thing is sometimes, .dat files are binary and sometimes, they are text. If they are binary and they have changed, you might up the creek a bit but at least you'd have something to talk to the vendor about.
If you have a way to get a list of the date/timestamp on the dat files, try installing the package you have created, then look at the date/timestamp on the same dat files to see if any of them changed. You could then at least pinpoint which dat files you need to look at, as those would be the ones that were changed during installation and might have something like machine specific information in them as VBScab said.
Or you could look to see if there are new dat files created at install time that aren't part of your package and you could look at those.
Another thing is sometimes, .dat files are binary and sometimes, they are text. If they are binary and they have changed, you might up the creek a bit but at least you'd have something to talk to the vendor about.
Posted by:
anonymous_9363
13 years ago
You missed out the line which sets up the FSO object:
Set FSO = CreateObject("Scripting.FileSystemObject") Also, calling some of the code in DoStuff recursively is a mistake, e.g. strComputer = ".". Move it somewhere in the code where it will execute just once.
Posted by:
anonymous_9363
13 years ago
You're on the right lines. As I mentioned, you need to move some of the code so that it executes only once.
Posted by:
anonymous_9363
13 years ago
Think!
Look at the WMI statement, where you have 'ASSOCIATORS OF'. Think of the variable which contains the path name which is passed to DoStuff. It helps with this stuff if you abstract as much as possible, even the WMI query. Indeed, personally, where a SQL (or SQL-style) query is being used, I like to split it out into manageable chunks, so if stuff goes wrong, I don't have to spend hours trying to decipher it. Also, it makes making changes to queries simpler. For example, where someone else might have this:
So, [H U G E hint] think about turning your WMI query string into a variable and using the variable already there which contains the path.
Look at the WMI statement, where you have 'ASSOCIATORS OF'. Think of the variable which contains the path name which is passed to DoStuff. It helps with this stuff if you abstract as much as possible, even the WMI query. Indeed, personally, where a SQL (or SQL-style) query is being used, I like to split it out into manageable chunks, so if stuff goes wrong, I don't have to spend hours trying to decipher it. Also, it makes making changes to queries simpler. For example, where someone else might have this:
strSQL = "SELECT Component_, File, FileName FROM File WHERE FileName='deadduck.dll'"I would have this:strSQL = ""
strSQL = strSQL & "SELECT "
strSQL = strSQL & "Component_"
strSQL = strSQL & ","
strSQL = strSQL & "File"
strSQL = strSQL & ","
strSQL = strSQL & "FileName"
strSQL = strSQL & "FROM "
strSQL = strSQL & "File"
strSQL = strSQL & "WHERE "
strSQL = strSQL & "FileName='deadduck.dll'"Now that looks incredibly long-winded and it is. The point is, if I want to add the 'Version' column to the query, I can see right away where it goes. Also, the poor guy who at some point will have to make changes to the code x years down the line can see the query neatly laid out: he won't even have to think about what it's doing - it's as plain as day.So, [H U G E hint] think about turning your WMI query string into a variable and using the variable already there which contains the path.
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.
