Support CoreCLR

Any idea when NLog will support CoreCLR?
So thanks.
Meriturva

Do you have an idea what we should change to support coreclr? (Process, code, build)
Correct me if wrong, I think with visual studio 2015 it would be easier to support coreCLR.

I don't have an idea, i have installed VisualStudo 2015 CTP 6 last week....it is completely based on new environments.... coreFx and coreClr.
I think that there are a lot of changes specially for the System.IO namespace....and coreClr is not finished right now.

I'm pretty sure we will support coreCLR.  Probably the next release after 4.0.

Moved to feature request.

Has there been any further discussion around this?

Well I tried PCL, and it was really a major task to get that working. We never got that working due to the many things that are missing.
I thought the same problem was for coreCLR. We like to support it, but if we have to rewrite a lot of stuff, it will take a lot of time.

Related is this branch (UAP10)
https://github.com/304NotModified/NLog/tree/UAP10
But is has still some compile errors. UAP <> coreclr, but is not fully clear what the relation is between them.

46 errors.

But real stuck now.

Well CoreCLR won't have issue #3 or #4 as Stackframes are available.  That said I'm only vaguely aware of supporting multiple environments so I'm not sure how adding dnxcore50 without going the PCL is any different then supporting Silverlight without PCL.
If someone picks up this issue at some point it'd be good to be aware of https://github.com/aspnet/Logging

Well CoreCLR won't have issue 3 or 4 as Stackframes are available.

Any idea what about 5?

That said I'm only vaguely aware of supporting multiple environments so I'm not sure how adding dnxcore50 without going the PCL is any different then supporting Silverlight without PCL.

We use multiple solution/project files and compiler conditionals (e.g. #if NET3_5)
But I don't have any experience with CoreCLR, yet. I also still in beta? How do I create a CoreCLR supported library in Visual Studio (2015)?

If someone picks up this issue at some point it'd be good to be aware of https://github.com/aspnet/Logging

I think we should also write an adapter for that. Do we need coreCLR support for it?

My 2 cents here:
At least when it comes to projects/solutions...
Part of this whole new world is also a new build system (aka project.json)
which is capable of targeting both the standard framework and the new
dnx/coreclr one.
So,  at least in theory,  it should be possible to covert to the new build
system while still targeting the normal framework,  while building out the
the coreclr one
On Oct 10, 2015 6:07 PM, "Julian Verdurmen"<EMAIL_ADDRESS>wrote:

Well CoreCLR won't have issue 3 or 4 as Stackframes are available.
Any idea what about 5?
That said I'm only vaguely aware of supporting multiple environments so
I'm not sure how adding dnxcore50 without going the PCL is any different
then supporting Silverlight without PCL.
We use multiple solution/project files and compiler conditionals (e.g. #if
NET3_5)
But I don't have any experience with CoreCLR, yet. I also still in beta?
How do I create a CoreCLR supported library in Visual Studio (2015)?
If someone picks up this issue at some point it'd be good to be aware of
https://github.com/aspnet/Logging
I think we should also write an adapter for that. Do we need coreCLR
support for it?
—
Reply to this email directly or view it on GitHub
https://github.com/NLog/NLog/issues/641#issuecomment-147096262.

Thanks @damageboy , so I don't need a new project file (csproj), but only a project.json?
PS analysis result of this cool extension

I see that .Net core is planned in Q1 2016.
https://github.com/dotnet/core/blob/master/roadmap.md

note5 :	Use AssemblyLoadContext

Basically, once you switch to project.json, your main build system is a
command line build, through the dot net utility (dnu),
so you build/pack with dnu build / dnu pack
Of course, microsoft being microsoft, the GUI is never far behind.
So there's a new project extension .xproj, which really just references the
project.json file for more native support through VS UI.
Right now, the whole thing is shipped with VS 2015 RTM as beta5, there's a
beta7 package out there for anyone to install:
http://www.microsoft.com/en-us/download/details.aspx?id=48738&fa43d42b-25b5-4a42-fe9b-1634f450f5ee=True
And there's supposed to be a beta8 release anyday now (October 12th right
now, but it's being pushed back every couple of days)
The portability analyzer is a great tool, although currently the biggest
hurdle is when your project is dependent on other critical packages that
don't support corclr yet.
In NLog's case I think the situation is actually pretty great (which is
really uncommon): You have no critical package dependencies except for
XUnit which is actually supported (version 2.0 only) under coreclr!
Shechter.

On Sat, Oct 10, 2015 at 6:41 PM, Julian Verdurmen<EMAIL_ADDRESS>wrote:

note5 : Use AssemblyLoadContext
—
Reply to this email directly or view it on GitHub
https://github.com/NLog/NLog/issues/641#issuecomment-147100945.

I should point out though, that one of the nicer aspects of the new system,
is that once you do that switch, each target platform that your project
targets gets built every build...
So essentially, you start hacking NLog for coreclr while using the new
project.json system, and every build you issue through VS shows build
errors from all your targets (coreclr + regular .net), which really helps
streamline development...
Shechter.

On Sat, Oct 10, 2015 at 6:41 PM, Julian Verdurmen<EMAIL_ADDRESS>wrote:

note5 : Use AssemblyLoadContext
—
Reply to this email directly or view it on GitHub
https://github.com/NLog/NLog/issues/641#issuecomment-147100945.

Thanks @damageboy !
I'm now trying to get the UAP10 build working. After that, I will check on coreCLR.

any news?

Yes,
we have a plan now:

We will fix first Xamarin (see #1009) - this is now for 80% done
Then we will fix UAP10  - done for 60%
And after that or .Net Core, of PCL.  We will decide then, but PCL has a lot more up-votes: http://nlog.userecho.com/list/44388-general/#module_994254/search/support

Because .Net Core isn't released yet, we find it has less prio.
If you think the .Net Core should be done earlier, help will be boost the development!

CoreCLR is now RC1, which is "go-live". It is at a good state to start switching over.

Can you help with porting NLog?

Would you be willing to change the build system to use dnx project.json? It is a big change from typical .proj in terms of development, deployment, etc.

I think we need it for coreCLR? Or is it optional?
It's also unknown to me if we an use project.json for older/other frameworks (.Net 3.5, silverlight, Xamarin Android etc)

Yes, you can target any runtime.
Refer to JSON.NET's project.json file.

Thanks @theonlylawislove ,
As you have noticed, we haven't any experience with the new core platform, yet.
To get some experience, I will convert first https://github.com/UniversalCharsetDetector/ude to CoreCLR / PCL. This is a small library which should be easily ported.

Awesome!
My email is hooked up to Google Hangouts if you need help with anything.

Thanks for the help!

@theonlylawislove
one question already, do I need to refer the project.json in the .sln file and drop the csproj?

The .sln file now doesn't reference project.json and global.json are ultra portable methods for project layout. If you'd like to use visual studio, be sure to use visual studio to create the solution and library projects, because it will create a .sln file that references the new ".xproj" files.
I'm not sure if you can add the .xproj files to any .sln. I'd start from scratch with the .sln that the "New project" wizard in visual studio gives you.

Which solution/project template do I need?
(no hangouts yet)

Class Library (Package)
Make sure you have the latest RC of ASP.NET 5 installed.
https://get.asp.net/

I tried to first run build a PCL (Class Libary (Portable), but I fails every time to build on AppVeyor. Any idea why?
https://github.com/UniversalCharsetDetector/ude/tree/pcl-notests
https://ci.appveyor.com/project/304NotModified/ude/history

Does it build in Visual Studio?
I personally haven't setup and CI build yet. I think you will need to use dnx to publish though.
https://github.com/aspnet/Home/wiki/DNX-utility

Yes, it builds in VS2015, but not with commandline msbuild also.
We need definitely CI for NLog

Take a look at the build.ps1 for Json.NET, particularly the DnxBuild function. It looks like they are using a mix between MSBuild and Dnx, but I don't think you have to.
When it comes to AppVeyor, I'd recommend using local scripts to do the building. The Microsoft team seem to be using Sake (C# build) to perform the building. Then, in their appveyor.yml, the simply call your own scripts.

Hope this helps: build scripts for "Class Library (Package)" project type (beta 8, yet):
Appveyor (Windows + MyGet auto-deploy)
https://github.com/fajro-net/FlexTimer/blob/b50b993f1573c338f4567bfaee659122218a63d2/appveyor.yml
https://github.com/fajro-net/FlexTimer/blob/b50b993f1573c338f4567bfaee659122218a63d2/build.cmd
Travis CI (Linux & OS X) - install DNX and run tests
https://github.com/fajro-net/FlexTimer/blob/b50b993f1573c338f4567bfaee659122218a63d2/.travis.yml
https://github.com/fajro-net/FlexTimer/blob/b50b993f1573c338f4567bfaee659122218a63d2/build.sh

Thanks guys!
I see that dnxcore is build with msbuild is build.ps1. That's the first step,  after that I try dnxbuild

hey @phenixdotnet!
I saw your fork. I cannot create an issue there to chat, but we can also do that here. :)

This may help you guys with the building.

Hi.
I totally missed this discussion, I hope we don't have duplicated effort on porting NLog to dnx.
Regarding CI system I use VSTS successfully with dnx build / dnu restore to build, test and pack libraries. The appveyor scripts provided by dmitry-ra looks good we can use a start point.
I will try to take time to play with appveyor and travis on my branch.
On the lib it self, the UAP 10 version is a good start for dnx version. We can reuse the NETFX_CORE const to isolate code which doesn't build on corecrl target.
An other point is would we want to maintains one solution per target or can we move all target to xproj / json system ? I don't know if Xamarin have any plan to support the new format but if yes it could be very interesting  to have only one solution and project to maintains.
Regards

I don't know if Xamarin have any plan to support the new format but if yes it could be very interesting to have only one solution and project to maintains.

Doesn't Xamarin support PCLs? I though you can build a PCL and simply reference it in Xamarin? No need for additional compilation.

https://docs.xamarin.com/guides/cross-platform/application_fundamentals/pcl/

Portable Class Libraries allow you to write code and produce libraries that can be shared across mulitple platforms including Xamarin.iOS, Xamarin.Android and Windows Phone.

PCL has the preference for Xamarin, but adding more targets to PCL has a curse - you can do less (Lowest common denominator). So if it hurts the functionality of Xamarin port, then we should keep it as separate projects.
I have no experience with DNX. Is the xproj required? I think it's also an option to move the project files in separate folders and keep the old project files? (e.g. NLog.netfx35.sln, NLog.netfx40.sln, NLog.netfx35.csproj, NLog.netfx40.csproj etc)

The xproj it self doesn't have any benefit but allow you to remove the old csproj files and keep only the project.json to manage dependencies, package version, name, publish settings, etc, etc, etc.
The problem with the old projects files is just the cost to maintains it (including the setup for CI system for example)

good to know that the UAP10 branch wasn't in sync with the master (with Xamarin support)

I saw this when I synced my work based on the current master your branch ^^

Is it then one xproj file instead of multiple csproj files?

it's correct that https://github.com/phenixdotnet/NLog/tree/dnx isn't building yet (local, vs2015). It seems to miss some files? used "NLog.uwp10.sln"

I think I should use nlog.xproj instead of the sln.
Got NLog building successful. Can we use strong naming? Other wise, we have to change this:
#if UWP10

[assembly: InternalsVisibleTo("NLog.UnitTests")]

#else
[assembly: InternalsVisibleTo("NLog.UnitTests, PublicKey=0024000004800000940000000602000000240000525341310004000001000100ef8eab4fbdeb511eeb475e1659fe53f00ec1c1340700f1aa347bf3438455d71993b28b1efbed44c8d97a989e0cb6f01bcb5e78f0b055d311546f63de0a969e04cf04450f43834db9f909e566545a67e42822036860075a1576e90e1c43d43e023a24c22a427f85592ae56cac26f13b7ec2625cbc01f9490d60f16cfbb1bc34d9")]
#endif

in AssemblyInfo.cs

With
[assembly: InternalsVisibleTo("NLog.UnitTests")]

only 32 errors in the unit test project:

Assert.ThrowsDelegate + Assert.DoesNotThrow . This should be removed with xUnit2
AppSettingTests + MessageQueueTargetTests should be removed for DNX . I think whole NLog.Extended should be not in DNX? Maybe we have to move those unit tests to another project.

@phenixdotnet  if you can add me as collaborator, I can push some fixes regarding the unit tests

@304NotModified Yes only one xproj instead of multiple csproj and sln files
normally we can use strong names but when I tried it I didn't get it working with unit tests.
Yes the merge is ugly I started work on the NLog master before merging your UAP branch and the result is .... strange. IMO, for real work we have to finish the work on UAP, use NETFX_CORE const instead UAP and move to DNX.
I added you as a collaborator on my repo.

So the best steps are:

rename UAP to NETFX_CORE in UAP branch
merge with nlog/master
move to CoreCLR?

So we should work in NLog/UAP for now?

We can just update the uap branch to master and rename the uap to netfx_core. This will serve as the base for my work on dnx and we can continue to work on both version.
Or we can move the uap branch to xproj and project.json and deliver the both version at the same time. And I could help you with the uap version if needed.
It's as you want :)

We can just update the uap branch to master and rename the uap to netfx_core.

no merge with nlog/master first?

And I could help you with the uap version if needed.

That would be great.

you can do less (Lowest common denominator). So if it hurts the functionality of Xamarin port, then we should keep it as separate projects.

That's why we have #if DEFINED ;)

That's why we have #if DEFINED ;)

But don't we need different projects files (for each platform) then?  Sorry, I try to get into the new stuff, but the documentation is really unclear and the rename also won't help.
We are very well known with #if at NLog.

Your project.json file should look as follows.
{
  "frameworks": {
    "net35": {}
  },
  "frameworks": {
    "net40": {}
  },
  "frameworks": {
    "net45": {}
  },
  "frameworks": {
    ".NETPortable,Version=v4.0,Profile=Profile328": {}
  },
  "runtimes": {
    "win-anycpu": {}
  }
}

Within the single project file, you can managed each framework, and the dependencies required for each framework. Then, when you dnu pack the project, you will get a single tidy nuget package with all the frameworks and dependencies embedded inside correctly.

Take a look at this.
{
  "version": "0.1-alpha-*",
  "compilationOptions": {
    "warningsAsErrors": true
  },
  "dependencies": {
    "Microsoft.Bcl.Immutable": "1.1.18-beta-*",
    "Microsoft.AspNet.ConfigurationModel": "0.1-alpha-*",
    "Microsoft.AspNet.DependencyInjection": "0.1-alpha-*",
    "Microsoft.AspNet.Logging": "0.1-alpha-*",
    "System.Data.Common": "0.1-alpha-*"
  },
  "code": ["**/*.cs", "/Shared/*.cs"],
  "frameworks": {
    "dnx451": {
      "frameworkAssemblies": {
        "System.Runtime": "",
        "System.Collections": ""
      }
    },
    "dnxcore50": {
      "dependencies": {
        "System.Collections": "<IP_ADDRESS>",
        "System.Collections.Concurrent": "<IP_ADDRESS>",
        "System.ComponentModel": "<IP_ADDRESS>",
        "System.Console": "<IP_ADDRESS>",
        "System.Diagnostics.Contracts": "<IP_ADDRESS>",
        "System.Diagnostics.Debug": "<IP_ADDRESS>",
        "System.Globalization": "<IP_ADDRESS>",
        "System.Linq": "<IP_ADDRESS>",
        "System.Linq.Expressions": "<IP_ADDRESS>",
        "System.Linq.Queryable": "<IP_ADDRESS>",
        "System.Reflection": "<IP_ADDRESS>",
        "System.Reflection.Extensions": "<IP_ADDRESS>",
        "System.Resources.ResourceManager": "<IP_ADDRESS>",
        "System.Runtime": "<IP_ADDRESS>",
        "System.Runtime.Extensions": "<IP_ADDRESS>",
        "System.Threading": "<IP_ADDRESS>",
        "System.Threading.Tasks": "<IP_ADDRESS>"
      }
    }
  }
}

Yes @theonlylawislove is right.
This is what I did on my fork, you can have a look at this file: https://github.com/phenixdotnet/NLog/blob/dnx/src/NLog/project.json.
.NET 4.5.1, .NET 4.6, UAP and coreclr are build from the same file

@phenixdotnet
What I did:

merged UWP with the master (was more work then expected)
[PR'd] https://github.com/NLog/NLog/pull/1077 and merged to branch UWP
Created a CoreCLR branch out of UWP branch

I didn't do the rename of the conditionals, but be my guest. So I propose to work futher on the coreCLR branch :) Can you take it from here?
NB: not all the tests / functionality is working in UWP. See  https://github.com/NLog/NLog/pull/1077

@304NotModified
thanks you, looks like a very good start to work on coreclr :)
To do list is:

[ ] Setup an appveyor build on coreclr banch
[ ] Fix missing functionnalities is possible and if make sense
[ ] Fix unit tests
[ ] Publish :)

Hum, there is a coreCLR and a coreclr branch, not sure why.
I will start work on coreCLR branch may be we can remove the coreclr.

I think the lowercase is the updated one. If we check that, I remove the other.
What is needed for appveyor?

We just need to adapt build script to ensure coreCLR is build with dnx / dnu tools.
I have those scripts, I just need to test it and integrate it.

We just need to adapt build script to ensure coreCLR is build with dnx / dnu tools.
I have those scripts, I just need to test it and integrate it.

Sounds good.

I will start work on coreCLR branch may be we can remove the coreclr.

I saw you have committed on coreCLR , so I have removed the coreclr branch. (the coreclr had some changes commited to UWP branch, but those aren't needed now I guess)

I saw you have committed on coreCLR , so I have removed the coreclr branch - otherwise it will be al confusing. (the coreclr had some changes commited to UWP branch, but those aren't needed now I guess)

Oups, sorry for that :(

NP! :)

@phenixdotnet
I see you have added a project.json, but that doens't work well with NLog.sl4.csproj etc. (see AppVeyor log)
In the UWP branch I used "NLog.uwp10.project.json". Can't we use that? Or are we converting every csproj?

Too bad :(
I will have a look at this right after I fix my appveyor build.

In the UWP branch I used "NLog.uwp10.project.json". Can't we use that? Or are we converting every csproj?

Yes I saw it but dnx and the new projects system mostly expect a project.json file. What I don't understand is why a project.json is handle by the SL project file.
Those errors are only on the coreclr branch no ? We can take time to investigate and fix it properly no ?

Yes I saw it but dnx and the new projects system mostly expect a project.json file. What I don't understand is why a project.json is handle by the SL project file.

this has to do that msbuild uses both packages.config and project.json AFAIK. There are 3 solutions:

move to different folders
migrate all projects to .json
rename "project.json" to "..project.json". This is what I did for UWP and that worked very well. I prefer this one.

@304NotModified finally this error isn't related to project.json files but to a changes I done in assembly signing for test. I fixed it and it should be ok now. Let me know if not :)

Did you pushed it? You can see the build status here: https://ci.appveyor.com/project/nlog/nlog/history (see label "coreCLR" for this branch)

I get this locally: (NLog.sl4.sln)

Interesting, I will have a look at this later this day.
I think we should really keep the default project.json file name.
If I can't get SL build with this we will move to your solution (IE Rename it) but I think it will be better if we can keep on proj and project;json for all targets.
Thanks for your help !

@phenixdotnet FYI,
the error (AppVeyor)
error CS1726: Friend assembly reference 'NLog.UnitTests'
 is invalid. Strong-name signed assemblies must specify a
 public key in their InternalsVisibleTo declarations.

For strong named assemblies we need (assemblyinfo.cs)
[assembly: InternalsVisibleTo("NLog.UnitTests, PublicKey=0024000004800000940000000602000000240000525341310004000001000100ef8eab4fbdeb511eeb475e1659fe53f00ec1c1340700f1aa347bf3438455d71993b28b1efbed44c8d97a989e0cb6f01bcb5e78f0b055d311546f63de0a969e04cf04450f43834db9f909e566545a67e42822036860075a1576e90e1c43d43e023a24c22a427f85592ae56cac26f13b7ec2625cbc01f9490d60f16cfbb1bc34d9")]

and for non-strong named:
[assembly: InternalsVisibleTo("NLog.UnitTests")]

@304NotModified Yes I'm aware about this :)
I missed some consts and the results is this signing errors.
I'm playing with different approaches for the dnx branch so don't be worry about appveyor for the moment, I will fix the build ASAP but I need time to explore the different options.

OK thanks for the update!

Need some help @phenixdotnet?

@304NotModified need time ^^
More seriously, I'm trying to fix units tests but we have to deal with the restrictions on coreclr platforme like for the UWP.

Ok, I have the same unit tests in error than in the UWP branch.
Look like a good point to start working on fix, if possible :)

Are you running xunit 1 or 2?

xunit 2.1.0 (see http://xunit.github.io/docs/getting-started-dnx.html for support matrix)

Thanks! I have updated my post already :)

@304NotModified About MDC, and the CallSite, I'm working on this but the new platform have some limitation. I took a look at the ApplicationInsight code and even MS is disabling the stack trace collect when running on dnx (See https://github.com/Microsoft/ApplicationInsights-dotnet/blob/master/src/Core/Managed/Shared/Extensibility/Implementation/ExceptionConverter.cs for example)

Yeah the stacktrace is also pity, but it's not essential (only highly desirable).
The same for the MDC. We can built a MDLC with (which is maybe even better then the MDC) in UWP: https://msdn.microsoft.com/en-us/library/windows/desktop/ms686749(v=vs.85).aspx. It that also possible for CoreCLR? Then we can alter the unit tests from MDC -> MDLC

I got MDC and NDC working (unit tests ok), both on coreclr and UWP, thanks to package System.Threading.Thread :)
I'm using the same code than the silverlight version (AKA TLS_WORKAROUND), is it ok ?

Great! Sounds good to me!

Yeah, next step is having the stacktrace working correctly.

We can use Environment.StackTrace? (think we used it also in Silverlight)

Good question !
I will test that tomorrow :)

PS: Can't find  Environment.StackTrace usage, but can find ParseMethodNameFromStackTrace(string stackTrace) (ExceptionLayoutRenderer)

Yep but the problem is how to get the stacktrace string.
The StackTrace object is just empty

Environment.StackTrace is empty?

Sorry, no, the StackTrace object instancied like this new StackTrace(new Exception(), bool) always return an empty stacktrace.

I got the CallSiteTests ok, but I'm not happy with the code I used.
To got stack trace I'm using reflection to create an instance of StackTrace class using the default constructor. This is working on coreclr on windows. I'm testing it on mac os x.

var stackTraceCtor = typeof(StackTrace).GetConstructor(new Type[] { typeof(bool) });
stackTrace = (StackTrace)stackTraceCtor.Invoke(new object[] { stu == StackTraceUsage.WithSource });

What I don't understand is why there is a diff between the StackTrace implementation in CoreCLR framework (https://github.com/dotnet/coreclr/blob/master/src/mscorlib/src/System/Environment.cs) and the core fx (https://github.com/dotnet/corefx/blob/master/src/System.Diagnostics.StackTrace/ref/System.Diagnostics.StackTrace.cs).
And @304NotModified you're right, Environment.StackTrace has the stack trace but I'm really not happy with string parsing.
I just found your comment on corefx Issues (https://github.com/dotnet/corefx/issues/1797) ;).
I will try to make a PR with the default constructor implemented.

And @304NotModified you're right, Environment.StackTrace has the stack trace but I'm really not happy with string parsing.

Well it's better then nothing. But Indeed the reflection idea is a better idea.
Can list the steps we need to do like github checkboxes?
e.g.

[ ] Fix .Net buids
[ ] Fix stacktrace

And can you tell us in which things we can helo?

Hi.
I'm waiting for someone on coreclr to check if we can get the default ctor of StackTrace back.
The task list is:

[ ] Fix the StackTrace in a better way than using reflection
[ ] Fix the build under unix-like systems -> phenixdotnet
[ ] Test the lib on all platform. The build procuce an assembly for each frameworks in this list: .NET 3.5.1, .NET 4.5.1, .NET Core 5, UAP 10, Silverlight 5.
[ ] Check if it's possible to build the Xamarin Android and Xamarin iOS version from project.json and test the lib.
[ ] Update doc

I'm working on build and stacktrace, you can take any of the other task if you want and any idea and help on the StackTrace subject is welcome :)

I'm waiting for someone on coreclr to check if we can get the default ctor of StackTrace back.

There is a big change that will take some time, isn't it?
I think it would be great that we can work on the other steps, and I we are done with it, we can see if the stacktrace thing is (getting) fixed. The stacktrace isn't a breaking IMO.

@phenixdotnet can we help one something?

@304NotModified yes sure !
We can start working on "est the lib on all platform. The build procuce an assembly for each frameworks in this list: .NET 3.5.1, .NET 4.5.1, .NET Core 5, UAP 10, Silverlight 5."
It's just about creating sample project and use the lib produced by the coreCLR branch.

Hi @phenixdotnet ,
Do you mean with test, unit test? On which platforms we can run the unit test now (successfully)?

@304NotModified : Nop I mean sample/test app.
Currently the lib pass the unit tests on .NET 4.5 and coreclr 5.0.
My idea with the sample/test apps is to test the output lib in "real", not coreclr, "old" project types.
I hope to have some time next week to move forward on this.

I think it's more important to have the unit tests working. The unit tests should pass for Xamarin (AppVeyor), .Net 3.5 (AppVeyor), .Net 4(AppVeyor), .Net  4.5(AppVeyor), and UWP (only local)

Finally I can get Nlog building on Windows & unix using the same system.
On Windows we build the .NET 3.5, .NET 4.5.1, DNXCore 5, SL5 and UWP 10 version of NLog
On Unix we build the .NET 4.5.1 and DNXCore 5 version. I will add the Android & iOS version soon.
Unit tests are OK on .NET 4.5.1 under Windows (One error on build under linux) but fails for DNXCore 5 (NLog.UnitTests  Total: 625, Errors: 0, Failed: 9, Skipped: 1, Time: 57,192s). Most of errors are related to autoreload tests.
You can test this by executing the build.cmd (or build.sh on linux/mac) in the coreCLR branch

Thanks for the update @phenixdotnet !

@phenixdotnet @304NotModified
You are doing great here!
I have downloaded the CoreClr branch. I couldn't finy any CoreClr related project.json file.
I ran  build.cmd and had some exeptions about parameters during the process. Is there any place I could find the nuget package ?

Hi,
There is no nuget package yet.

This is what I get when I run build.cmd:
Executing task: Dnxcore50
dnvm-exec: A parameter cannot be found that matches parameter name 'r'.
At C:\Users\Onur.dnx\bin\dnvm.ps1:1453 char:27

       & "dnvm-$cmd" @cmdargs

CategoryInfo     : Invalid Argument: (:) [dnvm-exec], ParentContains ErrorRecordException

FullyQualifiedErrorId : NamedParameterNotFound, dnvm-exec

dnvm-exec: A parameter cannot be found that matches parameter name 'r'.
At C:\Users\Onur.dnx\bin\dnvm.ps1:1453 char:27

       & "dnvm-$cmd" @cmdargs

CategoryInfo     : Invalid Argument: (:) [dnvm-exec], ParentContains ErrorRecordException

FullyQualifiedErrorId : NamedParameterNotFound, dnvm-exec

dnvm-exec: A parameter cannot be found that matches parameter name 'r'.
At C:\Users\Onur.dnx\bin\dnvm.ps1:1453 char:27

       & "dnvm-$cmd" @cmdargs

CategoryInfo     : Invalid Argument: (:) [dnvm-exec], ParentContains ErrorRecordException

FullyQualifiedErrorId : NamedParameterNotFound, dnvm-exec

I've just tried running it on Linux, and I get:
dans@dump ~/p/p/nlog.git (coreCLR)> ./build.sh
Using installed dnvm.sh script
dnx-coreclr-linux-x<IP_ADDRESS>-rc1-update1 already installed in /home/dans/.dnx
Adding /home/dans/.dnx/runtimes/dnx-coreclr-linux-x<IP_ADDRESS>-rc1-update1/bin to process PATH
dnx-mono.1.0.0-rc1-update1 already installed in /home/dans/.dnx
Adding /home/dans/.dnx/runtimes/dnx-mono.1.0.0-rc1-update1/bin to process PATH
Updating alias 'default' to 'dnx-mono.1.0.0-rc1-update1'
Adding /home/dans/.dnx/runtimes/dnx-mono.1.0.0-rc1-update1/bin to process PATH
Downloading Cake bootstrap script
Running cake
Analyzing build script...
Processing build script...
Could not load /home/dans/projects/public/nlog.git/tools/Cake/Cake.exe (missing NuGet.Core, Version=2.8.60717.93, Culture=neutral, PublicKeyToken=31bf3856ad364e35)
Compiling build script...

========================================
Clean
========================================
Executing task: Clean
Cleaning directory /home/dans/projects/public/nlog.git/artifacts
Cleaning directory /home/dans/projects/public/nlog.git/samples
Finished executing task: Clean

========================================
Dnxcore50
========================================
Executing task: Dnxcore50
An error occured when executing task 'Dnxcore50'.

========================================
Dnx451
========================================
Executing task: Dnx451
An error occured when executing task 'Dnx451'.

========================================
net35
========================================
Executing task: net35
An error occured when executing task 'net35'.

========================================
sl5
========================================
Executing task: sl5
An error occured when executing task 'sl5'.

========================================
uap10
========================================
Executing task: uap10
An error occured when executing task 'uap10'.

========================================
Default
========================================
Executing task: Default
Finished executing task: Default

Task                          Duration
--------------------------------------------------
Clean                         00:00:00.0044357
Dnxcore50                     00:00:00.1215780
Dnx451                        00:00:00.0624572
net35                         00:00:00.0611426
sl5                           00:00:00.0598565
uap10                         00:00:00.0613142
Default                       00:00:00.0003215
--------------------------------------------------
Total:                        00:00:00.3711057

I have seen the build commands in build.cake file.
According to this file, the build directory is:
NLog-coreCLR\src\NLog
The runtime is:
1.0.0 coreclr rc1-update1
I opened a Windows terminal and changed my directory to NLog-coreCLR\src\NLog
I changed my dnvm runtime as 1.0.0 coreclr rc1-update1
after dnu restore and dnu build, it built without errors.

Hi.
Strange I will try to reproduce your issue and let you known.
The build.cmd should work but may be I broke it when I work on lunux built.

@sirentek: Looks like you don t have UWP 10 support installed. Could you confirm pls ?
@damageboy: Could you confirm you have the dnvmwrapper.sh script in the tools dir and it's executable ?
@304NotModified: Nop I don't think we are ready for an alpha. I which to have time to work on the config load for the coreclr version. Today it's look like the Nlog.config isn't automatically found and loaded.

@phenixdotnet You are right. My Visual Studio installation doesn't include UWP components.

@phenixdotnet I have no dnvmwrapper.sh anywhere:
dans@dump ~/p/p/nlog.git (coreCLR)> find . -name dnvmwrapper.sh

returns nada

@phenixdotnet
I have opened DnxCore50SimpleConsoleApp project from Visual Studio.
I had NLog built using visual studio.
I had the simple application built using visual studio.
It successfully worked for me. I modified the NLog.config file and it seems it is working too.
I will try it from Linux also..

@damageboy
It worked for me on Linux too. (I use Linux Mint 17.2 Mate)
I modified NLog.config file and it worked as expected.
I created the nuget file from my Windows machine using console:
Go to this directory >>> NLog-coreCLR\src\NLog
Set runtime as >>>>> 1.0.0 coreclr rc1-update1
Run "dnu restore" "dnu build" "dnu pack"
It creates NLog.5.0.0.nupkg file under NLog-coreCLR\src\NLog\bin\Debug directory.
(Errors are not coreclr related.)
Copy this file from Windows to the linux machine.
I copied it to the  /home/onur/.dnx/local_packages
Change the NuGet.Config file in linux as:

Add this line to the project.json file :
"NLog":"5.0.0"
Now you can build the project in linux using "dnu restore" "dnu build".
It should work.
@phenixdotnet
Thank you much
Very appreciated!

@damageboy Just check my git status and I found I forgot to push changes ... It's should be ok now.
@sirentek I just ran the build script on Windows. On my machine its working if you rename the dnvmwrapper.sh and run the command build.cmd -Configuration Debug (Bug introduced by changes made to get it working on linux ^^). If it still doesn't work can you give me your windows version and dnvm version pls ?
To use the build script on Linux you should run build.sh --configuration Debug
Actually the build script doesn't create a nuget package, I will work on that and on the Windows issue ASAP.
Can somebody try to use NLog in an ASP.NET 5 and check if config is correctly loaded ?
Thanks !

@phenixdotnet
Windows:
I don't have dnvmwrapper.sh file in my source directory. Do you mention renaming it to something like dnvmwrapper.sh.Bak ?
Linux:
If I use "build.sh --configuration Debug"  I get the same result as @damageboy.
The file has executable right.
AspNet Project:
I will try it.
As I know NLog doesn't have log provider for asp.net mvc 6. So I plan to write my own.
If it works I can share it.

Done it. I have implemented NLog to an AspNet MVC 6 Sample application. Config was correctly loaded. This is the output:
20160109225059 Received request: GET / HTTP/1.1; Headers: { Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,/;q=0.8; Accept-Encoding: gzip, deflate, sdch; Accept-Language: en-US,en;q=0.8; Cache-Control: max-age=0; Connection: keep-alive; Host: localhost:5000; User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.106 Safari/537.36; Upgrade-Insecure-Requests: 1; } SirenTek.Logging.NLogAdapter.Log
20160109225059 Request starting HTTP/1.1 GET http://localhost:5000/   SirenTek.Logging.NLogAdapter.Log
20160109225059 The request path / does not match a supported file type SirenTek.Logging.NLogAdapter.Log
20160109225059 Request successfully matched the route with name 'default' and template '{controller=Home}/{action=Index}/{id?}'. SirenTek.Logging.NLogAdapter.Log
20160109225059 Executing action SirenTek.Controllers.HomeController.Index SirenTek.Logging.NLogAdapter.Log
20160109225059 Executing action method SirenTek.Controllers.HomeController.Index with arguments () - ModelState is Valid' SirenTek.Logging.NLogAdapter.Log
20160109225059 Index action requested at 01/09/2016 22:50:59 SirenTek.Logging.NLogAdapter.Log
20160109225059 Index action requested! SirenTek.Logging.NLogAdapter.Log
20160109225059 Executed action method SirenTek.Controllers.HomeController.Index, returned result Microsoft.AspNet.Mvc.ViewResult.' SirenTek.Logging.NLogAdapter.Log
20160109225101 The view 'Index' was found. SirenTek.Logging.NLogAdapter.Log
20160109225101 Executing ViewResult, running view at path /Views/Home/Index.cshtml.  But if you can't find the dnvmwrapper.sh script it's because you didn't pull the latest source. Please could run a git pull and confirm you get the dnvmwrapper.sh script in tools dir ? And can you share your dnvm version please ? (dnvm version)
Regarding the mvc6 provider,Nlog don't have it but Microsoft yes. You can have a look at Microsoft.Extensions.Logging.NLog package. Anyway your provider is simpler to configure than the MS one.

I pulled last version to my desktop on windows. Renamed dnvmwrapper.sh.
My dnvm version was 1.0.0 coreclr rc1-update1
I ran build.cmd with with debug parameters. Here is the output:
C:\Users\Onur\Desktop\NLogWinTest\NLog-coreCLR>build.cmd -Configuration Debug
Using temporary directory: C:\Users\Onur\AppData\Local\Temp\dnvminstall
Downloading DNVM.ps1 to C:\Users\Onur\AppData\Local\Temp\dnvminstall\dnvm.ps1
Downloading DNVM.cmd to C:\Users\Onur\AppData\Local\Temp\dnvminstall\dnvm.cmd
Installing DNVM
Installing .NET Version Manager to C:\Users\Onur.dnx\bin
Installing 'dnvm.ps1' to 'C:\Users\Onur.dnx\bin' ...
Skipping: file already exists
Installing 'dnvm.cmd' to 'C:\Users\Onur.dnx\bin' ...
Skipping: file already exists
Adding C:\Users\Onur.dnx\bin to Process PATH
Adding C:\Users\Onur.dnx\bin to User PATH
'dnx-clr-win-x<IP_ADDRESS>-rc1-update1' is already installed.
Adding C:\Users\Onur.dnx\runtimes\dnx-clr-win-x<IP_ADDRESS>-rc1-update1\bin to proc
ess PATH
Updating alias 'default' to 'dnx-clr-win-x<IP_ADDRESS>-rc1-update1'
'dnx-coreclr-win-x<IP_ADDRESS>-rc1-update1' is already installed.
Adding C:\Users\Onur.dnx\runtimes\dnx-coreclr-win-x<IP_ADDRESS>-rc1-update1\bin to
process PATH
'dnx-coreclr-win-x<IP_ADDRESS>-rc1-update1' is already installed.
Adding C:\Users\Onur.dnx\runtimes\dnx-coreclr-win-x<IP_ADDRESS>-rc1-update1\bin to
process PATH
Preparing to run build script...
Running build script...
Analyzing build script...
Processing build script...
Error: Could not load file or assembly 'file:///C:\Users\Onur\Desktop\NLogWinTes
t\NLog-coreCLR\tools\Cake\Cake.Common.dll' or one of its dependencies. Operation
is not supported. (Exception from HRESULT: 0x80131515)

This is the result of Linux machine:
Dnxcore50
Executing task: Dnxcore50
Microsoft .NET Development Utility CoreClr-x64-1.0.0-rc1-16231
CACHE https://api.nuget.org/v3/index.json
CACHE https://www.myget.org/F/dotnet-core/api/v3/index.json
Restoring packages for /home/websiren/Desktop/SIRENTEK/SirenTekLog/NLog-coreCLR/examples/UAP10SimpleApp/project.json
Unable to locate Dependency NLog
Writing lock file /home/websiren/Desktop/SIRENTEK/SirenTekLog/NLog-coreCLR/examples/UAP10SimpleApp/project.lock.json
Restore complete, 14245ms elapsed
Restoring packages for /home/websiren/Desktop/SIRENTEK/SirenTekLog/NLog-coreCLR/examples/DnxCore50SimpleConsoleApp/project.json
CACHE https://api.nuget.org/v3-flatcontainer/microsoft.csharp/index.json
GET https://www.myget.org/F/dotnet-core/api/v3/flatcontainer/microsoft.csharp/index.json
CACHE https://api.nuget.org/v3-flatcontainer/system.collections/index.json
GET https://www.myget.org/F/dotnet-core/api/v3/flatcontainer/system.collections/index.json
CACHE https://api.nuget.org/v3-flatcontainer/system.console/index.json
CACHE https://www.myget.org/F/dotnet-core/api/v3/flatcontainer/system.console/index.json
CACHE https://api.nuget.org/v3-flatcontainer/system.linq/index.json
CACHE https://www.myget.org/F/dotnet-core/api/v3/flatcontainer/system.linq/index.json
CACHE https://api.nuget.org/v3-flatcontainer/system.threading/index.json
GET https://www.myget.org/F/dotnet-core/api/v3/flatcontainer/system.threading/index.json
OK https://www.myget.org/F/dotnet-core/api/v3/flatcontainer/system.collections/index.json 1777ms
Warning: FindPackagesById: Microsoft.CSharp
HTTP request timed out. Retrying.
Warning: FindPackagesById: System.Threading
HTTP request timed out. Retrying.
GET https://www.myget.org/F/dotnet-core/api/v3/flatcontainer/microsoft.csharp/index.json
GET https://www.myget.org/F/dotnet-core/api/v3/flatcontainer/system.threading/index.json
OK https://www.myget.org/F/dotnet-core/api/v3/flatcontainer/microsoft.csharp/index.json 2207ms
Warning: FindPackagesById: System.Threading
HTTP request timed out. Retrying.
GET https://www.myget.org/F/dotnet-core/api/v3/flatcontainer/system.threading/index.json
OK https://www.myget.org/F/dotnet-core/api/v3/flatcontainer/system.threading/index.json 308ms
Unable to locate Dependency NLog
Writing lock file /home/websiren/Desktop/SIRENTEK/SirenTekLog/NLog-coreCLR/examples/DnxCore50SimpleConsoleApp/project.lock.json
Restore complete, 205311ms elapsed
Restoring packages for /home/websiren/Desktop/SIRENTEK/SirenTekLog/NLog-coreCLR/src/NLogAutoLoadExtension/project.json
CACHE https://api.nuget.org/v3-flatcontainer/system.diagnostics.contracts/index.json
GET https://www.myget.org/F/dotnet-core/api/v3/flatcontainer/system.diagnostics.contracts/index.json
CACHE https://api.nuget.org/v3-flatcontainer/system.diagnostics.stacktrace/index.json
CACHE https://www.myget.org/F/dotnet-core/api/v3/flatcontainer/system.diagnostics.stacktrace/index.json
CACHE https://api.nuget.org/v3-flatcontainer/system.diagnostics.tools/index.json
GET https://www.myget.org/F/dotnet-core/api/v3/flatcontainer/system.diagnostics.tools/index.json
CACHE https://api.nuget.org/v3-flatcontainer/system.diagnostics.tracesource/index.json
CACHE https://www.myget.org/F/dotnet-core/api/v3/flatcontainer/system.diagnostics.tracesource/index.json
CACHE https://api.nuget.org/v3-flatcontainer/system.runtime.serialization.primitives/index.json
CACHE https://www.myget.org/F/dotnet-core/api/v3/flatcontainer/system.runtime.serialization.primitives/index.json
CACHE https://api.nuget.org/v3-flatcontainer/system.xml.xmldocument/index.json
CACHE https://www.myget.org/F/dotnet-core/api/v3/flatcontainer/system.xml.xmldocument/index.json
OK https://www.myget.org/F/dotnet-core/api/v3/flatcontainer/system.diagnostics.contracts/index.json 1867ms
CACHE https://api.nuget.org/v3-flatcontainer/system.componentmodel.typeconverter/index.json
GET https://www.myget.org/F/dotnet-core/api/v3/flatcontainer/system.componentmodel.typeconverter/index.json
CACHE https://api.nuget.org/v3-flatcontainer/system.data.common/index.json
CACHE https://www.myget.org/F/dotnet-core/api/v3/flatcontainer/system.data.common/index.json
CACHE https://api.nuget.org/v3-flatcontainer/system.threading.threadpool/index.json
CACHE https://www.myget.org/F/dotnet-core/api/v3/flatcontainer/system.threading.threadpool/index.json
CACHE https://api.nuget.org/v3-flatcontainer/system.threading.thread/index.json
CACHE https://www.myget.org/F/dotnet-core/api/v3/flatcontainer/system.threading.thread/index.json
CACHE https://api.nuget.org/v3-flatcontainer/system.io.compression/index.json
CACHE https://www.myget.org/F/dotnet-core/api/v3/flatcontainer/system.io.compression/index.json
CACHE https://api.nuget.org/v3-flatcontainer/microsoft.extensions.platformabstractions/index.json
GET https://www.myget.org/F/dotnet-core/api/v3/flatcontainer/microsoft.extensions.platformabstractions/index.json
OK https://www.myget.org/F/dotnet-core/api/v3/flatcontainer/system.componentmodel.typeconverter/index.json 519ms
NotFound https://www.myget.org/F/dotnet-core/api/v3/flatcontainer/microsoft.extensions.platformabstractions/index.json 804ms
Warning: FindPackagesById: System.Diagnostics.Tools
HTTP request timed out. Retrying.

Same issues as @sirentek

@damageboy, @sirentek
I rework the build scripts and it should run on Windows at last.
Could you re-test it please ?
build.cmd -Configuration Debug
This should build NLog for .NET 3.5, .NET 4.5.1, SL5, UAP10.0 and DnxCore 5.0
The nuget package should be in ./nuget dir
The version is 4.4.0-alpha1
Thanks !

I have failing unit tests. is that expected?

In dnxcore50 target ? Yes ^^

@phenixdotnet what's the assembly version? I can't check in nugetPackageExplorer (crash)

@304NotModified : <IP_ADDRESS>. Nuget package version is 4.4.0-alpha1
I didn't integrate the appveyor build number in project.json (for the moment).
Do you have the same crash in nuget explorer with other nuget package built for the dnxcore framework ?

@304NotModified : <IP_ADDRESS>. Nuget package version is 4.4.0-alpha1
I didn't integrate the appveyor build number in project.json (for the moment).

No problem that it not integrated with the appveyor build number. But to upload in to nuget.org, the versions should be OK, otherwise people could get upgrade issues or assembly bind issues.
The versions should be:

assembly version (can be checked in nugetPackageExplorer normally): <IP_ADDRESS> (also not 4.0 or 4.0.0). This is really important, otherwise every library build on NLog 4.x would release a new version, OR uses should use <assemblybindings>. This has to do with strong naming.
(assembly) file version: 4.4.x (x not important for now, I used the build number of AppVeyor).  Visible in Windows (properties of .dll)
Product version: not that important. Preferred: 4.4-alpha1 . Visible in Windows (properties of .dll)

fullname should be (contains the assembly version.
.

Do you have the same crash in nuget explorer with other nuget package built for the dnxcore framework ?

Do you have an example of a package?

@304NotModified : ok I will do that by the end of week and after that we can push an pre-alpha-unsupported version to nuget :)
You can find nuget packages in your profil folder -> .dnx -> packages
%USERPROFILE%\.dnx\packages
You can have a look at Microsoft.Extensions.Configuration.Abstractions.

I noticed two times
Building NLog.UnitTests for DNX,Version=v4.5.1

Is that correct?

Yes.
.NET 3.5 use unit test lib build on .NET 4.5.1. It's the same in the NLog.3.5.sln solution.

You can find nuget packages in your profil folder -> .dnx -> packages
You can have a look at Microsoft.Extensions.Configuration.Ab

Thanks, that one works:

With NLog.4.4.0-alpha1.nupkg I get (don't get it). Any idea where this issue could be?

@304NotModified : Nop. I know MS is moving to other framework names with the dotnet cli and dnx rc2 coming soon, I will update framework names and test it again. I will check the dependencies too

@phenixdotnet
Can you tell me something about the current progress in build.sh / build.cmd / build.ps1 / build.cake? (I never used CAKE but did read the tutorial)

I assume that it works like this:
build.cmd  uses build.ps1 and build.ps1 uses build.cake.
build.sh uses build.cake.

is this correct? Why do we need a .cmd beside a .ps1?
Also I'm curious about the current build process. I will also tell have to tell how it works now in the master (not that it should be like that, but could be handy).
I assume:

build is done by Cake
Someone patches the assembly version? Cake?
Binaries are written to artifacts\debug \  artifacts\release
NuGet packages are  build from the artifacts and src\NuGet\NLog\NLog.nuspec. Nuget packages are written to nuget\

Is this correct?
FYI: the current process now for this repository before CoreCLR (not advised to keep it like this ;))

Call MSbuild with version numbers.
Assemblies are patched by MSbuild
Binaries are written to build\bin\debug \  build\bin\release
NuGet packages are  build from the binaries and src\NuGet\NLog\NLog.nuspec. Nuget packages are written to build\bin\release\NuGetPackages \ build\bin\debug\NuGetPackages

@304NotModified : You're rights about build process except one thing. The nuget packages are created by dnu pack command which rebuild the source and create the nuget package (and patch the assembly version).
We have to keep build and test steps to ensure we are running unit tests for each platform.
The build.cmd is required to bootstrap dnx env and download the initial build.ps1 (buildcake.sh under linux) and then run the build.ps1 script to start cake. It's a little complicated but this allow us to not customize the build script from cake team.
There is some work to be done before to have a production build pipeline but its a great POC :)
Additionally, as I read, with RC2 the dnx,dnvm, dnu commands will be deprecated so we will have to rewrite the tooling to use the dotnet cli.

Additionally, as I read, with RC2 the dnx,dnvm, dnu commands will be deprecated so we will have to rewrite the tooling to use the dotnet cli.

There are really moving in the last steps!

I have fixed the assembly version and pushed the first alpha: https://www.nuget.org/packages/NLog/4.4.0-alpha1

Thanks !

Can we get support for dotnet5.4 into the Nuget package?  https://github.com/aspnet/Announcements/issues/98

@akatz0813 : Yes sure ! And thanks for the doc, this is the info I was looking for :)

How to load NLOG configuration in Console App vNext? I have created NLog.config file in project folder and I've added a "content" param in project.json.
"content": [
"NLog.config"
],
... and Configuration property in new LogFactory is null. What I can do?

Hey @lukaszpyrzyk,
Any idea how to read the content (in C#) for this?

I can easily read this file using File Class
string file = File.ReadAllText("NLog.config");
or
byte[] file = File.ReadAllBytes("NLog.config");
or
FileStream file = File.OpenRead("NLog.config");
etc.
But how to cast this to the Configuration object and inject to each ILogger?

@lukasz-pyrzyk

But how to cast this to the Configuration object and inject to each ILogger?

You need something this
var reader = XmlTextReader.Create(streamToConfig); \\stream preferred above byte[] / string.
var config = new XmlLoggingConfiguration (reader, null); //filename is not required.
LogManager.Configuration = config;

related https://github.com/NLog/NLog/issues/1172

Can we get support for dotnet5.4 into the Nuget package? aspnet/Announcements#98

@phenixdotnet: I will create a new NuGet package when this is here.

@304NotModified, Thank you, it works.
"content": [
"NLog.config"
],

that was redundant

Could anyone, please, provide some deadline estimation for this? My team works on project on ASP.NET Core and we need NLog ASAP. It would be great to have an idea when to expect it.

Hi.
I'm sorry but I don't have any free time at the moment to work on the subject.
Additionally, MS has change the release date of the RC2 and the new tools chain to take time to work on new dotnet cli. We need it (that and xunit) to support new monikers.
You can try the 4.4.0 alpha 1 which provide support for "old" dnxcore50 and dnx451 monikers
Or you can use the coreCLR branch, I pushed some updates (merge from master and dotnet5.4/net451 support)

I think this needs 4-8 weeks. Too bad coreclr is really unstable.  A lot of changes are coming.  Don't get it why they call it rc.  It's more in alpha/beta stage.

You can of course boost it by helping us :)

PS, we have now also NLog.Framework.Logging on nuget for aspnet5 (ASP.NET core 1.0)
https://github.com/NLog/NLog.Framework.Logging

@304NotModified
Hi,
In AspNetExtensions.cs
in public static void ConfigureNLog(this IHostingEnvironment env, string configFileRelativePath) method, the following line should be replaced:
var fileName = Path.Combine(Directory.GetParent(env.WebRootPath).ToString(), configFileRelativePath);

with this one:
var fileName = (Path.Combine(Directory.GetParent(env.WebRootPath).FullName, configFileRelativePath), true);

Because when not using "FullName", it creates relative path. For example:
I have project on my desktop, under SirenWeb folder. I have the NLog.config file under SirenWeb.
When I call this method with "NLog.config" parameter
fileName variable will be equal to SirenWeb/NLog.config
After the fix, it will be equal to C:\users\onur\SirenWeb\NLog.config
By this way I had get it worked on both linux and windows environment.

@sirentek thanks! Can you send a PR for that?
Great to hear it's also working with Linux :)

@phenixdotnet
I don't get it all building and I don't get the errors. Can you help me with it?
I see the following errors
 Cannot find dnx-coreclr-win-x86.dnxcore50, do you need to run 'dnvm install dnxcore50'?
At C:\Program Files\Microsoft DNX\Dnvm\dnvm.ps1:1753 char:9
+         throw "Cannot find $($runtimeInfo.RuntimeName), do you need t ...
+         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OperationStopped: (Cannot find dnx...all dnxcore50'?:String) [], RuntimeException
    + FullyQualifiedErrorId : Cannot find dnx-coreclr-win-x86.dnxcore50, do you need to run 'dnvm install dnxcore50'?

Cannot find dnx-clr-win-x86.dnx451, do you need to run 'dnvm install dnx451'?
At C:\Program Files\Microsoft DNX\Dnvm\dnvm.ps1:1753 char:9
+         throw "Cannot find $($runtimeInfo.RuntimeName), do you need t ...
+         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OperationStopped: (Cannot find dnx...nstall dnx451'?:String) [], RuntimeException
    + FullyQualifiedErrorId : Cannot find dnx-clr-win-x86.dnx451, do you need to run 'dnvm install dnx451'?

Cannot find dnx-clr-win-x86.sl5, do you need to run 'dnvm install sl5'?
At C:\Program Files\Microsoft DNX\Dnvm\dnvm.ps1:1753 char:9
+         throw "Cannot find $($runtimeInfo.RuntimeName), do you need t ...
+         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OperationStopped: (Cannot find dnx...m install sl5'?:String) [], RuntimeException
    + FullyQualifiedErrorId : Cannot find dnx-clr-win-x86.sl5, do you need to run 'dnvm install sl5'?

Should I install something else?
And I see this error in .net 5.4
Building NLog for .NETPlatform,Version=v5.4
X:\Github-nlog-production\NLog\src\NLog\LayoutRenderers\BaseDirLayoutRenderer.cs(91,62): .NETPlatform,Version=v5.4 warning CS3001: Argument type 'IApplicationEnvironment' is not CLS-compliant

Any idea how to fix this?

I recently updated the build script to work with rc2, I guess I broke it.
I'm not at home at the moment, I will take a look at yours issues later this day.

OK thanks! :)

And I see this error in .net 5.4
Building NLog for .NETPlatform,Version=v5.4
X:\Github-nlog-production\NLog\src\NLog\LayoutRenderers\BaseDirLayoutRenderer.cs(91,62): > .NETPlatform,Version=v5.4 warning CS3001: Argument type 'IApplicationEnvironment' is not > CLS-compliant
Any idea how to fix this?

It's a warning no ? IApplicationEnvironment is a new system type, I'm not sure if we can do somethings

I just commit a set of updates. The lib should build, but the unit tests doesn't run. I don't known why at this time, I will try to take some to investigate next week.

@phenixdotnet
any idea why the packages won't work in UAP10, like "System.Threading.Thread"?

@304NotModified : The UWP platform doesn't have support to run app using System.Threading.Thread but core clr has ref lib to build app using it. So you can build a lib using it but you can't at this time run it.

Don't fully get it. If we now install NLog 4 alpha on an uwp app,  we get errors regarding those packages. Is this expected?

Yes ^^
The coreclr has lib for System.Threading.Thread but the UWP platform hasn't (for the moment).

So UWP is now unusable? Won't it be better to disable the code for uwp which depends those packages for now?

hi @phenixdotnet
I did some changes. I hope those won't conflict with your methods. I use the SLN so I find it important to get it compiling in VS2015.
What I did:

removed UWP platform for now (should be there in dotnet5.3)
removed the examples from the .sln (compile issues, not important for now)
updates in project.json to net451 / dotnet5.4

Also I checked if we can .Net Platform Standard with the following results:

.Net Platform Standard
moniker?
errors

1.4
dotnet5.4
0

1.3
dotnet5.3
126

1.2
dotnet5.2
134

1.1
dotnet5.1
134

1.0
dotnet5.0
317

I will propose to move first to 5.3 and after that tot 5.1. With 5.3 we get UWP support.

.Net Platform Standard
source
Image (as docs get moved every time)

Hi @304NotModified
You did an amazing work :). I always got the solution building before trying to build it with cake so its fine for me.
Regarding the support of the dotnet5.3, I think it will be really hard to get it. System.Threading.Thread isn't available for example.
Regarding the UWP support, as we use reflection to get a StackTrace instance I think it will not run because the platform doesn't support it at all.
Additionally you have update the Nlog/project.json to net451 and dotnet5.4 but not the others projects. Didn't you got errors on compilation and unit tests ? I tried this (maybe ^^) but I didn't got it working.

I'm lazy and run the unit tests on AppVeyor :P
But I forget to update the other projects indeed.

@phenixdotnet I tried to update the build.cmd/ .cake, but still it uses dnxcore50 and RC2? What Am i doing wrong?
I think it would be nice to stick to RC1-update1 for the moment

@phenixdotnet would be great if you could fix the build.cmd (windows) and the .cake for linux (see travis builds).

@304NotModified The version is set in build.cmd AND build.ps1.
I will rework the scripts to get it easier to work with.

Thanks! That would be great!

I would also be nice if appveyor would report errors when cake fails. Atm it looks like it builds, but that's wrong reported.

Yeah its due to the way I refactor the build.cake script. Errors doesn't seem to be catched by cake.

@304NotModified The cake script no throw errors when errors happen.
The script is also running under *unix. Travis fail because of the limitation of dnu/dnx which run only under Ubuntu.
I will try to investigate tomorrow why unit tests fail for dotnet5.4, I think its a recent merge from the master.

Well, it looks like the unit tests for dnxcore 50 aren't using the dotnet5.4 NLog. (and therefore fail)
Thanks for fixing the cake. (did not checked yet) . I was experimenting with the results without cake as that makes the build process less complicated.

@304NotModified I'm not sure removing cake will made the process less complicated. Cake is doing a lot of work and allow us to have the same process on windows and linux.
For example, if you want to work with the dnx/dnu command directly you should call all dnu /dnx command using dnvm exec to run in the right runtime context.

@304NotModified could you please publish a NuGet Package with dotnet5.4 support? The version 4.4.0-alpha1 only supports dnxcore50.

I was a bit waiting on netstandard1.4
(curious whats get renamed in rc3 :p)

@jeremymeng dotnet5.4 support is now available: https://www.nuget.org/packages/NLog/4.4.0-alpha2
Please note that all the unit tests are broken after the move from dnxcore50 -> dotnet5.4. We think xUnit is not ready for it. AFAIK xUnit will only change stuff after ASP.NET Core RC2 (dotnet5.4 -> netstandard 1.4)

@304NotModified Thank you very much!
What issue you were seeing in tests when moving to dotnet5.4?  The Castle.Core.Tests project still works after Castle.Core changed to use dotnet5.4.  Test projects should still use dnxcore50.  And you might need to use a higher version of xUnit.

Well after the change from dnxcore -> dotnet5.4:

NLog.UnitTests  Total: 854, Errors: 0, Failed: 582, Skipped: 2

When I tested locally, it seems that the unit test for dnxcore50  weren't using the dotnet5.4 nlog.dll
really strange.

Is it because you are using -* so RC2 packages got pulled down, Will it work if you explicitly specify RC1 version (beta-23516) for other dependencies?

Nope it doesnt. That's the confusion.

I gave it a try...only have 4 failures though

My changes: https://github.com/jeremymeng/NLog/commit/8f959536ca82bb77f73e42bf8e6441c6c202f4c1

@jeremymeng VS run the unit test on DNX but not on coreclr runtime but on clr runtime:
Starting  Microsoft.Dnx.TestHost [C:\Users\USER\.dnx\runtimes\dnx-clr-win-x<IP_ADDRESS>-rc1-update1\bin\dnx.exe --appbase "C:\dev\NLog\tests\NLog.UnitTests" Microsoft.Dnx.ApplicationHost --port 54680 Microsoft.Dnx.TestHost --port 54808 --parentProcessId 6816] Connected to Microsoft.Dnx.TestHost Running tests in 'C:\dev\NLog\tests\NLog.UnitTests\project.json'
if you want to try running unit tests on coreclr runtime you can:

Remove the net* target in project.json in unit tests project

OR

Use the build.cmd script: .\build.cmd -Configuration Debug

@phenixdotnet Thanks!  Got the coreclr version running. Yes a lot of tests failed.  I noticed that for Full .NET framework, 450 types are retrived here then scanned for registration next.  While the Dnx version returns zero-length array, so probably a lot of types are not registered but they are required for many tests.
I guess it's unfinished code.  I've submitted a PR to use the recommended alternative API for .NET Core.  There are still eight failing tests, four more than NET451.  Those should be dealt with separately.
   NLog.UnitTests  Total: 854, Errors: 0, Failed: 8, Skipped: 2, Time: 196.706s

@304NotModified I hope the PR is good and an alpha-3 package would be awesome!

Also it's unclear to me if I can switch the framework with unit testing in Visual Studio

BTW, the following seems to have worked for me

Set the test project as startup project so the Debug toolbar button becomes "test".  There you can use the dropdown to set the CLR type for debugging

In the project property page, Debug tab, there's an option to use specific Runtime.

I may also have to rebuild the test project, but I don't remember.

@jeremymeng The PR looks good, I merged it in coreCLR branch.
:+1:  for unit tests in VS :)

Thanks @jeremymeng !
https://www.nuget.org/packages/NLog/4.4.0-alpha3 is there!
PS: I don't know how to set the assembly file version with project.json / dnu pack. This can be an issue when installing.

@304NotModified Regarding the assembly file version and assembly version it should be setted by dnu itself and use the project.json version attribute.
Regarding cake, we can add the ContinueOnError option and it should run all target

Regarding cake, we can add the ContinueOnError option and it should run all target

That would be nice.

Regarding the assembly file version and assembly version it should be setted by dnu itself and use the project.json version attribute.

Well the file version is <IP_ADDRESS>, which is wrong. (because alpha2 and alpha3 has the same file version)
Illustrated:  (the assemblytitle is another issue)

FYI
NLog 4.3.0-beta3 and NLog 4.4.0-alpha4 are now on NuGet.

I noticed that ConsoleTarget and ColoredConsoleTarget are currently not included in the CoreCLR build because it is bundled together with UWP10. Is it planned to stay this way or will there eventually be a UWP10 build and a more feature rich CoreCLR build?

Is it planned to stay this way or will there eventually be a UWP10 build and a more feature rich CoreCLR build?

The latter. The CoreCLR support is build on UWP10, but we have still to fix this ( = don't use UWP10 debug symbol with CoreCLR)

@jeremymeng thanks for the unit test trick in Visual Studio. I did tested and it seems to work :)
You do need a rebuild.
Screenie:

(almost) all DNX tests are succeeding :)
DNX:

@304NotModified Thanks for the new packages.  Unfortunately it seems that I couldn't use it in the Castle.Core project, probably due to the RC2 dependencies.  Even after I added the dotnet-core and aspnetcidev feeds, I still get one error
Error	NU1002	The dependency Microsoft.Extensions.PlatformAbstractions 1.0.0-rc2-20113 in project Castle.Services.Logging.NLogIntegration does not support framework .NETPlatform,Version=v5.4.	Castle.Services.Logging.NLogIntegration	C:\github\jeremymeng\Core\src\Castle.Services.Logging.NLogIntegration\project.json	1

probably due to the RC2 dependencies

@jeremymeng RC2 is still not released? (https://www.nuget.org/packages/Microsoft.Extensions.Logging.Abstractions/)

Right, RC2 is not released yet.
Some package might have pulled in the PlatformAbstractions dependency?

Some package might have pulled in the PlatformAbstractions dependency?

What do you mean?

We don''t have "Microsoft.Extensions.PlatformAbstractions",

Some package might have pulled in the PlatformAbstractions dependency?

What do you mean?

I had thought that you weren't referencing PlatformAbstractions directly.  However the project does reference it.
The pre-release RC2 packages seem causing problems when I use it in Castle.Core project.

I tried to fix the RC2 issue, but failed.
Don't get this.

If you know how to fix it, please PR

@304NotModified : I have to pin version on ALL projects, otherwise nuget will take the higher version used in at least one project.

@phenixdotnet thanks!
I unloaded first all projects and found out that the SampleExtensions was breaking it.

@304NotModified I committed changes in project.json to pin version of all dependencies in all project.json file.
Also I rework the build.cake script to build and run all targets and report errors at the end. The build script should be usable on linux/mac too.
It still fail on travis because of unsupported version of the linux used.
If somebody could test the build / unit tests on linux/mac it will be greatly appreciated :)

Thanks @phenixdotnet !
@jeremymeng https://www.nuget.org/packages/NLog/4.4.0-beta1 is now live!

Thank you @304NotModified and @phenixdotnet!  The beta1 package works like a charm!

4.4.0-alpha2~4.4.0-beta1 is failed to install to project target dotnet451+(csproj only, not xproj) in VS due to an issue NuGet/Home#1855
Failed to add reference to 'System.Runtime'. Please make sure that it is in the Global Assembly Cache.
Seems an workaroud is set it to "type": "build"
"System.Runtime": { "type": "build", "version": ""}

Hi! Do we need to change that or the project using NLog?

This should be changed in the NLog project.json file.
The reference entry could be a complex object instead of a simple string.

I'm working on this (and testing it). Can confirm that 4.4.0-beta1 can't be installed net451 (it does install on net45)

@phenixdotnet can we chat on gitter?

I'm online :)

@yyjdelete
https://www.nuget.org/packages/NLog/4.4.0-beta2 :)

@304NotModified
Thanks, it works now.
But it's so strange that the new package can only be found at nuget v2(https://www.nuget.org/api/v2/) and web(https://www.nuget.org/packages/NLog/4.4.0-beta2), not v3(http://api.nuget.org/v3/index.json).The newest version in v3 is still 4.4.0-beta1(https://api.nuget.org/v3/registration1/nlog/index.json).

@yyjdelete the nuget.org v3 feeds have an outage to the services that update them, they are still visible because the static files are served via an Azure storage account.

It looks like beta2 is still not in the v3 index. I have updated the meta-data, so maybe some luck in a few minutes

@304NotModified @yyjdelete nope, also looks like Serilog 2.0.0-beta-509 still hasn't made it into the index yet either. It worked fine just changing the project.json to the version I needed to get the changes I made to Serilog into Castle Core yesterday, which it sounds like you've done.

Looks like .net core rc2 is finally released!

Let's continue discussion at https://github.com/NLog/NLog/issues/1458

This thread is large, so closing this let continue discussion at https://github.com/NLog/NLog/issues/1559


Move imports inside functions

If we move imports into functions, only importing packages when needed, importing and using the toolkit will be a quicker, cleaner user experience for most users. We should apply this principle generally throughout the toolkit (though this is not necessary for the tests).

"Premature optimization is the root of all evil.". We should not be concerned with optimization unless (1) we know performance is poor, and (2) we have evidence that this is a significant contributor.
We control the entire installation environment via conda packaging. If a dependency is missing, it's our fault, and we should catch that with tests---not with a top-level import.

Are there other reasons besides these two that may be compelling?

"Premature optimization is the root of all evil."

Completely agree, but that also applies to move the import statements inside the functions to speed up the import time of our modules.

We control the entire installation environment via conda packaging

Also true! I often have to fix the environment manually especially during development (e.g., package incompatibilities arising from changes in an external package that we can't control), but I agree that this is not the main use case we want to support.
I'll be happy with any solution anyway. I just wanted to make sure we consider advantages and disadvantages before refactoring.

Completely agree, but that also applies to move the import statements inside the functions to speed up the import time of our modules.

Except that it's much easier to adopt the import encapsulation principle from the start and move imports to global space if they become a computational bottleneck than it is to go the other way and hunt down all the times imported packages and methods are used.

I'll be happy with any solution anyway. I just wanted to make sure we consider advantages and disadvantages before refactoring.

+100

See linked PR for a decent attempt at cutting down some of these imports (more can be done!) and a quick method for analyzing and visualizing import times.


Support MarketplacePurchaseEvent support

this PR is intended to solve #704

Why close this PR? I think we just need to rebase the commit on latest master, and regenerate the Go package. See my https://github.com/google/go-github/issues/704#issuecomment-345373248 in the issue for more information about that.

I think i've screwed up everything! Will submit a fresh PR. I'm Closing this PR now


PhPStorm terminal UI Bug

hi, anyone encountered the same issue for PHPStorm Terminal UI.
Check the screenshot below, if you can see the "check" icon were not shown properly and the arrow as well.
PHPStorm screenshot

iTerm screenshot

Thanks!

I think this is bug on PHPStorm not on this repo.


Wacky Worlds Large Scenery Updates

This PR updates all of the RCT2 WW large scenery objects to have the following traits:

They no longer cost $190 to build and give back/remove $150 when demolished. Instead, they now follow a similar cost style to RCT2 Time Twister's large scenery (e.g. the Statue of Liberty now costs $260 to place down and -$190 to remove), with each object having its own build and removal prices.

Some large scenery objects either now have gained photogenic traits, supports, or both.

Others have also had their cursor icons changed.

ja-JP names have been added for the remaining large scenery objects that didn't already have them. Feel free to improve them, though.

I will do a similar update to the small scenery (that will be in a separate PR from this), but that is a whooping 354 objects to do, although I have edited over 75% of them already.

Never noticed that each object cost the same! That's... bad.

ja-JP names have been added for the remaining large scenery objects that didn't already have them. Feel free to improve them, though.

You tend to put several changes that are not really related together in a pull request. This makes reviewing hard. Especially with regards to translations, since we had to fix a lot of them. On other words, please keep translation changes out of pull requests that are there to fix prices.

I have now split off the following things from the PR:

Prices and cursor fixes - merged
Support fixes - merged
Japanese "translations" - removed

That only leaves the photogenic traits, which need a closer look. I certainly don't want to mark something as photogenic too easily, but I do agree that objects like the Sputnik are very logical candidates.

I have finally gotten around to updating the WW small scenery objects. That was a total of 354 objects whose properties and prices I fixed, and this took me at least one month. I have packaged the updated files in a zip.
RCT2 WW small scenery objects updated (20200627).zip
I updated my branch of objects and updating the WW small scenery objects in my branch took 4 commits (100 files, 100 files, 100 files, and then 54 files).

@Fred-1044276 We like that you put effort into fixing objects (they need it, frankly), but we have told you several times we really don't want all kinds of changes mixed together. Like I said before: we want one PR with fixed prices, another for fixing a certain property, and so forth. Otherwise it's nearly impossible to properly review and discuss the changes.
Until now, I have taken it upon myself to split your PRs and make sure to check them individually, but this is a laborious task. I did it anyway to help you get started - we don't expect everyone to be completely familiar with our way of working right from the start - but I did ask you, at least twice, to split them in the future. I'm not going to fix them this time. You will have to do that yourself, and create individual PRs - just dumping a ZIP is not sufficient. We are, of course, more than willing to help you determine what to put together in a PR and what to keep separate.


TypeError: "Cannot read properties of null (reading 'shardId')" in command "info"

Reported by mephisto5558<PHONE_NUMBER>25055775) with bot<PHONE_NUMBER>02710047
TypeError: Cannot read properties of null (reading 'shardId')
at Message.run ([cwd]/Commands/Information/info.js:17:45)
at Message.commandExecutionWrapper ([cwd]/Utils/commandExecutionWrapper.js:28:23)
at process.processTicksAndRejections (node:internal/process/task_queues:95:5)

+
An error occurred while trying to send your error report.
dev.send is not a function

Please message the dev directly.

Note: cmd executed in DMs, should be added to the error report


global config raw options

As the globally failing tests indicate, this approach needs some work.  options is nil by default.  I'd also need you to add some specs to consider the PR for merging.
Thanks!


.Net 5 package resolution problems with some packages

@forki I noticed a problem on GitLab which basically boils down to paket (crashing with stackoverflow) having trouble to resolve:
group Build
   source https://api.nuget.org/v3/index.json
   nuget Fake.DotNet.Cli
   nuget Fake.IO.FileSystem
   nuget Fake.Core.Target

Paket 5.251.0 runs into the following 'conflict':

 Conflict detected:
  - System.Security.Cryptography.Cng 5.0.0-preview.8.20407.11 requested package Microsoft.NETCore.Platforms: >= 5.0.0-preview.8.20407.11 (preview)
  - System.Text.Encoding.CodePages 4.7.1 requested package Microsoft.NETCore.Platforms: >= 3.1.1
  - System.Security.AccessControl 4.7.0 requested package Microsoft.NETCore.Platforms: >= 3.1
  - System.Security.Principal.Windows 4.7.0 requested package Microsoft.NETCore.Platforms: >= 3.1
  - System.Runtime 4.3.1 requested package Microsoft.NETCore.Platforms: >= 1.1.1

I assume there are still some problems with corner case packages on .net 5. Any chance we can get this fixed? While locally and on other CI systems paket finds a solution, it still dances around downgrading lots of packages until it finally finds a solution and downgrades some packages which IMHO shouldn't need to be downgraded (like NuGet.Common and some others).

At the very least I need to know what I should say to users when this hits someone?

Anyway, I released 5.20.4-alpha.1642, so maybe someone here can test if that actually works better?

From https://github.com/fsharp/FAKE/issues/2544

System.Security.Cryptography.Cng 5.0.0-preview.8.20407.11

where is that one coming from?

NuGet.Packaging 5.7.0 requested package System.Security.Cryptography.Cng: >= 5.0.0-preview.3.20214.6 (preview)
lol what?

Adding  nuget Nuget.Packaging 5.6 works.
group Build
   source https://api.nuget.org/v3/index.json
   nuget Fake.DotNet.Cli
   nuget Fake.IO.FileSystem
   nuget Fake.Core.Target
   nuget Nuget.Packaging 5.6

So the problem is that we need to way for a "real" stable net5 release and cannot use -rc releases even though Microsoft says they are "production-ready"?

So the "fix" would be to "whitelist" -rc as "stable" in Paket versioning semantics (at least that seems to be what Microsoft is doing in practice here)? Alternatively, we special case when a "stable" package depends on a "prerelease" package (though I always thought we do that already?)?

Contrary to what I wrote earlier the crash isn't specific to GitLab but it seems unixes in general. For example you can easily reproduce the crash in WSL 2 (Sorry, I confused myself there).
So while there is a 'workaround' and it finds a solution on windows the crash should still be investigated as the conflict here is not too complicated and I'd assume this indicates that a lot of other scenarios will crash as well.

I have seen similar "conflicts" myself locally. It did not end in a crash (or I did not wait long enough), but the conflicht from above does not really sound like a conflict, as only "greater or equal" restrictions are given.
In my case, this is the conflict:
The process is taking longer than expected.
Paket may still find a valid resolution, but this might take a while.
  Conflict detected:
   - Dependencies file requested package Microsoft.Extensions.Configuration: >= 3.0 < 4.0
   - Microsoft.Extensions.Hosting 3.1.10 requested package Microsoft.Extensions.Configuration: >= 3.1.10

If it is likely that this is another problem, I'll open another issue for this. But at least in both cases, I can't see a version conflict from the information given here.

@forki this issue should be fixed by #4059


EmptyList Error / Crashes.

What happened:
Gramaddict regularly crashes regardless of the type of interaction(s) I am trying to complete. It will run for a variable period of time and then crash.
What you expected to happen:
It to continually run until the limits are met.
How to reproduce it (as minimally and precisely as possible):
Run any form of interactions
Anything else we need to know?:
Environment:

GramAddict version: 3.2.2
Device Model/Emulator Type: Huawei P9 Lite
Android Version: 7.0
Instagram Version: <IP_ADDRESS>.123
Discord Ticket ID:           *(if submitting crash log)

Relevant Logs:
Traceback (most recent call last):
File "c:\users\phill.pyenv\pyenv-win\versions\3.8.2\lib\runpy.py", line 193, in run_module_as_main
return run_code(code, main_globals, None,
File "c:\users\phill.pyenv\pyenv-win\versions\3.8.2\lib\runpy.py", line 86, in run_code
exec(code, run_globals)
File "C:\Users\phill\instagramtools\gramaddict.venv\Scripts\gramaddict.exe_main.py", line 7, in
File "C:\Users\phill\instagramtools\gramaddict.venv\lib\site-packages\GramAddict_main.py", line 138, in main
actionsargs.subparser
File "C:\Users\phill\instagramtools\gramaddict.venv\lib\site-packages\GramAddict_main.py", line 40, in cmd_run
start_bot()
File "C:\Users\phill\instagramtools\gramaddict.venv\lib\site-packages\GramAddict\core\bot_flow.py", line 314, in start_bot
configs.actions[plugin].run(
File "C:\Users\phill\instagramtools\gramaddict.venv\lib\site-packages\GramAddict\plugins\interact_blogger_followers.py", line 126, in run
job()
File "C:\Users\phill\instagramtools\gramaddict.venv\lib\site-packages\GramAddict\core\decorators.py", line 100, in wrapper
raise e from e
File "C:\Users\phill\instagramtools\gramaddict.venv\lib\site-packages\GramAddict\core\decorators.py", line 31, in wrapper
func(*args, **kwargs)
File "C:\Users\phill\instagramtools\gramaddict.venv\lib\site-packages\GramAddict\plugins\interact_blogger_followers.py", line 109, in job
self.handle_blogger(
File "C:\Users\phill\instagramtools\gramaddict.venv\lib\site-packages\GramAddict\plugins\interact_blogger_followers.py", line 185, in handle_blogger
handle_followers(
File "C:\Users\phill\instagramtools\gramaddict.venv\lib\site-packages\GramAddict\core\handle_sources.py", line 677, in handle_followers
iterate_over_followers(
File "C:\Users\phill\instagramtools\gramaddict.venv\lib\site-packages\GramAddict\core\handle_sources.py", line 725, in iterate_over_followers
row_height, n_users = inspect_current_view(user_list)
File "C:\Users\phill\instagramtools\gramaddict.venv\lib\site-packages\GramAddict\core\utils.py", line 738, in inspect_current_view
raise EmptyList
GramAddict.core.utils.EmptyList

*Note: if you have a crash log, please do not attach the archive here as this is not a secure place to upload the sensitive data inside. Please open a ticket in Discord in #lobby and provide the ticket ID here.

Was this sorted please ?


TypeError: 'NoneType' object is not callable

Service does not work _ (
I`m doing something wrong?
(venv) bash-3.2$ python3 ./src/turnipexchange.py --name Username
[2020-04-20 20:04:53] Getting islands page...
[2020-04-20 20:04:07] Parsing page...
Traceback (most recent call last):
  File "./src/turnipexchange.py", line 245, in <module>
    islands = tex.get_islands()
  File "./src/turnipexchange.py", line 42, in get_islands
    name = island_top_note[0].findChild('h2').contents[0].strip()
TypeError: 'NoneType' object is not callable

Hi, thanks for the report!
Probably the content of the page we're scraping has changed since the last commit,
I'll try to fix it as soon as possible!

Thax a lot

Fixed as per commit d6b6c24ee5ff34d7c0cb3bec265aca37cbfb24f7 !

Thanx.
Today i have one more other error %(
~/P/TurnipMaster (master ☡=) python3 src/turnipexchange.py --name Username
[2020-04-23 14:04:16] Getting islands page...
[2020-04-23 14:04:28] Parsing page...
[2020-04-23 14:04:28] Filtering by queue length (2) [0 <-> inf]
[2020-04-23 14:04:28] Filtering by turnips price (2) [0 <-> inf]
[2020-04-23 14:04:28] Ignoring fruit (2) [None]
[2020-04-23 14:04:28] Filtering by emisphere (2) [None]
[2020-04-23 14:04:28] Islands after filters: 2
[2020-04-23 14:04:28] Sorting islands by turnips price...
[2020-04-23 14:04:28] Skipping 0 islands starting from top...
[2020-04-23 14:04:28] USER: Username
[2020-04-23 14:04:28] MODE: sell
[2020-04-23 14:04:28] [code:24deee69][price:301][queue:0/20]
[2020-04-23 14:04:28] [code:48bd86ad][price:150][queue:0/25]
[2020-04-23 14:04:28] Opening the first island based on price...
Traceback (most recent call last):
  File "src/turnipexchange.py", line 259, in <module>
    tex.open_island(islands[0].code, name)
  File "src/turnipexchange.py", line 86, in open_island
    EC.visibility_of_any_elements_located((By.XPATH, "/html/body/div/div[2]/div[2]/div/input"))
  File "/usr/local/lib/python3.7/site-packages/selenium/webdriver/support/wait.py", line 80, in until
    raise TimeoutException(message, screen, stacktrace)
selenium.common.exceptions.TimeoutException: Message:

As you can see in the Firefox browser tab opened by the application, the applications throws this error because he cannot join the queue due to it being already full after 10 seconds of trying.
We can decide to handle that, but it requires more work to be done and I don't think it will be worth the time spent on it.
Try using other filters like --skip and price and queue length for making sure you are going to be inserted in a free queue!


Ability to assigned "labels" to endpoints

Is your feature request related to a problem? Please describe.
Some devices provide many endpoints. It's not always clear what their function is, especially when these endpoints get represented in an application. A good example of this is the Aeotec Siren 6, which has 8 endpoints. Each endpoint provides some slightly different functionality. Luckily Aeotec provides good tech documents, so it's somewhat easy for a technically inclined person to determine the functionality, but this is still out of reach of must users.
In Home Assistant, with 8 endpoints you get 8 duplicate entities that interact with each endpoint. Since all we have to go by are the endpoint numbers, you get meaningless names like:
siren.foo
siren.foo_2
siren.foo_3
...
siren.foo_8

The numbers (sans the "1") should correspond to the endpoint numbers, but most users wont' have a clue how siren.foo_2 differs from siren.foo_8.
I would like to propose an enhancement that might allow applications to provide some clarification about how endpoints are used for various devices.
Describe the solution you'd like
As suggested in the HA Discord, Z-Wave JS already has the ability to configure endpoints via device config file. Adding something like a "label" field to the endpoint might be useful. This could be included as part of the node state and applications could choose to name things based off of the endpoint label, as opposed to just the endpoint number itself.
Describe alternatives you've considered
Applications could manually customize naming on a per-device basis. This would mean each application duplicates the implementation and could have different descriptions.
Additional context
Here's the definition of the endpoint functionality for a Siren 6. AFAIK this info is not available from the device itself.

In the device config I might set something like this:
"endpoints": {
    "1": {
        "label": "Browse"
    },
    "2": {
        "label": "Tampering"
    },
    "3": {
        "label": "Doorbell 1"
    },
    ...
    "8": {
        "label": "Emergency"
    }
}

And with the label, the entities could be named descriptively:
siren.foo_browse
siren.foo_tampering
siren.foo_doorbell_1
...
siren.foo_emergency

The naming is not a foolproof solution: what do "browse" and "emergency" mean? IMO, still better than plain numbers. A description field could even be added to provide more information, although I don't have a clue how something like HA would present that kind of information (an attribute of the primary entity?).
Another example is the Fibaro RGBW devices. I think they have 6 endpoints, including the root. The root controls RGB directly, other endpoints control each color channel separately, etc. Naming these would be pretty useful, e.g. light.foo_rgbw, light.foo_red, light.foo_green, etc.
I can't say how many devices this would be useful for, so it may be limited in application. I'll say though that a common question in HA in the past has been along the lines of "why does my node have so many duplicate entities?". Even something like a double replay would benefit to being named switch.foo_relay_s1 and switch.foo_relay_s2 as opposed to switch.foo and switch.foo_2.

I'm trying to migrate from Openzwave to Zwave-JS and I'm really missing these labels. For the rest Zwave-JS is awesome!
Am I overlooking something or is it still missing from the current release?

Am I overlooking something or is it still missing from the current release?

The feature request is still open, which means it hasn't been implemented.
I actually didn't realize OZW had this capability, but here it is: https://github.com/OpenZWave/open-zwave/blob/cb2320965e45650e509887a982d8096723ae4c8c/config/aeotec/zw164.xml#L35-L44
I didn't think it was used in HA (I can't find any code using the labels). Does your experience show otherwise?

Good find in the OZW code! This should make it much easier to implement, right?
I don't think the label is currently used in HA. In fact I don't think the usage of sirens is really supported at all.
Personally, I use the labels in MQTT-explorer for my own reference when interfacing with the Siren's/ Doorbell I've got. Being able to make use of the labels in HA would make it an awesome improvement and really a big step to more/better support for sirens.


WebAssembly subfeatures

WebAssembly currently supports a growing number of subfeatures that is causing fragmentation in WebAssembly adoption. Simply listing a single WebAssembly supported Yes/No page is not enough.
The WebAssembly roadmap page at https://webassembly.org/roadmap/ lists the most recent state of each browser, but that is not really useful for anyone developing a site that needs to take marketshare statistics into account.
In https://github.com/WebAssembly/website/issues/187 a question was raised to the WebAssembly CG if they would like to revise the website to be more precise caniuse.com-like in the data they provide, but the query did not gain traction, citing "it is too complex" to report the data like caniuse.com does.
Would it be possible for caniuse.com to do this?
The different subfeatures of WebAssembly so far are:

Wasm BigInt support
Bulk memory
Multivalue functions
Mutable globals
Reference types
Nontrapping Float-to-Int conversions
Sign-extension operations
Wasm exception handling
SIMD128
Tail calls
SharedArrayBuffer and Atomics. This is already covered by https://caniuse.com/sharedarraybuffer
4GB Wasm Memory support. https://github.com/WebAssembly/website/issues/214

To get going, I gathered the results list for Firefox desktop:
Signext: Introduced in Firefox 57
Nontrapping FpToInt: Introduced in Firefox 60
Mutable Globals: Introduced in Firefox 61
Bulk memory: Introduced in Firefox 64
BigInt: Introduced in Firefox 74
Multivalue: Introduced in Firefox 77
Reference types: Introduced in Firefox 78
Wasm exceptions: No support as of Firefox 82
SIMD128:  No support as of Firefox 82
Tail calls: No support as of Firefox 82
4GB Wasm Memory: No support as of Firefox 82
Do you think this kind of data could be integrated to caniuse.com?

Started a repository that one can use to quickly test out the different subfeatures: https://github.com/juj/wasm_feature_test . I'll try to complete to the full set soon.

Very much related: #5200

webassembly.org/roadmap has been revamped to report detailed support data, which is now mostly complete for mainstream browsers (WebAssembly/website#292).
Should we replicate this data to caniuse.com?
Pros:

Discoverability: caniuse.com is significantly more well-known than WebAssembly roadmap. It is the go-to place for developers seeking centralized knowledge about web feature status.

#6383 addded a link of the roadmap to the resources tab, but I feel it's too hidden for most people. I personally almost never check in there.

Marketshare statistics: This is arguably more useful than raw version numbers. The roadmap doesn't have this.

Cons:

Maintainance burden required to manually keep the two projects in sync.
Design mismatch: the roadmap is designed slightly differently. For example, it doesn't track the first-introduced version of feature flags (rationale). And overall it's less powerful/expressive than caniuse.com.

I think we should add the feature extensions, basically for the reasons given in the Pros section above.
I just uploaded #6952 as a test case and it wasn't too bad. Based on my experience keeping webassembly/org/features up to date, It doesn't seem like it will be a huge burden to also put the data on caniuse.
For future features, we can add data on first-introduced version of feature flags if we want; although I agree with the rationale given in your link, that developers should use bleeding-edge browsers to test flagged features. Also feature flags sometimes change (which would be onerous to track here), and there are also Origin Trials, which are arguably more relevant to track wrt browser versions than flags. But those considerations apply to all new browser features and are not unique to wasm, so we can do whatever the common practice on caniuse is.
I agree that SharedArrayBuffer is tricky; this is true for both webassembly.org/features and caniuse.


Make recommendation to split negated mappings in separate files

We have often warned of the dangers of allowing negative (NOt) and positive mappings side by side due to the possibility of accidentally ignoring the predicate_modifier column by more naive users. We should contemplate to suggest to always split negative from positive mappings into separate files. This also aligns with normal use cases of mappings.
As a reminder, a negative mapping is a mapping that does not hold. It emerges when one source, for example an automated matcher, suggests a mapping that is later rejected by another source, for example a human reviewer.

I would not do this for sake of simplicity. Or it will become a nightmare to deals with multiple files (producing or consuming).
There is a documentation. There is an explicit column.
Negative mappings are a real value added (and innovation) of SSSOM, I would not hide it "in another file"

We can decide not to do this on the level of SSSOM, but I disagree with your caution here - we will deal with hundreds of different files anyways so "nightmare" is in any case a given. But the risk of naive downstream users ignoring the predicate_modifier column is significant. I lost that vote (I would have preferred sssom:notExactMatch, so a predicate based solution, but ok, most people preferred predicate_modifier :D

I understand the motivation in the separation of files. This was mainly a personnal thougth ;)
I join you on the point: "we will deal with hundreds of different files anyways". => that's why I want to work on "mapping repositories"


'Unsupported parameters for (ceph_ec_profile) module: crush_root.

when I use the "ceph_ec_profile" module with the "crush_root" parameter, I get the following msg:
'Unsupported parameters for (ceph_ec_profile) module: crush_root. Supported parameters include: cluster, stripe_unit, name, k, state, m, crush_device_class.'
this parameter is already described in this module "ceph-ansible/library/ceph_ec_profile.py", how can i use it ?

Although crush_root is documented here [1] this module doesn't support this parameter, see [2].
Not sure why I've documented this parameter while the module doesn't actually support it, it seems to be an error.
[1] https://github.com/ceph/ceph-ansible/blob/main/library/ceph_ec_profile.py#L79-L83
[2] https://github.com/ceph/ceph-ansible/blob/main/library/ceph_ec_profile.py#L162-L169

This parameters unsupported, so i close this issue.

This parameters unsupported, so i close this issue.

we could make it support this parameter though 🙂

Thank you for this. I'm looking forward to it. 😄

PR are welcome too 😅


fix: remove urm create from task create request.

This will greatly reduce the amount of urms created in the system. To make this change to the system we need to also remove our direct reliance on the urm's in tasks.
Remove the create and delete portion of the task actions that are creating and deleting urms
Remove reliance on urm's when we are doing FindTaskByUser and instead rely on the user filter matching the task.OwnerID
One test had to be changed because the test was explicitly hacking the task to remove the owner ID and then trying to successfully look up the task by ownerID

Makes me wonder if we do want to flag this change 🤔 What do you think?

Yah the change ended up being larger than I thought. A feature flag would get the create actions creating urm's. I think if we run into problems with this change it will be with the find action or as part of task execute, both of which the feature flag wouldn't be able to help.


Hydrogen does not display anything in editor

I have been using Hydrogen happily for some time, but something seems to have gone wrong now such that when I try to run a script, the bubble appears saying "Kernels updated" but then nothing happens. No activity symbol, no tick, no results shown in the editor. I'm hoping someone might be able to suggest what has gone wrong here.

Can you see if there are any notices shown in the Dev tools? In the command palette select Window: Toggle Dev Tools.

Actually yes it provides the following warning:
Hydrogen.kernelspec' could not set the default. Attempted default: undefined; Schema: {}

I often get that warning too, so I don't think that should prevent results from showing. Does ipython work in the terminal?

IPython does work in the terminal. Running jupyter kernelspec list --json shows that Hydrogen is pointing to a version of Python that no longer exists. Is there any way to change this?

python -m ipykernel install --user, where python is the specific executable that you want Jupyter to use.

That seems to have done the trick. Thanks very much.

Welcome!

Seems like a lot of people are having trouble,
Make sure 'pip' is working properly in your system. For me, pip2 is not responding so I worked with pip3.
I got this from "Joseph T" in comments under a YouTube video:
"
I had troubles with installation so here is a guide:
Install Hydrogen in Atom
Type in terminal:
python3 -m pip install --upgrade pip; sudo python3 -m pip install jupyter
python3 -m ipykernel install --user
sudo pip install --upgrade ipykernel
Ctrl+Shift+P in Atom and type hydrogen update kernel
After that select your python lines to run and press Ctrl+Enter
If still not working close and reopen Atom and try again

"
from https://www.youtube.com/watch?v=VcDbxEV-OI0
The thing is, you should install ipykernel separately yourself, in Terminal.
Any kernel you want, for beginners like me, that was a challenge.

Can you guys refer to this more explicitly in the readme, for beginner?

I had Hydrogen installed more than a year ago. since it didn't work, I was afraid of going to it.
Until yesterday, I decided to get it to work no matter what.
It took me more than 3 hours.

One of the problems was that I thought jupyter was the kernel.
I later found out I should install ipykernel.

The installation page says

Checkout nteract.io/kernels for instructions on how to install the most popular kernels

And that shows how to install kernels for several languages.

@Ornataweaver
Based on your experience, how would you improve this?

Whatever I used in atom, was installed via atom or apm. This caused the confusion.
Although it's good for learners to break habits.
Many of consumers of atom are highschool kids, and even younger. So this can happen for them too.
Suggestions

Start the Installation page (https://nteract.gitbooks.io/hydrogen/docs/Installation.html) with:

  Hydrogen requires Atom 1.20.0+ and kernels,
  which should be installed outside of atom and apm,
  for the languages you intend to use Hydrogen with.

Put a "Beginner notice:" on the top and emphasize that kernels should be installed out of Atom.
Devs read the rest of it more carefully, and won't make my mistake.

The second option is better.
#UserStoryHub
To top it off mentioning apm install hydrogen in the second line, gives the impression that kernels are installed via apm as well.


NTR: grit removal

Proposed Term Label
grit removal
Proposed Associated Field(s)
presampling_activity
Definition/Description
A wastewater treatment process which removes sand, silt, and grit from wastewater.
Definition Source
No response
Guidance
No response
Alternative labels and/or synonyms
No response
Additional Comments (not an annotation)
Required for IRIDA dataset. Include any relevant additional presampling activities from wastewater spec.
Optional - Contributor Attribution
No response

Term
Ontology ID

Wastewater treatment process
ENVO:06105300

Wastewater filtration
GENEPIO:0100881

Wastewater grit removal
GENEPIO:0100882

Wastewater microbial treatment
GENEPIO:0100883

Wastewater primary sedimentation
GENEPIO:0100884

Wastewater secondary sedimentation
GENEPIO:0100885

PR #96