http://bugs.winehq.org/show_bug.cgi?id=12079
--- Comment #2 from Anastasius Focht focht@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-... (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