[Bug 16891] New: .NET 3.0: Windows Workflow Foundation installer claims .NET 2.0 Framework needed, MsiNetAssemblySupport/msi fusion version retrieval bug

wine-bugs at winehq.org wine-bugs at winehq.org
Sun Jan 11 12:15:10 CST 2009


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 at winehq.org
        ReportedBy: focht at 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


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



More information about the wine-bugs mailing list