http://bugs.winehq.org/show_bug.cgi?id=30707
Bug #: 30707 Summary: Add support for .NET 4.0 assembly cache (.NET 4.0 Framework installer) Product: Wine Version: 1.5.4 Platform: x86 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: msi AssignedTo: wine-bugs@winehq.org ReportedBy: focht@gmx.net Classification: Unclassified
Hello,
this is a bug covering Hans' patch http://source.winehq.org/patches/data/86357
'winetricks dotnet40' recipe currently contains 'gacutil' workaround/hack for installing assemblies into .NET 4.0 GAC. .NET's native fusion currently fails due to junction support (bug 10601) hence all assemblies must be manually installed using 'gacutil' as post-installation step.
Using Hans' patch and setting 'fusion=builtin' before running the .NET 4.0 installer gets .NET 4.0 assemblies installed into GAC. The installer actually succeeds which is an improvement over the current "workaround" recipe.
There is a difference though. With Hans' patch all .NET 4.0 assemblies get installed into:
--- snip --- $ pwd /home/focht/.wine/drive_c/windows/assembly ... $ ls */* GAC_32/CustomMarshalers: 4.0.0.0__b03f5f7f11d50a3a
GAC_32/ISymWrapper: 4.0.0.0__b03f5f7f11d50a3a
GAC_32/Microsoft.Transactions.Bridge.Dtc: 4.0.0.0__b03f5f7f11d50a3a
GAC_32/Microsoft.VisualBasic.Activities.Compiler: 10.0.0.0__b03f5f7f11d50a3a ... GAC_32/System.Web: 4.0.0.0__b03f5f7f11d50a3a
GAC_MSIL/Accessibility: 4.0.0.0__b03f5f7f11d50a3a
GAC_MSIL/AspNetMMCExt: 4.0.0.0__b03f5f7f11d50a3a
GAC_MSIL/Microsoft.Build: 4.0.0.0__b03f5f7f11d50a3a ... --- snip ---
Starting with .NET 4.0 there exist two global assembly caches - the "public" one and a "private" one for the Framework.
In previous versions, all .NET assemblies were installed into "C:\windows\assembly".
With .NET 4.0 the assemblies are further split. The "private" GAC for 4.0 is located in "c:\windows\Microsoft.NET\assembly".
See: http://msdn.microsoft.com/en-us/magazine/dd727509.aspx
("Understanding The CLR Binder")
--- quote --- In .NET Framework 4.0, the GAC went through a few changes. The concept of placing assemblies into a global directory began in CLR v1.1. In case of .NET Framework 1.1 (which had CLR v1.1) and .NET Framework 2.0 (which had CLR 2.0), the GAC was split into two, one for each CLR. This avoided the leaking of assemblies across CLR versions. For example, if both .NET 1.1 and .NET 2.0 shared the same GAC, then a .NET 1.1 application, loading an assembly from this shared GAC, could get .NET 2.0 assemblies, thereby breaking the .NET 1.1 application.
The CLR version used for both .NET Framework 2.0 and .NET Framework 3.5 is CLR 2.0. As a result of this, there was no need in the previous two framework releases to split the GAC. The problem of breaking older (in this case, .NET 2.0) applications resurfaces in Net Framework 4.0 at which point CLR 4.0 released. Hence, to avoid interference issues between CLR 2.0 and CLR 4.0, the GAC is now split into private GACs for each runtime.
Tools such as GACUtil and Shfusion will behave exactly the same as they did in pre–.NET Framework 4.0 scenarios. Also, the behavior of publisher policy (explicitly mentioned, since it is required to install these policy files to the GAC) will not change. The main change is that CLR v2.0 applications now cannot see CLR v4.0 assemblies in the GAC. ... --- quote ---
With the current 'winetricks dotnet40' recipe and help of .NET 4.0 'gacutil' the assemblies live in "private" GAC:
--- snip --- $ pwd /home/focht/.wine/drive_c/windows/Microsoft.NET/assembly ... $ ls */*
GAC_MSIL/UIAutomationProvider: v4.0_4.0.0.0__31bf3856ad364e35
GAC_MSIL/UIAutomationTypes: v4.0_4.0.0.0__31bf3856ad364e35
GAC_MSIL/WindowsBase: v4.0_4.0.0.0__31bf3856ad364e35
GAC_MSIL/WindowsFormsIntegration: v4.0_4.0.0.0__31bf3856ad364e35 --- snip ---
"public" GAC with no previous .NET versions installed:
--- snip --- $ ls assembly/ PublisherPolicy.tme pubpol1.dat temp tmp --- snip ---
There are some problems when 'fusion' remains set to 'builtin' after installation though that will be subject to other bugs.
If the .NET 4.0 'private' GAC location is fixed one can safely remove 'fusion=builtin' workaround after running the installer and have a functional .NET Framework installation running with native mscoree/fusion. This allows to get rid of 'gacutil' hack.
Regards
http://bugs.winehq.org/show_bug.cgi?id=30707
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |dotnet, download, Installer URL| |http://download.microsoft.c | |om/download/9/5/A/95A9616B- | |7A37-4AF6-BC36-D6EA96C8DAAE | |/dotNetFx40_Full_x86_x64.ex | |e
http://bugs.winehq.org/show_bug.cgi?id=30707
--- Comment #1 from Hans Leidekker hans@meelstraat.net 2012-05-17 06:46:50 CDT --- This is really a fusion bug, just like 26426 was. Perhaps it's time to add a "fusion" component?
http://bugs.winehq.org/show_bug.cgi?id=30707
--- Comment #2 from Anastasius Focht focht@gmx.net 2012-05-17 07:09:45 CDT --- Hello Hans,
--- quote --- This is really a fusion bug, just like 26426 was. Perhaps it's time to add a "fusion" component? --- quote ---
I took the last msi-component patch that makes use of fusion as "anchor". Fusion related bugs manifest mostly in msi-component/installers (assembly installation) hence both components were usually affected.
But yes, having a "fusion" component might be more appropriate because the root cause is located there.
Regards
http://bugs.winehq.org/show_bug.cgi?id=30707
--- Comment #3 from Anastasius Focht focht@gmx.net 2012-05-17 07:19:02 CDT --- Hello Hans,
I created http://bugs.winehq.org/show_bug.cgi?id=30710 for 'fusion' component request.
Regards
http://bugs.winehq.org/show_bug.cgi?id=30707
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|msi |fusion
http://bugs.winehq.org/show_bug.cgi?id=30707
--- Comment #4 from Hans Leidekker hans@meelstraat.net 2012-05-22 07:47:27 CDT --- I've sent a couple of patches to address this but it's not quite there yet. Native appears to add a v4.0_ prefix to the assembly directory name.
http://bugs.winehq.org/show_bug.cgi?id=30707
--- Comment #5 from Hans Leidekker hans@meelstraat.net 2012-05-23 15:16:04 CDT --- I believe this is fixed now.
http://bugs.winehq.org/show_bug.cgi?id=30707
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |0b82e284013dafd20f14377dda3 | |8820f5645a9b4 Status|NEW |RESOLVED Resolution| |FIXED
--- Comment #6 from Anastasius Focht focht@gmx.net 2012-05-23 15:36:56 CDT --- Hello Hans,
yep, using "fusion=builtin,native" and "ngen=builtin" override all .NET 4.0 assemblies are now properly installed into private GAC.
"ngen=builtin" to avoid native ngen.exe calling into unimplemented fusion API. It's not really harmful as these deferred assembly -> GAC install steps have already been carried out by msi install itself but it might confuse users looking at terminal output, spotting "unimplemented function fusion.dll.InitializeFusion, aborting".
Fixing that part - supporting native ngen + Wine fusion for installers/manual steps that don't use msi assembly install will be subject of other bugs...
Fixed by http://source.winehq.org/git/wine.git/commitdiff/0b82e284013dafd20f14377dda3...
Thanks for the work!
Austin/Dan: starting with Wine 1.5.5 'winetricks dotnet40' recipe can be modified to not use gacutil hack anymore. For Wine < 1.5.5 the current gacutil way should be kept and phased out at some point.
Regards
http://bugs.winehq.org/show_bug.cgi?id=30707
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #7 from Alexandre Julliard julliard@winehq.org 2012-05-25 13:41:10 CDT --- Closing bugs fixed in 1.5.5.
http://bugs.winehq.org/show_bug.cgi?id=30707
--- Comment #8 from Austin English austinenglish@gmail.com 2012-05-25 13:58:21 CDT --- (In reply to comment #6)
Austin/Dan: starting with Wine 1.5.5 'winetricks dotnet40' recipe can be modified to not use gacutil hack anymore. For Wine < 1.5.5 the current gacutil way should be kept and phased out at some point.
http://code.google.com/p/winetricks/source/detail?r=822
Should: mkdir -p "$W_WINDIR_UNIX/Microsoft.NET/assembly/GAC_32/System.EnterpriseServices/v4.0_4.0.0.0__b03f5f7f11d50a3a" cp "$W_WINDIR_UNIX/Microsoft.NET/Framework/v4.0.30319/System.EnterpriseServices.dll" "$W_WINDIR_UNIX/Microsoft.NET/assembly/GAC_32/System.EnterpriseServices/v4.0_4.0.0.0__b03f5f7f11d50a3a"
be < 1.5.5 as well?
http://bugs.winehq.org/show_bug.cgi?id=30707
--- Comment #9 from Anastasius Focht focht@gmx.net 2012-05-25 14:24:48 CDT --- Hello Austin,
--- quote --- Should: mkdir -p "$W_WINDIR_UNIX/Microsoft.NET/assembly/GAC_32/System.EnterpriseServices/v4.0_4.0.0.0__b03f5f7f11d50a3a" cp "$W_WINDIR_UNIX/Microsoft.NET/Framework/v4.0.30319/System.EnterpriseServices.dll" "$W_WINDIR_UNIX/Microsoft.NET/assembly/GAC_32/System.EnterpriseServices/v4.0_4.0.0.0__b03f5f7f11d50a3a"
be < 1.5.5 as well? --- quote ---
yep, that's one of the assemblies requiring junction support during install (native fusion), hence the extra copy "cheat". It should stay with the old recipe.
Regards
http://bugs.winehq.org/show_bug.cgi?id=30707
--- Comment #10 from Austin English austinenglish@gmail.com 2012-05-25 17:08:49 CDT --- (In reply to comment #9)
Hello Austin,
--- quote --- Should: mkdir -p "$W_WINDIR_UNIX/Microsoft.NET/assembly/GAC_32/System.EnterpriseServices/v4.0_4.0.0.0__b03f5f7f11d50a3a" cp "$W_WINDIR_UNIX/Microsoft.NET/Framework/v4.0.30319/System.EnterpriseServices.dll" "$W_WINDIR_UNIX/Microsoft.NET/assembly/GAC_32/System.EnterpriseServices/v4.0_4.0.0.0__b03f5f7f11d50a3a"
be < 1.5.5 as well? --- quote ---
yep, that's one of the assemblies requiring junction support during install (native fusion), hence the extra copy "cheat". It should stay with the old recipe.
Regards
http://code.google.com/p/winetricks/source/detail?r=826
please let me know if there is anything else to change.
http://bugs.winehq.org/show_bug.cgi?id=30707
Dan Kegel dank@kegel.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dank@kegel.com
--- Comment #12 from Dan Kegel dank@kegel.com 2012-07-02 23:28:29 CDT --- Done, I think: http://code.google.com/p/winetricks/source/detail?r=846
http://bugs.winehq.org/show_bug.cgi?id=30707
--- Comment #11 from Anastasius Focht focht@gmx.net 2012-05-26 02:07:13 CDT --- Hello Austin,
the most important part missing: the installer has to be run with fusion set to "prefer builtin". If this temp override is not set the GAC remains empty after install.
--- snip --- WINEDLLOVERRIDES="fusion=b" $WINE dotNetFx40_Full_x86_x64.exe ... --- snip ---
Regards
https://bugs.winehq.org/show_bug.cgi?id=30707
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- URL|http://download.microsoft.c |https://web.archive.org/web |om/download/9/5/A/95A9616B- |/20100818223107/http://down |7A37-4AF6-BC36-D6EA96C8DAAE |load.microsoft.com/download |/dotNetFx40_Full_x86_x64.ex |/9/5/A/95A9616B-7A37-4AF6-B |e |C36-D6EA96C8DAAE/dotNetFx40 | |_Full_x86_x64.exe
-
wine-bugs＠winehq.org -
WineHQ Bugzilla