I'm using the Diagnostics.Process approach to shelling out run the
following:

C:\Windows\System32\MSIEXEC.EXE /x {73F1BDB7-11E1-11D5-9DC6-00C04F2FC33B} /q

..FileName = "C:\Windows\System32\MSIEXEC.EXE"
..Arguments = "/x {73F1BDB7-11E1-11D5-9DC6-00C04F2FC33B} /q"
..Start()

I do a WaitForExit and get an error code back from MSIEXEC of 1605 -- this
means product not installed.  So I go into the registry to locate the
produce code and verify that it does indeed exist.  Since I'm baffled as to
why shell ot MSIEXEC would return this error when the product IS installed,
I decide to try Start | Run and enter the exact same:

C:\Windows\System32\MSIEXEC.EXE /x {73F1BDB7-11E1-11D5-9DC6-00C04F2FC33B} /q

and it works!!?  So now, I'm really baffled.

So why is does this NOT work using Diagnostics.Process approach?  Obviously
the product does indeed exists.

Rob.

P.S. - this is basically uninstalling a product (

Rob,

As this is your total code than it is definitly wrong because you are not
adding the ProsesStartInfo to the proces..

See this sample to open regedit.

\\\Registry
Dim p As New Process
Dim pi As ProcessStartInfo = New ProcessStartInfo
pi.FileName = "regedit"
pi.Arguments = "/S C:\yourRegFile.reg"
p.StartInfo = pi
p.Start()
///

I hope this helps,

Cor


Show quoteHide quote

Cor,

I didn't post all my code, just the critical parts.  The start process is
working fine as MSIEXEC is returning 1605 error code.  I'm going to try to
log the MSIEXEC output but according to Microsoft 1605 means "This action is
only valid for products that are currently installed."

What has me really puzzled is the exact same command entered via Start | Run
works fine.  There must be some undocumented "feature" of the Process or
something?  I've talked to other developers that have received the 1605 from
MSIEXEC when it had nothing to do with the actual error.

Thanks, Rob


Show quoteHide quote

Rob,

Did you try it already as a simple winform program. AFAIK can a
windowservice in Net not standard connect to the UI (what the shell in fact
is)

Cor

Show quoteHide quote

Cor,

The service uses Diagnostics.Process to start a standard .NET windows form
application (my UI) -- this works fine if the "interact with desktop" is
checked for my service.

However, what I've been able to finally determine (with NO help from
Microsoft at all) is that MSIEXEC will NOT execute correctly (returns bogus
error 1605) if being called via the Diagnostics.Process and if that process
was originated from under a windows service context regardless of the
"interact with desktop setting".  So basically the problem is that
Diagnostics.Process only supports single context level, if another process
is called from that process it does NOT inherit the windows service
"interact with desktop" context or even be aware that is the context.

As stated in my message if I run the my UI stand alone from desktop shortcut
or double click via explorer it works without a problem.  Only when my UI is
called from my service does it produce these problems.

Microsoft's bug (and yes this is a bug that I doubt they will ever fix)

1.  Diagnostics.Process does NOT inherit origination thread "interact with
desktop" context so if you go more than one level of diagnostics.process you
will not really be able to run anything with an interface.
2.  MSIEXEC returns a bogus error 1605 (product not installed) when it can't
run in an interface context.

This has probably result from sloppy coding  and/or poor QA on Microsoft's
part  OR it came about due to a security problem and rather than provide a
specific fix to the security issue, they implemented a blanket solution that
has left the above items broken.

This has cost me 3 days of work and 15 clients very pissed off.  And I have
probably 1 more day of work left to re-write this project so that it does
NOT run as a service and loads via the StartUp and use a timer in the UI.

What I'm hearing from Microsoft and those supporters of Microsoft is that
"interact with desktop" should NEVER be used because they believe Microsoft
will not support it in Vista.  Rather than ask the OBVIOUS question, why
can't a service interact with the desktop?  why force a restriction? -- 
because it present a security risk??  NO, sorry it doesn't -- the security
risk is allowing applications to install without the consent of the user.
Think about it, it is purile to just disable functionality because Microsoft
can't be bothered to deal with security in a more detailed and efficient
manner.

What is more concerning, is that Microsoft are just doing this with ZERO
documentation to help any developers and even worse the errors generated are
completely misleading so it send developers down the wrong path to find a
solution.  And to have other developers say "Why would you want to do that"
is freakin' lame and stupid!

This is just Bullsh*t from Microsoft, complete and utter Bullsh*t.


Show quoteHide quote

This is what the MSIEXEC logging produced:

=== Verbose logging started: 7/20/2006  14:39:46  Build type: SHIP UNICODE
3.01.4000.2435  Calling process: C:\WINDOWS\system32\MSIEXEC.EXE ===
MSI (c) (A8:80) [14:39:46:625]: Resetting cached policy values
MSI (c) (A8:80) [14:39:46:625]: Machine policy value 'Debug' is 0
MSI (c) (A8:80) [14:39:46:625]: ******* RunEngine:
           ******* Product: {73F1BDB7-11E1-11D5-9DC6-00C04F2FC33B}
           ******* Action:
           ******* CommandLine: **********
MSI (c) (A8:80) [14:39:46:625]: Client-side and UI is none or basic: Running
entire install on the server.
MSI (c) (A8:80) [14:39:46:640]: Grabbed execution mutex.
MSI (c) (A8:80) [14:39:46:671]: Cloaking enabled.
MSI (c) (A8:80) [14:39:46:671]: Attempting to enable all disabled priveleges
before calling Install on Server
MSI (c) (A8:80) [14:39:46:687]: Incrementing counter to disable shutdown.
Counter after increment: 0
MSI (s) (30:90) [14:39:46:734]: Grabbed execution mutex.
MSI (s) (30:64) [14:39:46:734]: Resetting cached policy values
MSI (s) (30:64) [14:39:46:734]: Machine policy value 'Debug' is 0
MSI (s) (30:64) [14:39:46:734]: ******* RunEngine:
           ******* Product: {73F1BDB7-11E1-11D5-9DC6-00C04F2FC33B}
           ******* Action:
           ******* CommandLine: **********
MSI (s) (30:64) [14:39:46:734]: Machine policy value 'DisableUserInstalls'
is 0
MSI (s) (30:64) [14:39:46:750]: MainEngineThread is returning 1605
MSI (c) (A8:80) [14:39:46:765]: Decrementing counter to disable shutdown. If
counter >= 0, shutdown will be denied.  Counter after decrement: -1
MSI (c) (A8:80) [14:39:46:765]: MainEngineThread is returning 1605
=== Verbose logging stopped: 7/20/2006  14:39:46 ===

Not helpful at all.

Rob.

Show quoteHide quote

Ok, the plot thicken's

Addendum:

The root of the problem seems to steam my Windows Service (interacts with
desktop is checked) shell.  Here is the sequence:

DUSM.EXE (my Windows Service running un LocalSystem with "interact with
desktop" enabled)
DUSM performs a Process.Start which loads DUSM_UI.EXE
DUSM_UI.EXE performs a Process.Start which runs the MSIEXEC (see below)
Results: 1605 error (this appears to be a bogus error reported by MSIEXEC
but product does NOT uninstall)

Since DUSM_UI.EXE is a stand alone program I can run it directly (double
click in Explorer)
run DUSM_UI.EXE (from explorer) which performs a Process.Start which runs
MSIEXEC
Results: 0 (no errors and MSIEXEC performs the uninstall)

So this looks like some type of thread restriction being imposed on MSIEXEC
when its source thread path originates from a Windows Service.

The $64,000 question -- how can I work around this problem?  My DUSM service
MUST be the originator of these tasks, what are my options?  Where do I even
start to look for answers?

Rob.


Show quoteHide quote

How to Return Value from Module?
exceptions/inner exceptions
Getting the full path of a folder.
Expose Count from System.Collections.CollectionBase in an inherited class
Referencing a MDI Parent form from a Child
Force Windows to "See" new files burned to a CD/DVD?
Problem with two version of program in one code and class referenc
Obtain info from other computer
SendMessage()
Assembly info from separate project?