No subject

Tue Sep 2 11:01:37 CDT 2008

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:
- which is correct as _temporary_ location before final phase.
Windows installer always employs 2-step transactional process for CLR
At the end this assembly should get published/installed to:

--- 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
resolves to
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
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
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
001f:trace:msi:cabinet_copy_file extracting
001f:trace:msi:cabinet_notify (3)
001f:trace:msi:install_assembly installing assembly:
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

Either regression or there are still missing bits in


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.


Configure bugmail:
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.

More information about the wine-bugs mailing list