http://bugs.winehq.org/show_bug.cgi?id=16891
Summary: .NET 3.0: Windows Workflow Foundation installer claims .NET 2.0 Framework needed, MsiNetAssemblySupport/msi fusion version retrieval bug Product: Wine Version: 1.1.12 Platform: Other URL: http://www.microsoft.com/downloads/details.aspx?FamilyID =10cc340b-f857-4a14-83f5-25634c3bf043 OS/Version: other Status: UNCONFIRMED Severity: normal Priority: P2 Component: msi AssignedTo: wine-bugs@winehq.org ReportedBy: focht@gmx.net
Hello,
after getting past bug 16888 another subinstaller "Windows Workflow Foundation" fails, claiming ".NET 2.0 Framework is required". This is of course already installed as part of prerequisite.
Prerequisites:
--- 1. clean WINEPREFIX 2. sh mywinetricks -q wmicore 3. sh winetricks -q dotnet20 4. download .NET 3.0 Framework installer from: http://download.microsoft.com /download/4/d/a/4da3a5fa-ee6a-42b8-8bfa-ea5c4a458a7d/dotnetfx3setup.exe (sha1sum: a566bcd2ffffc3842a95adc57f7df3f8cd11577f) 5. export _SFX_CAB_SHUTDOWN_REQUEST=1 (workaround, see bug 9158) 6. wine ./dotnetfx3setup.exe
It might take a while until all required packages are downloaded using BITS.
Note: If you need to redo steps, backup the directory "dotnetfx304506.30" from "c:\windows\temp" to a different location, remove ~/.wine, copy "dotnetfx304506.30" again to "c:\windows\temp" to prevent BITS from downloading over and over again.
---
The corresponding logfile "dd_WF_3.0_x86retMSI48DE.txt" reveals nothing, it's empty.
Using ORCA on "WF_3.0_x86.msi" shows that MsiNetAssemblySupport >="2.0.50727" condition needs to be satisfied. The "MsiNetAssemblySupport" property should be set in set_msi_assembly_prop() but it doesn't seem so.
Trace log shows:
--- snip --- 0016:Call version.GetFileVersionInfoSizeW(00149050 L"C:\windows\Microsoft.NET\Framework\v3.0\fusion.dll",0032f2d0) ret=6024ad80 0016:Call KERNEL32.GetModuleHandleExW(00000000,00149050,0032ef90) ret=609ecc77 0016:Ret KERNEL32.GetModuleHandleExW() retval=00000000 ret=609ecc77 0016:Call KERNEL32.LoadLibraryExW(00149050 L"C:\windows\Microsoft.NET\Framework\v3.0\fusion.dll",00000000,00000002) ret=609ecc99 0016:Call PE DLL (proc=0x60c431f0,module=0x60c40000 L"psapi.dll",reason=PROCESS_ATTACH,res=(nil)) ... 0016:Ret PE DLL (proc=0x60bd98c4,module=0x60bd0000 L"fusion.dll",reason=PROCESS_ATTACH,res=(nil)) retval=1 0016:Ret KERNEL32.LoadLibraryExW() retval=60bd0000 ret=609ecc99 0016:Call KERNEL32.FindResourceW(60bd0000,00000001,00000010) ret=609ecd25 0016:Ret KERNEL32.FindResourceW() retval=00000000 ret=609ecd25 0016:Call KERNEL32.FreeLibrary(60bd0000) ret=609ecd94 ... 0016:Ret KERNEL32.FreeLibrary() retval=00000001 ret=609ecd94 0016:Call KERNEL32.SetLastError(00000714) ret=609ed6e6 0016:Ret KERNEL32.SetLastError() retval=00000714 ret=609ed6e6 0016:Ret version.GetFileVersionInfoSizeW() retval=00000000 ret=6024ad80 --- snip ---
Looking into "C:\windows\Microsoft.NET\Framework\v3.0\fusion.dll" path there is no native fusion.dll. Hence Wine's builtin fusion.dll is loaded by LoadLibraryExW(). The builtin fusion doesn't contain version resource so it fails.
This is a subtile problem: adding version resource to Wine's fusion might cause problems because every .NET Framework might ship it's own version of fusion which ought to override builtin fusion.
http://msdn.microsoft.com/en-us/library/aa370325.aspx
Usually:
C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\fusion.dll C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\fusion.dll
AFAIK .NET 3.0 and 3.5 don't bring their own fusion version (someone might check a real Windows installation with these Frameworks present).
The problem is how dlls/msi/package.c:get_fusion_filename() works. At the point where the installation fails the following registry data is present at the location get_fusion_filename() reads:
--- snip --- [HKEY_LOCAL_MACHINE\Software\Microsoft\NET Framework Setup]
[HKEY_LOCAL_MACHINE\Software\Microsoft\NET Framework Setup\NDP]
[HKEY_LOCAL_MACHINE\Software\Microsoft\NET Framework Setup\NDP\v2.0.50727] "Increment"="42" "Install"=dword:00000001 "MSI"=dword:00000001 "SP"=dword:00000000
[HKEY_LOCAL_MACHINE\Software\Microsoft\NET Framework Setup\NDP\v2.0.50727\1033] "Install"=dword:00000001 "MSI"=dword:00000001 "SP"=dword:00000000
[HKEY_LOCAL_MACHINE\Software\Microsoft\NET Framework Setup\NDP\v3.0]
[HKEY_LOCAL_MACHINE\Software\Microsoft\NET Framework Setup\NDP\v3.0\Setup]
[HKEY_LOCAL_MACHINE\Software\Microsoft\NET Framework Setup\NDP\v3.0\Setup\Windows Communication Foundation] "InstallSuccess"=dword:00000001 "ReferenceInstallPath"="C:\Program Files\Reference Assemblies\Microsoft\Framework\v3.0\" "RuntimeInstallPath"="C:\windows\Microsoft.NET\Framework\v3.0\Windows Communication Foundation\" "Version"="3.0.04506.30"
[HKEY_LOCAL_MACHINE\Software\Microsoft\NET Framework Setup\NDP\v3.0\Setup\Windows Presentation Foundation] @="Windows Presentation Foundation" "InstallRoot"="C:\windows\Microsoft.Net\Framework\v3.0\WPF\" "InstallSuccess"=dword:00000001 "ProductVersion"="3.0.6920.0" "Version"="3.0.6920.0" "WPFCommonAssembliesPathx86"="C:\windows\system32\" "WPFNonReferenceAssembliesPathx86"="C:\windows\Microsoft.Net\Framework\v3.0\WPF\" "WPFReferenceAssembliesPathx86"="C:\Program Files\Reference Assemblies\Microsoft\Framework\v3.0\" --- snip ---
I don't know how Windows msi does MsiNetAssemblySupport. Maybe a check for real existence of (native) fusion.dll to prevent false load of "builtin" fusion is better. If native fusion is not present in full path, that .NET Framework subkey data (version) can't be used for MsiNetAssemblySupport property.
Regards