http://bugs.winehq.org/show_bug.cgi?id=7098
--- Comment #14 from Anastasius Focht focht@gmx.net 2008-11-01 16:22:52 --- Hello,
revisiting. Yes, that app still unearths deficencies in .NET Framework 1.1 installation. The app crashes for me at startup. Wine: GIT (1.1.7+) App: 6b9bc1db7994f2664c1f1935df95f0b502277cb4 rufzxp_fw1_1_setup_1_1_1.exe
If it really worked for you earlier then this might be a regression in msi.
From a quick glance it seems that Wine's msi doesn't publish/install some
assemblies into GAC.
One prime example is: "Microsoft.VisualBasic.dll" assembly. The app expects this assembly in GAC (otherwise it won't run).
It gets installed to: "C:\windows\Microsoft.NET\Framework\v1.1.4322\GAC\Microsoft.VisualBasic.dll" - which is correct as _temporary_ location before final phase. Windows installer always employs 2-step transactional process for CLR assemblies. At the end this assembly should get published/installed to: "C:\WINDOWS\assembly\GAC\Microsoft.VisualBasic\7.0.5000.0__b03f5f7f11d50a3a\Microsoft.VisualBasic.dll"
--- snip msi install log --- .. 001f:trace:msi:msi_check_file_install_states file L"Microsoft_VisualBasic_dll_3_____X86.3643236F_FC70_11D3_A536_0090278A1BB8" is named L"Microsoft.VisualBasic.dll" 001f:trace:msi:msi_check_file_install_states file L"Microsoft_VisualBasic_dll_3_____X86.3643236F_FC70_11D3_A536_0090278A1BB8" resolves to L"C:\windows\Microsoft.NET\Framework\v1.1.4322\GAC\Microsoft.VisualBasic.dll" .. 001f:trace:msi:MSI_ProcessMessage ((nil) 0 200 L"File: Microsoft.VisualBasic.dll, Directory: C:\windows\Microsoft.NET\Framework\v1.1.4322\GAC\, Size: 299008") .. 001f:trace:msi:cabinet_copy_file extracting L"C:\windows\Microsoft.NET\Framework\v1.1.4322\GAC\Microsoft.VisualBasic.dll" .. 001f:trace:msi:execute_script Executing Action (L"MsiPublishAssemblies") 001f:trace:msi:ACTION_PerformAction Performing action (L"MsiPublishAssemblies") 001f:trace:msi:MSI_DatabaseOpenViewW L"SELECT * FROM `ActionText` WHERE `Action` = 'MsiPublishAssemblies'" 0x33f010 .. 001f:trace:msi:MSI_DatabaseOpenViewW L"SELECT * FROM `MsiAssemblyName` WHERE `Component_`='VB7_Runtime_GAC_____X86.3643236F_FC70_11D3_A536_0090278A1BB8'" 0x33ef70 .. 001f:trace:msi:MSI_DatabaseOpenViewW L"SELECT * FROM `Media` WHERE `LastSequence` >= 5153 AND `DiskId` >= 0 ORDER BY `DiskId`" 0x33ed30 .. 001f:trace:msi:MSI_GetPropertyW returning L"C:\windows\temp\IXP000.TMP\" for property L"SourceDir" 001f:trace:msi:msi_cabextract Extracting L"C:\windows\temp\IXP000.TMP\netfx1.cab" .. 001f:trace:msi:cabinet_copy_file extracting L"C:\windows\temp\System.Configuration.Install.dll" 001f:trace:msi:cabinet_notify (3) 001f:trace:msi:install_assembly installing assembly: L"C:\windows\temp\System.Configuration.Install.dll" 001f:fixme:msi:install_assembly Manifest unhandled 001f:fixme:msi:install_assembly Assembly should be privately installed .. --- snip msi install log ---
install_assembly() is never called for Microsoft.VisualBasic.dll (VB7_Runtime_GAC_____X86.3643236F_FC70_11D3_A536_0090278A1BB8).
Either regression or there are still missing bits in msi/ACTION_MsiPublishAssemblies.
---
So what should we do with this bug? The bug title doesn't reflect the current problem. Either change the title to something more matching or close this one and open a new one copying the information there.
---
As side note: While investigating this, I encountered that race condition other people occasionally reported but no one including me took it for real... Google for: StopDarwinService() - Call to ControlService() failed! winehq
Only happens with winetricks dotnet11 (or some other installer which tries to interact with msi server service) when WINEPREFIX is being newly created. Looks like there is a SCM race between msi service shutdown - initiated when wineboot exits - and the app executed immediately thereafter which tries to query/control the service.
I added a note to appdb entry, though this might also apply to other stuff.
As quickfix, you might want to put a small sleep (3-5 secs) before spawning the installer in winetricks to make sure msi service shutdown is finished after wineboot exited.
Regards