[Bug 12079] VS.NET 7.x/. NET SDK installers fail if re-executed due to ACTION_StopServices being a stub

[wine-bugs at winehq.org]

http://bugs.winehq.org/show_bug.cgi?id=12079





--- Comment #2 from Anastasius Focht <focht at gmx.net>  2008-03-19 15:54:55 ---
Hello,

--- quote ---
Does this happen with the .NET installer (dotnetfx.exe)?  If so, can you please
provide steps to reproduce the problem.
--- quote ---

The .NET 1.1 redistributable package alone doesn't install the local/remote
DevStudio Debugging Service.
Actually it's a combination of several bugs which lead to this problem.

The installer failure itself can only be simulated with full VS.NET 7.x
installer.

I will outline some steps to show at least the "locking" problem - without
VS.NET 7.x
The .NET 1.1 SDK installer can be used for this purpose.

Prerequisites needed:

Download the .NET 1.1 SDK from:
http://www.microsoft.com/downloads/details.aspx?familyid=9B3A2CA6-3647-4070-9F41-A333C6B9181D&displaylang=en
 (106.2 MB)

You need to apply my patch from bug 11420 ->
http://bugs.winehq.org/attachment.cgi?id=10552 to work around another SCM bug.
Otherwise the MDM service won't get started correctly and hangs due to named
pipe/objects mismatch.

---

1. clean your ~/.wine
2. install .NET 1.1 redistributable (if you use 'sh winetricks dotnet11' make
sure winetricks script is up-to-date)
3. install .NET 1.1 SDK with default install settings, takes a bit due to table
JOINs ;-)

Wait until the installer hangs while displaying "Creating shortcuts" step...
Thats another bug (COM/RPC/race) which needs deeper investigation.

In process list you will now find:

"C:\\Program Files\\Microsoft.NET\\SDK\\v1.1\\GuiDebug\\DbgCLR.exe /setup" 

-> Microsoft CLR Debugger self registering for first time

"C:\\Program Files\\Common Files\\Microsoft Shared\\VS7Debug\\mdm.exe\"

-> "Machine Debug Manager" automagically started as COM service.

Both have "C:\Program Files\Common Files\Microsoft Shared\VS7Debug\msdbg2.dll"
a COM proxy/stub dll mapped into their address space.
This proxy/stub dll is only mapped on demand (client like DbgClr connects).

Try to overwrite the proxy/stub file with a copy - won't work.
Executing the .NET Framework installer a second time doesn't exhibit this
problem, because some installer steps are skipped now (need to re-clean your
~/.wine and reinstall or simulate without reinstall by manually executing
'DbgCLR.exe /setup' step).

Within the real VS.NET 7.x installer, the component installations following
update this stuff again (.NET SDK is only small part of install).
Due to the failing/hanging CLR GUI registration and MDM COM server processes -
which lock the proxy/stub dll - the overall installation fails.

Before the later update on this VS7Debug components is done, ACTION_StopService
is executed (table contains MDM stop) which would ideally cure the problem
away.
Granted, it doesn't really solve the other bugs (which require some time to
track down) but let the installer go further and finish.

You can simulate this by manually stopping the MDM service (wine net stop mdm).
Both processes terminate then, releasing the proxy/stub.

Sorry that I couldn't provide you with a shorter explanation/solution.
There are lots of gaps/bugs in various areas which need to be addressed.

If you start implementing the next set of msi actions one day, consider stop
services for it.

Regards


-- 
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.