No subject

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


-- 
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.