[Mono-dev] Assemblies in the CLR system directory and F# scripting.
matthi.d at googlemail.com
Thu Apr 16 11:17:24 UTC 2015
On 16.04.2015 12:37, Alexander Köplinger wrote:
> EntityFramework was already removed from the upcoming Mono 4.0.
> I also just checked and on Windows I have System.Web.Razor.dll (Razor
> 2.0) in the GAC as well, so maybe there's some other issue here?
I'm not talking about the GAC, you are right: Leaving a (mono
compatible) version in the GAC is probably good idea.
On Windows the corresponding CLR system directory is (on my machine)
"C:\Windows\Microsoft.NET\Framework\v4.0.30319" and there is no
"System.Web.Razor.dll" in there.
GAC-Linux: /usr/lib/mono/gac/ <- having a compatible
System.Web.Razor.dll is a good thing
GAC-Windows: somewhere <- doesn't matter (for completeness: has a
188.8.131.52 version of System.Web.Razor on my machine, like mono)
CLR-Dir-Windows: "C:\Windows\Microsoft.NET\Framework\v4.0.30319" <- does
not have a System.Web.Razor.dll (at least on my machine)
CLR-Dir-Linux: /usr/lib/mono/4.5 (number depends on the runtime used) <-
has System.Web.Razor.dll (= problem I was describing in the last email)
Please correct me if my analysis is incorrect.
If you indeed have a System.Web.Razor.dll in the CLR directory it might
have been installed with some additional package?
> -- Alex
>> From: matthi.d at googlemail.com
>> Date: Thu, 16 Apr 2015 12:08:54 +0200
>> To: mono-devel-list at lists.ximian.com
>> Subject: [Mono-dev] Assemblies in the CLR system directory and F#
>> Hi all,
>> TL;DR: We should remove System.Web.Razor.dll, EntityFramework.dll (and
>> possibly more) from "/usr/lib/mono/4.5"
>> I noticed that some assemblies (namely "EntityFramework" and
>> "System.Web.Razor" and possibly more) lead to problems when used within
>> a F# script file. The problem is the following:
>> Assume you use NuGet to download the latest Razor-3 package and then do
>> the following (in an F# script file):
>> #I "packages/Microsoft.AspNet.Razor/lib/net45"
>> #r "System.Web.Razor.dll"
>> Note that this is the usual way of loading assemblies in F# scripting
>> and it works fine on Windows/.NET.
>> However because this is the same as using
>> /reference:System.Web.Razor.dll" on the C# compiler and because mono has
>> a "System.Web.Razor.dll" in its CLR system directory (/usr/lib/mono/4.5)
>> it will redirect the reference (CLR system directory is always
>> preferred, see https://msdn.microsoft.com/en-us/library/s5bac5fx.aspx).
>> This already hit me several times:
>> - https://github.com/fsharp/FSharp.Compiler.Service/issues/313
>> - https://github.com/tpetricek/FSharp.Formatting/pull/279
>> I'm not really sure why mono actually needs those file to live there.
>> For referencing the NuGet package should be fine. To load the correct
>> (mono compatible) version on runtime the GAC should do it.
>> IMHO we can just remove the System.Web.Razor.dll (and possibly others?)
>> from the runtime directory.
>> @akoeplinger noted the following in the gitter chat: It would be a
>> breaking change for people depending on "/reference:System.Web.Razor" to
>> just work.
>> But I'm not sure how common that is with the NuGet package in place.
>> IIRC xbuild and msbuild always use fully qualified references, so it
>> shouldn't be a problem for them.
>> So... Is removing those file something we can do? I just wanted to bring
>> attention to this issue as it can be *really* hard to debug. The
>> workarounds in place for this are required anyway to work with older
>> mono versions. The workaround in itself is simple you just need to use
>> the fully qualified reference instead:
>> #r "packages/Microsoft.AspNet.Razor/lib/net45/System.Web.Razor.dll"
>> However this can be a problem if you don't know in advance in which of
>> the included directories ("#I") the file is living. (Because F# will
>> stop executing if the fully qualified reference doesn't exists).
>> Mono-devel-list mailing list
>> Mono-devel-list at lists.ximian.com
More information about the Mono-devel-list