PDA

View Full Version : Had rabies with IS tech support and with MSDE 2000 object



moroandrea
12-07-2004, 04:59 AM
It sounds a joke. I got a log file of a new project in which I've included the MSDE object ... I want to control it ... I've put a condition (that it's ignored) I moved the ISSQLServerCosting CA from UI to execute sequence (in log file those CA seems to be the startup CA for MSDE) ...
nothing ...

MSDE Continue to start when it wants, ignoring the condition ...

IS, why don't you make a well written manual, post or something like that to help us (or only me if I'm alone) to work well with MSDE object?

Is one month that I'm running after MSDE install, and SQL script install ... and one month that I don't got results. Maybe that setup design isn't my work, but actually it's the only one I need to do ... so improve your tech reply time ...

I opened support request in Mysupport, but every reply comes after more than two days ... I need to give a package to my customer not excuses.

Stefan Krueger
12-07-2004, 01:17 PM
You can't install MSDE in Execute sequence because it is a MSI setup.
What condition are you using (that's being ignored)? On which action? In which sequence position? (Before or after dialogs etc.)
Did you generate a log file to see what happens in which order and what's the value of your condition?

moroandrea
12-07-2004, 01:29 PM
<quote>You can't install MSDE in Execute sequence because it is a MSI setup.</quote>
I'm using their objects ... I tried for both MSDE 2000 and MSDE for NT platform ...

While the first one let me specify the targetdir (but doesn't accept any other path than [PROGRAMFILESFOLDER]somethingyouwant the second one doesn't let you specify anything that isn't hard coded.

I tried to modify parameter inside the script, in both way, using internal property or using MSI property with the appropriate function.

But not a problem ... finally I got a nice working, also if it need to improved.
I used the MSDE 2000 ... doesn't change the path, start the service by hand because it's not supported ... and add protocols management by hand because DISABLENETWORKPROTOCOL doesn't work (I opened a support for this and they are working on).

<quote>What condition are you using (that's being ignored)? </quote>
A simple condition like setupMSDE=true, where setupMSDE is a global variable defined in top of my script.
I don't be sure about it can be used so ... but it sounds like a condition ...
I didn't not investigate too much, because of first point.

<quote>On which action? In which sequence position? (Before or after dialogs etc.)</quote>
During dialogs. If user select a feature on the last dialog I setup the variable to TRUE, otherwise FALSE.

<quote>Did you generate a log file to see what happens in which order and what's the value of your condition?</quote>
Unfortunately on the log file, it doesn't never start the MSDE install ... so any referer to feature start, command line etc won't be logged.
And this is the worste thing ... I don't know where else check.

I've a friend that is helping also me with this setup, and also him is surprised about the strange behaviour is happening on.

Stefan Krueger
12-08-2004, 03:45 AM
The "MSDE for NT platform " object is a wrapper for Microsoft MSDE setup wich is MSI based. Direct use of the MSDE 2000 merge modules is no longer recommended by Microsoft (actually they say you should not use them). The suggested method is installing MSDE outside of your own setup. You can do this using InstallShield's setup prerequisites, but in this case you can't specify conditions. Or you can use your own setup.exe launcher wich would first install your setup, and then (coditionally) launch the MSDE setup. Of course this means you cannot access MSDE in your setup because it's not yet installed. Another option would be a CD browser where users can first (optionally) install MSDE and then your setup.

moroandrea
12-08-2004, 05:02 AM
Well I can plan to use the MSDE for NT instead the MSDE 2000, but there is a trouble. While the second one start only if a feature is selected, the first one, despite is associated to a feature was setup just after setup has launched.

Why?

Stefan Krueger
12-08-2004, 05:25 AM
Because it's just a custom action that calls the MSDE setup, not a real merge module that adds components to the feature. You could modify the merge module to put a condition on the custom action. You may also need to change the sequence number for the custom action to make sure it's executed after you displayed the dialog where users can select whether they want to install MSDE.

moroandrea
12-08-2004, 05:36 AM
>Because it's just a custom action that calls the MSDE setup

Well, I've tried to identify it throught the log file, but I see this.

MSI (c) (8C:E8) [11:12:57:958]: Doing action: CheckInstance.DEAEC3E7_8F5C_4115_ABD3_E5742E47D469
Inizio operazione 11.12.57: CheckInstance.DEAEC3E7_8F5C_4115_ABD3_E5742E47D469.
MSI (c) (8C:FC) [11:12:57:968]: Invoking remote custom action. DLL: C:\DOCUME~1\ADMINI~1\IMPOST~1\Temp\MSI8.tmp, Entrypoint: CheckInstance
Fine operazione 11.12.58: CheckInstance.DEAEC3E7_8F5C_4115_ABD3_E5742E47D469. Valore restituito 1.
MSI (c) (8C:E8) [11:12:58:358]: Doing action: InstallMSDE.DEAEC3E7_8F5C_4115_ABD3_E5742E47D469
Inizio operazione 11.12.58: InstallMSDE.DEAEC3E7_8F5C_4115_ABD3_E5742E47D469.

If I go to the custom action, and show all custom action there aren't Ca with that name.

> You could modify the merge module to put a condition on the custom action.

I'ven't experience with that. Could you be so kind to explain me that (a sort of step by step?) ...

>You may also need to change the sequence number for the custom action to make sure it's executed after you displayed the dialog where users can select whether they want to install MSDE.

As said above I don't see the CA entry for MSDE ... so I don't know what to change. The only CA that I've identified in log and there is also in the Custom Action list is the ISSQLServerFilteredList.
But this should populate the lists of sql server available, not setup MSDE.

I also don't think that simpy adding CheckInstance.DEAEC3E7_8F5C_4115_ABD3_E5742E47D469 custom action or InstallMSDE.DEAEC3E7_8F5C_4115_ABD3_E5742E47D469 custom action into the list in the right order don't give me the control I want.

Stefan Krueger
12-08-2004, 06:13 AM
Did you open the merge module? You won't see these actions in your parent setup. You have to open the .msm file.

moroandrea
12-08-2004, 06:35 AM
I opened it, and set CA in-script execution as deferred ... according to the help it should wait for main setup.

I don't find any explanation about deferred in system context. What does it mean?

moroandrea
12-08-2004, 06:48 AM
I got error 2762 ... in both case deferred and deferred in system context ... what do I need to change?

Stefan Krueger
12-08-2004, 07:04 AM
That won't work. You need to read more about custom action types, scheduling, execution options etc. in MSI help. My article at http://www.installsite.org/pages/en/isnews/200108/index.htm also explains this.

moroandrea
12-08-2004, 07:34 AM
Well I understand why the 2762 error, but I came back to original request ... I don't know who is the action that call the msm execution.

I don't think that is just started because is there. There is an entry point that turn it on ... after that control flow pass to msm ... but which is the entry point?

Execute action? May be according to your diagram. But If I move it to InstallExecute table, what's happen if I need to have some CA (Execute Action should refer to CA run command) that need to be execute during the UI sequence?

Actually I don't have it, but I won't say in the next future what could I add to setup.

moroandrea
12-08-2004, 08:25 AM
Let me aks one thing ... Do I need to declare the custom action by myself?
And just then setup, scanning tables find it and execute only in the position I put and in different case continue to execute when it wants?

Stefan Krueger
12-08-2004, 09:02 AM
The merge module is merged into your msi at build time. During the build, any components are added, and any customa ctions are inserted into the sequences. Where in the sequence they are inserted is specified in the ModuleInstallUISequence and ModuleInstallExecute sequence tables in the MSI.
I'd suggest you open the built .msi file to see the flow of your built setup, including the merge module actions.

moroandrea
12-08-2004, 09:20 AM
Let me say you that I just discovered how to add a custom action of merge module ... I don't know it before.

I added them into the Execute table ... levead the deferred option in the MSDE msm and buitl. Won't work.

I then opened the .msi as you suggested me, and surprise. Checkinstance, installamsde and all other custom actions of merge module are there in the UI table and also (two I manually addedd) in the execute.

This mean that do I need to editate the .msi manually every time?

Possible that doesn't exit a way to say it to don't insert them into the UI table?

By the way, I've also read that better is provided a full set of MSDE packages and througt a CA call setup.exe with .ini files with parameter or pass them in command line ... do you have some links to suggest about create a custom action that call an external setup?
I found something on your site, but isn't specific for setup. It was for a dll ...

Stefan Krueger
12-08-2004, 09:31 AM
I added them into the Execute table ... levead the deferred option in the MSDE msm and buitl.
You don't have to do this. Merging in the module automatically adds the custom actions in the right place.

This mean that do I need to editate the .msi manually every time?
No, you edit the .msm file once. The information is preserved in the MSM and will automatically be added to your MSI each time you build it.

Possible that doesn't exit a way to say it to don't insert them into the UI table?
Theoretically, yes. But (talking about InstallShield's MSDE for NT object) these custom actions will only work in UI sequence. They will fail in execute sequence, as explained before.

By the way, I've also read that better is provided a full set of MSDE packages and througt a CA call setup.exe with .ini files with parameter or pass them in command line
Basically this is what the custom action in InstallShield's MSDE for NT object does, as I tried to explain before.

... do you have some links to suggest about create a custom action that call an external setup?
A custom action of type "run an executable" that launches the setup.exe can be easily added in the Custom Actions view. If you need additional files, things get more complicated. Using the Support Files view might be a better way in this case.

Please note that installing MSDE is "wicked" and modifying InstallShield's object is not a trivial task. You may need to learn more about the inner working of Windows Installer before you can complete this successfully.

moroandrea
12-08-2004, 09:46 AM
You don't have to do this. Merging in the module automatically adds the custom actions in the right place.


But in the .ism file I cannot saw it. This mean that I must add it for myself, and this let me control when CA will be run, instead run when they wants, and optionally add a condition that will be appended to original condition in the ISMSDE2000 object. Is it right?


No, you edit the .msm file once. The information is preserved in the MSM and will automatically be added to your MSI each time you build it.


According to previous paragraph, I don't need anymore to modify the original ISMSDE2000.msm module. Right again?


Theoretically, yes. But (talking about InstallShield's MSDE for NT object) these custom actions will only work in UI sequence. They will fail in execute sequence, as explained before.


Sincerely I didn't read about it. Maybe that some thing that is so obvious for you that are MVP and works (I think) with setup every day, won't be so for me.

Stefan Krueger
12-08-2004, 09:59 AM
But in the .ism file I cannot saw it.
The merge happens at BUILD time. Therefore the custom actions from the merge module are NOT added to your PROJECT file (.ism). Instead they are added to your MSI file when you perform the media build. Therefore you will only see them in the .msi file bit not in the .ism file.


According to previous paragraph, I don't need anymore to modify the original ISMSDE2000.msm module. Right again?
You can either modify the .msi file after each build, or modify the msm file once. Whichever you prefer. In my opinion the latter makes more sense.


Sincerely I didn't read about it. Maybe that some thing that is so obvious for you that are MVP and works (I think) with setup every day, won't be so for me.
Quote from my first post in this thread:
You can't install MSDE in Execute sequence because it is a MSI setup.
Quote from my second post in this thread:
The "MSDE for NT platform " object is a wrapper for Microsoft MSDE setup wich is MSI based.
Only one installation at a time can run its execute sequence. therefore you cannot run another MSI based setup from a custom action in your execute sequence.