Command line parameters not being passed to install...........

OK, you have an EXE.
This could be an MSI compiled to an EXE or a Wisescript compiled to an EXE.
So let's start by asking what Wise product you are working with.
Then let us ask how you are "processing" the HOST 'variable'

Thanks for the reply.  I am using Wise Installation Studio 7.3.0.250.  I am a VB.NET programmer so I understand the logic but I don't get the wsi vs. the wse vs. the msi vs. exe.  In the code it checks to see if host has anything in it and then does certain things based on that.  In the rewrite version I see the server name passed from the command line host=servername.  In my upgrade I see a ~.  It's like its not even taking my command line or its just ignoring it.  I keep thinking something  or some version number didn't get changed in the new one or something like that.  Is there anyway I can post my wsi for you and then maybe it would make more sense as to what its doing or not doing?

Thanks

Phil

In your original posting, you stated you were passing HOST=servername. In your most recent posting you state host=servername.
If you are not already aware of this, properties passed on the command line must be public properties - in other words HOST must always be in capitals. If it is not entirely in capitals, the parameter will not be passed into the MSI and you will get exactly the result you are reporting - as if the property setting is being ignored.  There should also be NO spaces either side of the equals sign.

What have you changed in the rewrite ?  This might give us a clue as to what might be the issue if not the above.

WSI = windows installer editor project file that is compiled into an MSI

WSE = wisescript editor project file that is compiled into an EXE.

An MSI can only be installed by either double clicking it (which launches msiexec.exe by file association) or by specifying a command line install such as

msiexec.exe /i program.msi HOST=servername /L*v c:\windows\temp\installationLog.txt

Therefore there is also an option to further compile the MSI into an EXE which does not require you to call msiexec.
This uses a stub installer pre-written in wisescript, which compresses the MSI into an EXE format.

For testing, leave out the step that compiles the MSI to an EXE and stick with the MSI. This makes it easier to generate installation logs and perform basic diagnostic testing.

The command line I have given above, will generate a verbose logfile of the install - just substitute the full path of your MSI for "program.msi"

You can post attachments to this thread, by editing your FIRST posting and attaching your files in ZIPPED format. Zipping preserves any formatting of text files, etc, and also makes uploads and downloads smaller.

Thanks for the quick reply.  My host versus HOST was just a typo.  All I changed was the version numbers in the new one and recompiled.  The other thing I've noticed is when I run his it starts out by "preparing the setup files for our app name".  He calls a couple of other little exe's to start before anything else happens.  It appears those aren't happening on mine.  Now here is the weird part.  When I ran your line comman above then it works.  I have a display message that pops up showing me what HOST equals and it shows me what I entered in the command line. When it was done I checked my registry and all of the stuff I needed entered based on the command line was there.  So does that give you any clue.  It won't take it witht he EXE which is what we distribute to clients but it will work with the MSI.  I will attach a file with this that has all the code.  Thank you again so much for your help.  I really wich the economy would flip around so we can hire someone back that knows what they are doing with this stuff instead of counting on some programmer with no training.  Thanks again.

I just uploaded two files.  The one that says Everything is 90 some meg and has everything you need to build.  The other one just has the wsi and msi and wse files.  Thank you again.

I had a quick look at the MSI and also at the WSE file.
In the MSI, the default value of HOST is set to ~
So it is clear that your attempt to enter HOST=servername on the EXE command line is being ignored.
There is a reason for this - the EXE stub expects any command line passed to the exe, to specify the full path and filename of the settings.ini file which will then hold various parameters to be passed to the MSI - in this case a line starting MsiCommandLinexxx=  where your HOSTS=servername setting would be found.

If that is NOT the way that your previous install worked, then it is perfectly conceivable that your install outsource wrote their own wrapper script for compiling the MSI to an EXE, which handled any command line options differently. You would have to look carefully at the sources for the original version to see if this is the case.

If you are intending to use your version as an Upgrade to a previous install, there are additional considerations than if the intention is to manually uninstall previous versions then reinstall the updated version. If upgrade IS your intention, and you have not read as far as Upgradesync in the documentation, then I would strongly recommend that you ask the external packaging resource to assist you with this.  Packaging windows installer apps is a non-trivial task which requires a substantial investment in time and effort to understand what is going on, and for which training courses can only go part way to achieving a decent level of competence. There is only so much that we can do to assist you in the forums, as we all have our day jobs to do as well.

However, as a starting point, test your MSI with the command line as I mentioned above - at least that will verify if it is basically working.

I think I confused you by posting that last post saying I uploaded the files.  Before that post I said in another post that the command line worked.  That really confused me.  I know he talked about a wrapper and what not.  So yes your command line works with the msi but not with my exe.  Does that mean something to you?  If you want to scroll back before files post I wrote a little more on this.  I do appreciate all of your help.

Thanks

I saw your posting about uploading the files, and didn't spot the previous one.

So what you are saying confirms my suspicion that your packaging outsource company have used a different wisescript "wrapper" to compile the MSI to EXE. It looks like you are using the standard stub wrapper.

Do you have the original source of the app that worked, including any wse files?

(I'm in the UK so am off home now but may log on later this evening, otherwise tomorrow)

Yes I have all that code and will attach it right now.  I've tried to look at it to see if anything else is different and I can't find anything that stands out.  Like I said when his starts it starts with a message about preparing files for setup and I dont' get that but did get it with your comman line.  I keep for some reason looking at this prereq area and think its something with that but I really am guessing.  I will upload the old version now.  Thank you again for all of your help.

SO I think I see the problem now but I am not for sure how to fix it.  It's all about the custom wrapper like you said.  Some how I have overwritten the custom wrapper and it's made a generic one or something becuase ithe wse from his to mine are totally different.  I think the issue I was at some point I noticed when my I hovered over my my exe that it was saying like version 11 something when it should be 7.  I saw on this forum that it meant I had no version number in my wse.  I went in and added it and then rebuilt and I wonder if that did it.  I know I am on the right trail now.  If you have any ideas when you get time that would be great.  Thanks again and there is a post above this that you probably haven't read also.

Okay so after doing more research I decided to edit this post.  So again not doing this for a living , this is what I see happening and maybe you can tell me yes or no or explain.  The custom wrapper is the wse file.  If I compile the WSI file then it makes a new wse and wipes out his custom code.  So what I am guessing i need to do is copy over the old wse and change the version number and keep a copy it.  Then after I am all done compiling the WSI I can then place in my good wse and compile and build the exe from that?????  Maybe also there is a way to tell the WSI compike not to overwrite my wse and then problem solved or do I just always need to build from my custom wrapper wsi now?   Am I making any sense because it's sort of making sense in my VB.NET brain.  HA.

Okay after a little more testing and my last of the day I have this....When I compile my WSI it seems to redo my WSE.  When I do the same with the 3rd party rewrite 7.0.0 version it doesn not.  So I am now confused on how this wrapper works.  All the code that gets the command line stuff is in his wrapper that keeps getting overwritten each time I do the compile of the WSI.  So I thought maybe building the WSE was the answer but I get errors in mine and his and so maybe that is not it or I am doing something wrong in that process.  Okay now my brain is fried.

Okay I think I figured it out...Sooooooooo I noticed in my WSE that the package code didn't match the new package code in my upgrade.  So this is where i have a question for you...If the package codes between the wsi and the wse wrapper are different, does the wsi compile then automatically remake my wse?  I then changed the package code in my wse to match the one in my wsi and did not compike the wse.  I then went in to my wsi and this time when I built it didn't wipe out my wse with a new one and then my install exe worked properly.  Am I making any sense?  I really do appreciate all the  help you gave and you prettty much pointed in the direction I ended up but I would love any insight on what I just said and whether its right or wrong or whatever...Okay I am really done for the day now and I will talk to you after you respond.

Thanks again.

To prepare your own MSI for an existing prerequisite wse script, put a copy of the wse script in a safe place and open your wsi. On the prerequisites page, add a dummy prerequisite and Edit script. This will open up a fresh wse. Save and close the wse and the wsi. Now replace the wse created by Wise with your own wse script. It has to have the same name. Next time when you compile the MSI, it will not recreate the wse script. As far as I know, the Package Code should not matter. Wise stores the information about the edited wse script in some of the Wise MSI tables in the wsi. This causes the wsi to not recreate the wse.

As a side note. There are some problems with the prerequisites wse when you choose to edit it. There is at least one bug (you can find information about it in the Knowledgebase) and the ability to pass MSI command line options to the MSI is broken. In my scripts I have fixed this by adding a section that interprets all possible MSI command line options and passes it to the MSI.

But since you already had a working wse that you can use, there should be no problems.

Another note. If you have an existing wse script that you want to use, you can always create your MSI first, then put the wse script in the same folder, open up the wse script in the Wise script editor and click compile. This will create the new exe file. Note that the MSI is not compiled this way.

Thanks Ed for all the help.  I just now got a chance to get on here and reply.  I think I am good to go. 

Also I'd like to thank Johan for the idea of the prereq and making a dummy prereq.

Thanks for all of your help.