[Mono-dev] Assemblies in the CLR system directory and F# scripting.

[Matthias Dittrich]

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.
(System.Runtime.InteropServices.RuntimeEnvironment.GetRuntimeDirectory()).

To clarify:
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
2.0.0.0 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?

-- Matthias
>  
> -- 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#
> scripting.
>>
>> 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
>> "/lib:packages/Microsoft.AspNet.Razor/lib/net45
>> /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).
>>
>> Thanks,
>> Matthias
>> _______________________________________________
>> Mono-devel-list mailing list
>> Mono-devel-list at lists.ximian.com
>> http://lists.ximian.com/mailman/listinfo/mono-devel-list