Re: [Mono-dev] LLVM + mac deploys
See twitter ... adding you there so you get link + user On Thu, Apr 16, 2015 at 5:31 PM, Miguel de Icaza wrote: > That is most definitely not the version that xamarin is shipping. > > On Thu, Apr 16, 2015 at 10:30 AM, Greg Young > wrote: >> >> Did something like just change with this? I just asked if anyone could >> do a fresh install and got >> >> mono --version >> Mono JIT compiler version 3.12.1 (tarball Tue Mar 17 15:03:14 GMT 2015) >> Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors. >> www.mono-project.com >> TLS: normal >> SIGSEGV: altstack >> Notification: kqueue >> Architecture: amd64 >> Disabled: none >> Misc: softdebug >> LLVM: supported, not enabled. >> GC:sgen >> >> On Thu, Apr 16, 2015 at 5:17 PM, Miguel de Icaza >> wrote: >> > Right, Mono on Mac is currently 32 bits, and we ship LLVM with it. >> > >> > But we do not default to LLVM, that is something that you can use when >> > you >> > pass the --llvm option. >> > >> > I believe we are just about to release a Mono that includes both 32 and >> > 64 >> > bit binaries. >> > >> > Miguel >> > >> > On Thu, Apr 16, 2015 at 10:15 AM, Greg Young >> > wrote: >> >> >> >> Some others are saying the xamarin package is also 32bit + llvm >> >> >> >> I don't have it installed here to test >> >> >> >> On Thu, Apr 16, 2015 at 5:13 PM, Miguel de Icaza >> >> wrote: >> >> > Hello, >> >> > >> >> > LLVM is never the default for JIT configurations, it is something >> >> > that >> >> > you >> >> > must manually opt-into. >> >> > >> >> > Did homebrew default to it? Because LLVM as a JIT is *very slow* >> >> > >> >> > Miguel >> >> > >> >> > On Thu, Apr 16, 2015 at 8:35 AM, Greg Young >> >> > wrote: >> >> >> >> >> >> I was looking through an issue from a mac user today. >> >> >> >> >> >> Apparently when they brought down mono from home brew there were two >> >> >> odds things. >> >> >> >> >> >> 1) It was 32bit. That's not really for this list though >> >> >> 2) It was using LLVM by default. Is LLVM ready for being the default >> >> >> at this point? I haven't been following it much. >> >> >> >> >> >> What is the current "best practice" for a mac user to be installing? >> >> >> I >> >> >> run builds myself but figure there is a better way >> >> >> >> >> >> Cheers, >> >> >> >> >> >> Greg >> >> >> >> >> >> -- >> >> >> Studying for the Turing test >> >> >> ___ >> >> >> Mono-devel-list mailing list >> >> >> Mono-devel-list@lists.ximian.com >> >> >> http://lists.ximian.com/mailman/listinfo/mono-devel-list >> >> > >> >> > >> >> >> >> >> >> >> >> -- >> >> Studying for the Turing test >> > >> > >> >> >> >> -- >> Studying for the Turing test > > -- Studying for the Turing test ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] LLVM + mac deploys
That is most definitely not the version that xamarin is shipping. On Thu, Apr 16, 2015 at 10:30 AM, Greg Young wrote: > Did something like just change with this? I just asked if anyone could > do a fresh install and got > > mono --version > Mono JIT compiler version 3.12.1 (tarball Tue Mar 17 15:03:14 GMT 2015) > Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors. > www.mono-project.com > TLS: normal > SIGSEGV: altstack > Notification: kqueue > Architecture: amd64 > Disabled: none > Misc: softdebug > LLVM: supported, not enabled. > GC:sgen > > On Thu, Apr 16, 2015 at 5:17 PM, Miguel de Icaza > wrote: > > Right, Mono on Mac is currently 32 bits, and we ship LLVM with it. > > > > But we do not default to LLVM, that is something that you can use when > you > > pass the --llvm option. > > > > I believe we are just about to release a Mono that includes both 32 and > 64 > > bit binaries. > > > > Miguel > > > > On Thu, Apr 16, 2015 at 10:15 AM, Greg Young > > wrote: > >> > >> Some others are saying the xamarin package is also 32bit + llvm > >> > >> I don't have it installed here to test > >> > >> On Thu, Apr 16, 2015 at 5:13 PM, Miguel de Icaza > >> wrote: > >> > Hello, > >> > > >> > LLVM is never the default for JIT configurations, it is something that > >> > you > >> > must manually opt-into. > >> > > >> > Did homebrew default to it? Because LLVM as a JIT is *very slow* > >> > > >> > Miguel > >> > > >> > On Thu, Apr 16, 2015 at 8:35 AM, Greg Young > >> > wrote: > >> >> > >> >> I was looking through an issue from a mac user today. > >> >> > >> >> Apparently when they brought down mono from home brew there were two > >> >> odds things. > >> >> > >> >> 1) It was 32bit. That's not really for this list though > >> >> 2) It was using LLVM by default. Is LLVM ready for being the default > >> >> at this point? I haven't been following it much. > >> >> > >> >> What is the current "best practice" for a mac user to be installing? > I > >> >> run builds myself but figure there is a better way > >> >> > >> >> Cheers, > >> >> > >> >> Greg > >> >> > >> >> -- > >> >> Studying for the Turing test > >> >> ___ > >> >> Mono-devel-list mailing list > >> >> Mono-devel-list@lists.ximian.com > >> >> http://lists.ximian.com/mailman/listinfo/mono-devel-list > >> > > >> > > >> > >> > >> > >> -- > >> Studying for the Turing test > > > > > > > > -- > Studying for the Turing test > ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] LLVM + mac deploys
Did something like just change with this? I just asked if anyone could do a fresh install and got mono --version Mono JIT compiler version 3.12.1 (tarball Tue Mar 17 15:03:14 GMT 2015) Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors. www.mono-project.com TLS: normal SIGSEGV: altstack Notification: kqueue Architecture: amd64 Disabled: none Misc: softdebug LLVM: supported, not enabled. GC:sgen On Thu, Apr 16, 2015 at 5:17 PM, Miguel de Icaza wrote: > Right, Mono on Mac is currently 32 bits, and we ship LLVM with it. > > But we do not default to LLVM, that is something that you can use when you > pass the --llvm option. > > I believe we are just about to release a Mono that includes both 32 and 64 > bit binaries. > > Miguel > > On Thu, Apr 16, 2015 at 10:15 AM, Greg Young > wrote: >> >> Some others are saying the xamarin package is also 32bit + llvm >> >> I don't have it installed here to test >> >> On Thu, Apr 16, 2015 at 5:13 PM, Miguel de Icaza >> wrote: >> > Hello, >> > >> > LLVM is never the default for JIT configurations, it is something that >> > you >> > must manually opt-into. >> > >> > Did homebrew default to it? Because LLVM as a JIT is *very slow* >> > >> > Miguel >> > >> > On Thu, Apr 16, 2015 at 8:35 AM, Greg Young >> > wrote: >> >> >> >> I was looking through an issue from a mac user today. >> >> >> >> Apparently when they brought down mono from home brew there were two >> >> odds things. >> >> >> >> 1) It was 32bit. That's not really for this list though >> >> 2) It was using LLVM by default. Is LLVM ready for being the default >> >> at this point? I haven't been following it much. >> >> >> >> What is the current "best practice" for a mac user to be installing? I >> >> run builds myself but figure there is a better way >> >> >> >> Cheers, >> >> >> >> Greg >> >> >> >> -- >> >> Studying for the Turing test >> >> ___ >> >> Mono-devel-list mailing list >> >> Mono-devel-list@lists.ximian.com >> >> http://lists.ximian.com/mailman/listinfo/mono-devel-list >> > >> > >> >> >> >> -- >> Studying for the Turing test > > -- Studying for the Turing test ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] LLVM + mac deploys
Some others are saying the xamarin package is also 32bit + llvm I don't have it installed here to test On Thu, Apr 16, 2015 at 5:13 PM, Miguel de Icaza wrote: > Hello, > > LLVM is never the default for JIT configurations, it is something that you > must manually opt-into. > > Did homebrew default to it? Because LLVM as a JIT is *very slow* > > Miguel > > On Thu, Apr 16, 2015 at 8:35 AM, Greg Young wrote: >> >> I was looking through an issue from a mac user today. >> >> Apparently when they brought down mono from home brew there were two >> odds things. >> >> 1) It was 32bit. That's not really for this list though >> 2) It was using LLVM by default. Is LLVM ready for being the default >> at this point? I haven't been following it much. >> >> What is the current "best practice" for a mac user to be installing? I >> run builds myself but figure there is a better way >> >> Cheers, >> >> Greg >> >> -- >> Studying for the Turing test >> ___ >> Mono-devel-list mailing list >> Mono-devel-list@lists.ximian.com >> http://lists.ximian.com/mailman/listinfo/mono-devel-list > > -- Studying for the Turing test ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] LLVM + mac deploys
Hello, LLVM is never the default for JIT configurations, it is something that you must manually opt-into. Did homebrew default to it? Because LLVM as a JIT is *very slow* Miguel On Thu, Apr 16, 2015 at 8:35 AM, Greg Young wrote: > I was looking through an issue from a mac user today. > > Apparently when they brought down mono from home brew there were two > odds things. > > 1) It was 32bit. That's not really for this list though > 2) It was using LLVM by default. Is LLVM ready for being the default > at this point? I haven't been following it much. > > What is the current "best practice" for a mac user to be installing? I > run builds myself but figure there is a better way > > Cheers, > > Greg > > -- > Studying for the Turing test > ___ > Mono-devel-list mailing list > Mono-devel-list@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] LLVM + mac deploys
Right, Mono on Mac is currently 32 bits, and we ship LLVM with it. But we do not default to LLVM, that is something that you can use when you pass the --llvm option. I believe we are just about to release a Mono that includes both 32 and 64 bit binaries. Miguel On Thu, Apr 16, 2015 at 10:15 AM, Greg Young wrote: > Some others are saying the xamarin package is also 32bit + llvm > > I don't have it installed here to test > > On Thu, Apr 16, 2015 at 5:13 PM, Miguel de Icaza > wrote: > > Hello, > > > > LLVM is never the default for JIT configurations, it is something that > you > > must manually opt-into. > > > > Did homebrew default to it? Because LLVM as a JIT is *very slow* > > > > Miguel > > > > On Thu, Apr 16, 2015 at 8:35 AM, Greg Young > wrote: > >> > >> I was looking through an issue from a mac user today. > >> > >> Apparently when they brought down mono from home brew there were two > >> odds things. > >> > >> 1) It was 32bit. That's not really for this list though > >> 2) It was using LLVM by default. Is LLVM ready for being the default > >> at this point? I haven't been following it much. > >> > >> What is the current "best practice" for a mac user to be installing? I > >> run builds myself but figure there is a better way > >> > >> Cheers, > >> > >> Greg > >> > >> -- > >> Studying for the Turing test > >> ___ > >> Mono-devel-list mailing list > >> Mono-devel-list@lists.ximian.com > >> http://lists.ximian.com/mailman/listinfo/mono-devel-list > > > > > > > > -- > Studying for the Turing test > ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] LLVM + mac deploys
I was looking through an issue from a mac user today. Apparently when they brought down mono from home brew there were two odds things. 1) It was 32bit. That's not really for this list though 2) It was using LLVM by default. Is LLVM ready for being the default at this point? I haven't been following it much. What is the current "best practice" for a mac user to be installing? I run builds myself but figure there is a better way Cheers, Greg -- Studying for the Turing test ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Build failure on ARMv6/Raspberry Pi with Raspbian/armhf (Mono-devel-list Digest, Vol 120, Issue 11)
On 15/04/15 14:21, Fabian Pietsch wrote: > Hi, > > I'm trying to compile Mono GIT mono-3.12.0-branch on the Raspberry > Pi (ARMv6), on Raspbian/armhf (Mono 3.2.8), with monolite-111-latest > 3.6.1.0 as bootstrap compiler. > > I'm building like this: > > mono $ ./autogen.sh --prefix=/usr/local > EXTERNAL_MCS="/home/pi/build/mono/mono/mcs/class/lib/monolite/gmcs.exe" > [...] > mono $ SKIP_AOT=true make > EXTERNAL_MCS="/home/pi/build/mono/mono/mcs/class/lib/monolite/gmcs.exe" V=1 > [...] > make[8]: Entering directory '/home/pi/build/mono/mono/mcs/class/corlib' > /bin/sh ./../../mkinstalldirs ../../class/lib/build/ > touch ../../class/lib/build//.stamp > MONO_PATH="./../../class/lib/basic:$MONO_PATH" > /home/pi/build/mono/mono/runtime/mono-wrapper > ./../../class/lib/basic/basic.exe /codepage:65001 -unsafe -nostdlib > -nowarn:612,618 -d:INSIDE_CORLIB -d:LIBC -d:NET_1_1 -d:NET_2_0 -d:NET_3_0 > -d:NET_3_5 -d:NET_4_0 -nowarn:1699 -nostdlib -lib:./../../class/lib/build > -optimize /noconfig -resource:resources/collation.core.bin > -resource:resources/collation.tailoring.bin > -resource:resources/collation.cjkCHS.bin > -resource:resources/collation.cjkCHT.bin > -resource:resources/collation.cjkJA.bin > -resource:resources/collation.cjkKO.bin > -resource:resources/collation.cjkKOlv2.bin --runtime:v4 -target:library > -out:../../class/lib/build/mscorlib.dll @corlib.dll.sources > > Unhandled Exception: > System.TypeLoadException: Could not load type 'Mono.CSharp.CommandLineParser' > from assembly 'basic, Version=3.12.1.0, Culture=neutral, PublicKeyToken=null'. > [ERROR] FATAL UNHANDLED EXCEPTION: System.TypeLoadException: Could not load > type 'Mono.CSharp.CommandLineParser' from assembly 'basic, Version=3.12.1.0, > Culture=neutral, PublicKeyToken=null'. > ../../build/library.make:275: recipe for target > '../../class/lib/build/mscorlib.dll' failed > make[8]: *** [../../class/lib/build/mscorlib.dll] Error 1 > [...] Don't specify EXTERNAL_MCS. EXTERNAL_MCS needs to be set to an executable c# compiler, i.e. "/usr/bin/mcs" not to a C# compiler assembly, i.e. "/usr/lib/mono/4.5/mcs.exe" (the former requires an existing working Mono in some path). In your case, because you have the binfmt-support package installed, the kernel is interpreting efforts to execute mcs.exe directly and passing them through /usr/bin/mono - mcs 3.12 doesn't work on Mono 3.2.8 If EXTERNAL_MCS does not exist, and "mcs" does not exist in $PATH, then the build system will use mcs.exe from monolite/ using the just-built mono in mono/mini - this is the scenario you want. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Assemblies in the CLR system directory and F# scripting.
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: matth...@googlemail.com
>> Date: Thu, 16 Apr 2015 12:08:54 +0200
>> To: mono-devel-list@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@lists.ximian.com
>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Assemblies in the CLR system directory and F# scripting.
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?
-- Alex
> From: matth...@googlemail.com
> Date: Thu, 16 Apr 2015 12:08:54 +0200
> To: mono-devel-list@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@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[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@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
