MONO_4_0 support

[ArsenShnurkov]

I added MONO_4_0 define for packaging with portage package manager

UPD: see also
http://stackoverflow.com/questions/33185770/older-version-of-net-not-installed-with-latest-mono

[ie-zero]

Excuse my ignorance but are there any conditional compilation code blocks which might be affected from this change?

[ArsenShnurkov]

Yes, I added 2 configurations for mono 2 and mono 4, and I tested building in both configurations (and also I corrected some conditional preprocessing directives)

[304NotModified]

Thanks for this PR!

To be consistent, we prefer:

• separate solutions and projects.
• naming MONO2_0 instead of MONO_2_0

Can you tell me how to change the nuspec for this? As you can see, mono isn't in nuspec yet.

[ArsenShnurkov]

Thank you for your fast and valuable reply!

1. You don't have mono-specific dlls, because your proj script doesn't contain line

<NuGetDir>somedir</NuGetDir>

here:

NLog/src/NLog.proj

Lines 107 to 108 in 9bc000a

	<ToolsVersion>3.5</ToolsVersion>
	</TargetFramework>

the problem is that there should be no such thing as "mono specific", because they should be byte by byte the same as .net version dlls. You can install it into mono2 and mono4. But why on the earth mono projects should use these libraries instead of libraries for their required frameworks (i.e. lib/net35, lib/net45) ?

And this is your problem, not mine. Because I don't use NLog.proj file at all. I have portage bash script which builds my package from my separate nuspec (I build my version of nupkg with lib/net45/NLib.dll inside)

Probably it is possible to build them into net35 and net45 (assuming that this is linux-hosted build and .net versions will not be built at the same machine).

Or one need to check the underlaying build OS (if it is windows - then build mono assemblies with separate toolchain and place them into separate location).
Here is how to detect Linux ot Windows OS from C# code (which can be run from inside of .proj):
http://stackoverflow.com/questions/5116977/how-to-check-the-os-version-at-runtime-e-g-windows-or-linux-without-using-a-con

2. you have a wrong name of project

https://github.com/NLog/NLog/blob/9bc000af0df388b409f7f34869df544b311d1716/src/NLog/NLog.mono.csproj

but it should be NLog.mono2.csproj to be used in

<MSBuild Projects="NLog\NLog%(TargetFramework.ProjectFileSuffix).csproj" 
         Targets="Build" 
         Properties="$(StyleCopProperties);%(TargetFramework.Properties);BaseOutputDirectory=$(BaseOutputDirectory);BuildInfoFile=$(BuildInfoFile)" 
         ToolsVersion="%(TargetFramework.ToolsVersion)" 
         ContinueOnError="$(IgnoreBuildFailures)" 
         StopOnFirstFailure="false" />

NLog/src/NLog.proj

Line 176 in 9bc000a

<MSBuild Projects="NLog\NLog%(TargetFramework.ProjectFileSuffix).csproj"

because of the value of ProjectFileSuffix property:

<TargetFramework Include="Mono 2.x" Condition="'$(BuildMono2)' == 'true'">
    <ProjectFileSuffix>.mono2</ProjectFileSuffix>
    <ToolsVersion>3.5</ToolsVersion>
</TargetFramework>

NLog/src/NLog.proj

Lines 105 to 108 in 9bc000a

	<TargetFramework Include="Mono 2.x" Condition="'$(BuildMono2)' == 'true'">
	<ProjectFileSuffix>.mono2</ProjectFileSuffix>
	<ToolsVersion>3.5</ToolsVersion>
	</TargetFramework>

3. MONO_2_0 is the original name of the constant. I didn't change it. I just added MONO_4_0 in the same style

4. I will add one more commit (to provide assembly versioning for mono builds)

[304NotModified]

Thanks for the comprehensive response!

1+2) Yes, the .proj isn't good for Mono, but that has probably a cause.
We are already using sometimes platform detection (https://github.com/NLog/NLog/blob/master/src/NLog/Internal/PlatformDetector.cs), but that's bad and cannot be used in PCL nor CoreCLR

3. You're right! Sorry for the mistake.

---

The key question is, if MONO uses the .Net dll's, then we can:

A) Make a separate nuget package for mono (has seen that before)
B) Ask people to build their own binaries (for mono)
C) Download the Mono binaries from somewhere else (not nuget)
D) Fix the code so it uses dynamic recognition of platform, instead of conditional compilation symbols eg#if MONO_2_0
E) Don't care and hope for the best (current approach, I'm afraid)

At least, the usage of conditional compilation symbols are questionable. The up-side, we can build it with mono and knows that it works (mostly).

But now I dunno what to do with #if MONO_4_0. With the current approach, if won't gain a lot?

Also, it's not clear to mean what the benefit is besides the current MONO_2. What are the features what aren't supported inn MONO2?

[ArsenShnurkov]

Unfortunately I don't have xunit on my linux yet, because of xunit/xunit#548

So, I disabled build of tests in .sln file.
this lead to

error: file not found: ./build/bin/Release/Mono 2.x/NLog.UnitTests.dll

and following

The command "mono ./testrunner/xunit.runners.1.9.2/tools/xunit.console.clr4.exe "./build/bin/Release/Mono 2.x/NLog.UnitTests.dll"" exited with 255.

Actually, I am working on issue gentoo/dotnet#115
and NLog is just one of dependencies. So I see this project for the first time and need your help with this PR (because on my machnine everything works, and i don't have windows to build .proj and don't need tests).

Now I am going to reenable test projects in .sln files, and disable them locally with my portage patch

[ArsenShnurkov]

Mono.targets was broken (because it can't work on linux in principle)

1. this line gives an exception:

<MonoDefaultClr>$(Registry:HKEY_LOCAL_MACHINE\SOFTWARE\Novell\Mono@DefaultCLR)</MonoDefaultClr>

NLog/src/Mono.targets

Line 4 in fb44621

<MonoDefaultClr>$(Registry:HKEY_LOCAL_MACHINE\SOFTWARE\Novell\Mono@DefaultCLR)</MonoDefaultClr>

the text of exception is

/home/travis/build/NLog/NLog/tests/NLog.UnitTests/NLog.UnitTests.mono2.csproj: error : /home/travis/build/NLog/NLog/tests/NLog.UnitTests/NLog.UnitTests.mono2.csproj: Registry function
 3 Warning(s)
 1 Error(s)

and here is it's source:
https://github.com/mono/mono/blob/9a9e721cd85568cf4a5ae7ac22c7f12fea97be80/mcs/class/Microsoft.Build.Engine/Microsoft.Build.BuildEngine/Expression.cs#L345-L351

2. there is no .bat files on linux, they are .sh or without extension:

    <MonoCommandLine>"$(MonoInstallLocation)\bin\gmcs.bat"</MonoCommandLine>

NLog/src/Mono.targets

Line 39 in fb44621

<MonoCommandLine>"$(MonoInstallLocation)\bin\gmcs.bat"</MonoCommandLine>

Mono.targets was used in

NLog/tests/NLog.UnitTests/NLog.UnitTests.mono2.csproj

Line 158 in 0f3f34f

<Import Project="..\..\src\Mono.targets" />

This file was not tested in CI builds. (because another file with name NLog.UnitTests.mono.csproj was built with .sln)

For now I have no opinion what to do with it...

[ArsenShnurkov]

NLog.UnitTests.LogFactoryTests.Auto_Reload_invalidxml_test [FAIL]
   System.Exception : failed to reload - 2
   Stack Trace:
     at NLog.UnitTests.LogFactoryTests.Auto_Reload_invalidxml_test () [0x00000] in <filename unknown>:0 
     at (wrapper managed-to-native) System.Reflection.MonoMethod:InternalInvoke (System.Reflection.MonoMethod,object,object[],System.Exception&)
     at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00000] in <filename unknown>:0
Tests complete: 491 of 703
No output has been received in the last 10 minutes, this potentially indicates a stalled build or something wrong with the build itself.
The build has been terminated

this kind of noncrossplatform code

@"c:\temp\log.txt"

NLog/tests/NLog.UnitTests/LogFactoryTests.cs

Line 344 in aa7af2b

Test_if_reload_success(@"c:\temp\log.txt");

has no chances to pass, i guess...

I have no future plans on improving this PR (works for me).

[ArsenShnurkov]

my local version of mono is exactly
Mono JIT compiler version 4.2.0 (Stable 4.2.0.179/a224653 Wed Sep 16 20:09:53 MSK 2015)

travis's version is (too old):
Mono JIT compiler version 4.0.4 (Stable 4.0.4.1/5ab4c0d Tue Aug 25 23:11:51 UTC 2015)

[304NotModified]

@ArsenShnurkov I have no idea what to do with this PR. I can merge it (after resolve conflicts), but it's useless if we don't release it somewhere (nuget?)

So need you opinion on that. Also I was wondering, why can't we use Mono2 and that should also work on mono4?

[ArsenShnurkov]

"it's useless if we don't release it somewhere"

it is usefull in linux distributions, which build software from sources (i.e. portage and paludis-based distributions, such as Gentoo Linux, Funtoo Linux, Calculate Linux, Sabayon Linux, Exherbo and others)

The reason of this PR was the attempt to package (release) this project for portage.

See gentoo/dotnet#137 for details

"I was wondering, why can't we use Mono2 and that should also work on mono4"

Mono4 introduces breaking changes, and old programs will not compile anymore (binaries would run, but it's different story)

[304NotModified]

OK, thanks for the answers.

Can you check the conflicts?

I will merge it when it builds :)

[ArsenShnurkov]

It builds. It's the unit tests what fails.
NLog.UnitTests.SourceCodeTests.VerifyProjectsInSync [FAIL]
in particular.

[304NotModified]

Well it has a conflict now :(

Can you rebase?

You can fix VerifyProjectsInSync with

NLog\src>msbuild NLog.proj /t:SyncProjectItems

See https://github.com/NLog/NLog/blob/master/CONTRIBUTING.md

[304NotModified]

PS: probably merging #1009 will also create conflicts. But I need some things to fix at #1009

[304NotModified]

I like to merge this for 4.3 (first waiting for 4.2.1 release) . Do you need help on fixing the last things?

[ArsenShnurkov]

i have no enough physical resources now (i.e. money). may be later. sorry

[304NotModified]

If you reopen this PR and add me as collaborator, I will fix these last things (iff you can answer some questions if i'm lost)

[304NotModified]

We don't need this anymore with netstandard :)