(LOG4NET-467) .NET Core support #16

Closed
wants to merge 3 commits into
from

Projects

None yet
@chlowell
chlowell commented Oct 29, 2015 edited

This adds a new solution under log4net/netstandard, providing a build for netstandard1.3. Using this in Visual Studio requires Visual Studio 2015 Update 3 and .NET Core 1.0 for Visual Studio. Building and running tests from the command line, without Visual Studio, can be done with .NET Core SDK Preview 2.

Following established style, the new projects use compilation constant NETSTANDARD1_3 for platform-specific changes. Some features are excluded entirely because they can't be implemented presently on the .NET Platform Standard. I think stack frame logging is the most important of these.

Similarly, due to the lack of Assembly.GetCallingAssembly(), only APIs which are explicit about their assembly parameters are exposed. For example, several LogManager methods reliant on GetCallingAssembly() have overloads with an Assembly or Type parameter; only the latter are surfaced for netstandard1.3.

Known issues:

  • RollingFileAppenderTest.TestExclusiveLockLocks() fails on Linux; fixing this will probably require a new strategy for file locking, e.g. lock files.
@chlowell chlowell changed the title from [WIP] Initial .NET Core support to [WIP] (LOG4NET-467) .NET Core support Nov 16, 2015
@bodewig
Member
bodewig commented Dec 11, 2015
@bleroy bleroy referenced this pull request in OrchardCMS/Orchard2 Jan 29, 2016
@sebastienros sebastienros Adding diagnostics middlewares eb156cb
@chester89

@chlowell any updates on this?

@chlowell

I have another branch on my fork (dotnetcore-rc2) which builds with RC2 tools, and has some improvements over the code here. A few tests are broken due to executing with NUnitLite. Once the NUnit runner is updated for RC2 (nunit/nunit#1371), I'll open a new PR.

@bodewig
Member
bodewig commented May 29, 2016

Please note I'm just one voice others may think differently about this. Given the amount of flux that's going on I'm a bit reluctant to adapt to .NET Core before 1.0 is final.

And once it is, in the light of https://blogs.msdn.microsoft.com/dotnet/2016/05/27/making-it-easier-to-port-to-net-core/ I'm not sure whether it wouldn't be better to wait even a bit longer. The current patch throws out all serialization which will become available in a successor of .NET Core again, maybe the workarounds for System.Diagnostics.StackTrace and Assembly.GetCallingAssembly won't be needed any longer either.

@StrangeWill StrangeWill referenced this pull request in RoushTech/RollbarDotNet Jun 1, 2016
Open

Add Log4Net Appenders #9

@StrangeWill

@bodewig Hopefully there shouldn't be much flux between RC2 and Final (well at least we were told porting from RC2 -> Final won't be nearly as bad as RC1 -> RC2 was, and it wasn't that bad), though I am struggling myself with System.Diagnostics.Stacktrace being gutted on one of my own projects. I can totally understand the hesitation though especially with a project like this.

I'll be keeping my eye out for support for .NET Core on log4net, I'm just not nearly as happy with any of the other solutions.


The other interesting question is whether or not log4net on .NET Core is going to support the new json configuration files or still require XML files out of the box.

@bodewig
Member
bodewig commented Jun 1, 2016

so far there haven't been any concrete plans beyond this PR

@niemyjski

+1 I'm also needing this for our oss projects that depend on log4net. Would be great to get this on the lowest .net standard possible.

@pantonis

+1

@arkadiuszwojcik

I suggest all of you switch to:

https://www.nuget.org/packages/Microsoft.Extensions.Logging.Abstractions/

and create log4net port for that. Actually it is quite easy to create it on your own.

@jonorossi jonorossi referenced this pull request in castleproject/Core Jul 12, 2016
Open

Support log4net integration on .NET Core #201

@chlowell chlowell changed the title from [WIP] (LOG4NET-467) .NET Core support to (LOG4NET-467) .NET Core support Jul 12, 2016
@chlowell

I updated this branch for .NET Core 1.0 rather than creating a new PR. The branch name is unfortunate--there's no longer a PCL involved--but I hope keeping this open is convenient for those watching.

@arkadiuszwojcik the goal of this PR is to make log4net portable across .NET Core platforms. Implementing those abstractions could be useful, but doing so wouldn't enable consuming log4net on additional platforms.

@ghost Unknown commented on the diff Jul 13, 2016
src/Appender/AppenderCollection.cs
@@ -26,7 +26,10 @@ namespace log4net.Appender
/// A strongly-typed collection of <see cref="IAppender"/> objects.
/// </summary>
/// <author>Nicko Cadell</author>
- public class AppenderCollection : ICollection, IList, IEnumerable, ICloneable
+ public class AppenderCollection : ICollection, IList, IEnumerable
+#if !NETSTANDARD1_3
+ , ICloneable
@ghost
ghost Jul 13, 2016

Note that ICloneable is coming back. dotnet/corefx#9970
If the new contract doesn't support NETSTANDARD1_3, and we do want to support this TxM, then the best way in the future would be to also add NETSTANDARD1_<whatever> in the project.json which exposes IColeable interface on public surface area.

@ghost Unknown commented on an outdated diff Jul 13, 2016
tests/src/Utils.cs
}
- }
+
+ // Wrappers because repository/logger retrieval APIs require an Assembly argument on NETSTANDARD1_3
+ internal static ILog GetLogger(string name)
+ {
+#if NETSTANDARD1_3
+ return LogManager.GetLogger(typeof(Utils).GetTypeInfo().Assembly, name);
+#else
+ return LogManager.GetLogger(name);
+#endif
@ghost
ghost Jul 13, 2016

nit: indentation of either one of two return statements is off

@ghost Unknown commented on an outdated diff Jul 13, 2016
tests/src/Utils.cs
+ internal static ILog GetLogger(string name)
+ {
+#if NETSTANDARD1_3
+ return LogManager.GetLogger(typeof(Utils).GetTypeInfo().Assembly, name);
+#else
+ return LogManager.GetLogger(name);
+#endif
+ }
+
+ internal static ILoggerRepository GetRepository()
+ {
+#if NETSTANDARD1_3
+ return LogManager.GetRepository(typeof(Utils).GetTypeInfo().Assembly);
+#else
+ return LogManager.GetRepository();
+#endif
@ghost
ghost Jul 13, 2016

nit: indentation of either one of two return statements is off

@ghost Unknown and 1 other commented on an outdated diff Jul 13, 2016
src/Util/ReadOnlyPropertiesDictionary.cs
@@ -215,8 +216,13 @@ public virtual void GetObjectData(SerializationInfo info, StreamingContext conte
string entryKey = entry.Key as string;
object entryValue = entry.Value;
- // If value is serializable then we add it to the list
- if (entryKey != null && entryValue != null && entryValue.GetType().IsSerializable)
+ // If value is serializable then we add it to the list
+#if NETSTANDARD1_3
+ bool isSerializable = entryValue.GetType().GetTypeInfo().IsSerializable;
+#else
+ bool isSerializable = entryValue.GetType().IsSerializable;
+#endif
+ if (entryKey != null && entryValue != null && isSerializable)
{
@ghost
ghost Jul 13, 2016

nit: indentation under #if #else and that of if (entryKey is off

@chlowell
chlowell Jul 13, 2016

The original code mixes tabs and spaces freely. I tried to remain consistent with that to limit whitespace noise in the diff. I'll normalize the lines you've called out; thanks for the attention to detail.

@ghost Unknown commented on the diff Jul 13, 2016
...il/PatternStringConverters/NewLinePatternConverter.cs
@@ -72,6 +75,16 @@ internal sealed class NewLinePatternConverter : LiteralPatternConverter, IOption
/// </remarks>
public void ActivateOptions()
{
+#if NETSTANDARD1_3
+ if (CultureInfo.InvariantCulture.CompareInfo.Compare(Option, "DOS", CompareOptions.IgnoreCase) == 0)
+ {
+ Option = "\r\n";
+ }
+ else if (CultureInfo.InvariantCulture.CompareInfo.Compare(Option, "UNIX", CompareOptions.IgnoreCase) == 0)
@ghost
ghost Jul 13, 2016

Should we just ToLower(), compare with == and get rid of the preprocessors for all Compare()-like code?

@niemyjski
niemyjski Jul 13, 2016

ToLowerInvariant()

@ghost
ghost Aug 13, 2016

@chlowell, do you think it's a good idea to instead of dogfooding string.Compare(strA, strB, InvariantCulture) == 0 pattern with CultureInfo comparer, use common denominator strA.ToUpperInvariant() == strB.ToUpperInvariant() and remove the preprocessor all over the place as part of this PR? IMO, this will clean up quite a bit. If you want, I can send a PR to your log4net-core-pcl branch, then you would just need to update the JIRA patch. :)

@stuartd
stuartd commented Jul 13, 2016

ToUpperInvariant is preferable

@ghost
ghost commented Jul 13, 2016

@arkadiuszwojcik the goal of this PR is to make log4net portable across .NET Core platforms. Implementing those abstractions could be useful, but doing so wouldn't enable consuming log4net on additional platforms.

I agree and I think that can be a separate repo / package, something like log4net.Extensions.Logging. However, having this Extensions package first hand from original vendor (Apache) is vital on multiple accounts.


Separately, can this PR get some prio love from the reviews please? All the providers listed here: https://github.com/aspnet/Logging#providers, are not as popular as log4net and we (folks running stuff on dotnet core) hoping to get our hands on apache/log4net bits.

@chlowell, could you please prepare a SVN patch for the reviewers? We can always have subsequent PRs to refine stuff. If you are aiming to add CI setup for .NET Core TxM as part of this PR, feel free to grab Travis/AppVeyor bits from https://github.com/autofac/Autofac.Extras.Moq/pull/6/files.

chlowell added some commits Feb 1, 2016
@chlowell chlowell Add build for .NET Platform Standard 1.3
This adds a new solution and project at log4net/netstandard/. The new project defines builds for .NET 4.0, .NET 4.5, and .NET Platform Standard 1.3 (netstandard1.3), simplifying distribution of all three in a single NuGet package. In keeping with existing code and patterns, the netstandard1.3 build uses a compilation constant (NETSTANDARD1_3) to work around compatibility issues. Some features requiring APIs not available on .NET Core platforms are excluded, e.g. stack frame logging. Similarly, log4net APIs reliant on Assembly.GetCallingAssembly are excluded from the public surface. Overloads of these with explicit Assembly or Type parameters are exposed, and can be used in an equivalent manner by passing typeof().GetTypeInfo().Assembly.
8fd0af6
@chlowell chlowell Add test project for netstandard1.3 build
Run tests via the CLI (`dotnet test`) or the Visual Studio Test Explorer.
9aa29db
@ghost Unknown commented on the diff Aug 2, 2016
netstandard/log4net/project.json
+ "../../src/Layout/Pattern/AspNetCachePatternConverter.cs",
+ "../../src/Layout/Pattern/AspNetContextPatternConverter.cs",
+ "../../src/Layout/Pattern/AspNetPatternConverter.cs",
+ "../../src/Layout/Pattern/AspNetRequestPatternConverter.cs",
+ "../../src/Layout/Pattern/AspNetSessionPatternConverter.cs",
+ "../../src/Layout/Pattern/StackTraceDetailPatternConverter.cs",
+ "../../src/Layout/Pattern/StackTracePatternConverter.cs",
+ "../../src/Plugin/RemoteLoggingServerPlugin.cs",
+ "../../src/Util/PatternStringConverters/EnvironmentFolderPathPatternConverter.cs",
+ "../../src/Util/LogicalThreadContextProperties.cs",
+ "../../src/Util/LogicalThreadContextStacks.cs",
+ "../../src/Util/NativeError.cs",
+ "../../src/Util/WindowsSecurityContext.cs"
+ ]
+ },
+ "define": [ "HAS_READERWRITERLOCKSLIM", "NETSTANDARD1_3" ]
@ghost
ghost Aug 2, 2016

NETSTANDARD1_3 definition is redundant here.

@asfgit asfgit pushed a commit that closed this pull request Aug 13, 2016
@bodewig bodewig initial support for .NET Core by @chlowell - closes #16
git-svn-id: https://svn.apache.org/repos/asf/logging/log4net/trunk@1756257 13f79535-47bb-0310-9956-ffa450edef68
cb7802b
@asfgit asfgit closed this in cb7802b Aug 13, 2016
@bodewig
Member
bodewig commented Aug 13, 2016

Many thanks for your persistence.

I have applied the patch as is as it didn't break anything of the existing build. But I haven't even tried to build the .NET Core part itself - I'll do so later, and try to figure out how to cut releases that contain the .NET Core assembly as well as the current process is centered around NAnt.

I'd like to invite anybody interested in keeping log4net moving to join the log4net-dev mailing list and lend a hand. We are severely understaffed and can use any help.

@ghost
ghost commented Aug 13, 2016 edited

Thanks a lot @bodewig! I am definitely willing to participate. I will test out the master trunk branch and try to incorporate the feedback in subsequent PR pronto (before you start cutting the release ๐Ÿ˜œ). I have subscribed to log4net-dev mailing list.

@ghost Unknown referenced this pull request Aug 13, 2016
Closed

Misc. fixes for netstandard #30

@ghost
ghost commented Aug 13, 2016

Fixed the build breakage and feedback in #30.

@bodewig
Member
bodewig commented Aug 13, 2016

I've installed the Linux version, this is what happens for me:

Compiling log4net for .NETStandard,Version=v1.3
/usr/share/dotnet/dotnet compile-csc @/devel/ASF/log4net/trunk/netstandard/log4net/obj/Debug/netstandard1.3/dotnet-compile.rsp returned Exit Code 1
/devel/ASF/log4net/trunk/src/Appender/FileAppender.cs(164,33): error CS0115: 'FileAppender.LockingStream.BeginRead(byte[], int, int, AsyncCallback, object)': no suitable method found to override
/devel/ASF/log4net/trunk/src/Appender/FileAppender.cs(175,33): error CS0115: 'FileAppender.LockingStream.BeginWrite(byte[], int, int, AsyncCallback, object)': no suitable method found to override
/devel/ASF/log4net/trunk/src/Appender/FileAppender.cs(183,25): error CS0115: 'FileAppender.LockingStream.Close()': no suitable method found to override
/devel/ASF/log4net/trunk/src/Appender/FileAppender.cs(188,24): error CS0115: 'FileAppender.LockingStream.EndRead(IAsyncResult)': no suitable method found to override
/devel/ASF/log4net/trunk/src/Appender/FileAppender.cs(193,25): error CS0115: 'FileAppender.LockingStream.EndWrite(IAsyncResult)': no suitable method found to override

Compilation failed.
    0 Warning(s)
    5 Error(s)

I'll double check whether I've missed some changes to FileAppender.

@ghost
ghost commented Aug 13, 2016

@bodewig, #30 fixed exactly this issue. Can you try with my branch?

@asfgit asfgit pushed a commit that referenced this pull request Aug 13, 2016
@bodewig bodewig apply missed patch of #16
git-svn-id: https://svn.apache.org/repos/asf/logging/log4net/trunk@1756281 13f79535-47bb-0310-9956-ffa450edef68
f00cdfd
@bodewig
Member
bodewig commented Aug 13, 2016

@jasonwilliams200OK, thanks, but too late, I went off fixing it myself before I saw you comment. :-)

I'll diff my svn tree against a checkout of @chlowell's original branch to verify whether I missed more patch failures. It's pretty strange as I don't recall seeing any "hunk failed" messages.

BTW, this is the test result on Linux (Ubuntu 16.04, but I don't think it matters):

Errors and Failures
1) Failed : log4net.Tests.Appender.RollingFileAppenderTest.TestExclusiveLockLocks
  Log contents is not what is expected
  String lengths are both 38. Strings differ at index 0.
  Expected: "This is a message\nThis is a message 2\n"
  But was:  "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0This is a message 2\n"
  -----------^
at log4net.Tests.Appender.RollingFileAppenderTest.AssertFileEquals(String filename, String contents) in /devel/ASF/log4net/trunk/tests/src/Appender/RollingFileAppenderTest.cs:line 1470
at log4net.Tests.Appender.RollingFileAppenderTest.TestExclusiveLockLocks() in /devel/ASF/log4net/trunk/tests/src/Appender/RollingFileAppenderTest.cs:line 1570
Run Settings
    WorkDirectory: /devel/ASF/log4net/trunk/netstandard
Test Run Summary
  Overall result: Failed
  Test Count: 145, Passed: 136, Failed: 1, Inconclusive: 0, Skipped: 8
    Failed Tests - Failures: 1, Errors: 0, Invalid: 0
    Skipped Tests - Ignored: 8, Explicit: 0, Other: 0
  Start time: 2016-08-13 16:05:11Z
    End time: 2016-08-13 16:05:14Z
    Duration: 2,964 seconds
Results saved as /devel/ASF/log4net/trunk/netstandard/TestResult.xml
SUMMARY: Total: 1 targets, Passed: 0, Failed: 1.
@bodewig
Member
bodewig commented Aug 13, 2016

I've just diffed chlowell:log4net-core-pcl against my svn working copy of trunk and it looks as if there have been changes after the PR which makes identifying misses more difficult. I'll apply #30 and then we can all go from there.

@bodewig
Member
bodewig commented Sep 13, 2016

@chlowell maybe you can help us with two questions.

Why did you chose netstandard1.3 as target and not, say, netstandard1.6. .NET Core 1.0 should provide the later AFAIU.

Why did you chose the version 3.0.0? To me it looks as if 2.1 would be fine if we wanted to unify the versions of the nuget package and the assemblies.

@niemyjski

The lower the .net standard you can target the more places it will run. 1.0 can run every where (1.0, 1.6, etc). You should be targeting 1.3 here.

@bodewig
Member
bodewig commented Sep 13, 2016

I'm not sure this applies here as we are still creating specific assemblies for .NET 2.0 up to 4.5 - and all of them are superior to the .NET Core DLL as they provide an ADO.NET appender, for example. The assembly built here is only expected to be used for .NET Core. At least that's where I'd have expected it to get used.

@chlowell

@bodewig I chose the version number to prevent any confusion between prerelease and published packages. There's no reason not to change it before release.

I chose netstandard1.3 because it's the lowest version with the required APIs. Targeting a higher version than necessary generally brings no benefit. For example, UAP 10.0 (the current version) supports netstandard1.4. If log4net targets netstandard1.6, UWP apps won't be able to use it (at least, not without a hack). There's more on this in the docs.

There's no need to worry about overriding--a project targeting .NET Framework 4.5 or below won't use the netstandard1.3 assembly.

@NachbarsLumpi

So that means that the log4net assembly targeting .net core has the same capabilities like the one targeting the .net framework 4.6 and differs only in the fact that it targets .net core with netstandard1.3?

@chlowell

No, there are significant differences. My first post details some important ones.

.NET Framework 4.6 implements netstandard1.3. This means it exposes all the APIs specified by netstandard1.3 (and below). However, in terms of exposed APIs, netstandard1.3 is a subset of .NET Framework 4.6. The latter exposes many APIs not specified by the former.

@TAGC
TAGC commented Sep 13, 2016

How far along is the .NET Core migration? I'm planning to migrate one of my projects that currently targets .NET Framework 4.5.2 to .NET Core and one of its dependencies is Log4Net. I only use ColoredConsoleAppenders and RollingFileAppenders - are these still available in the version targeting .NET Core?

@chlowell

This code has been merged into trunk. To my knowledge there's no published package, but you can build one with the dotnet CLI.

ColoredConsoleAppender isn't available for .NET Core because it uses Win32 APIs. RollingFileAppender is available, with the caveat that its file locking doesn't work on Linux.

@TAGC
TAGC commented Sep 13, 2016 edited

Thanks for the info. ๐Ÿ‘

@bodewig
Member
bodewig commented Sep 14, 2016

Thank you very much @chlowell

@TAGC the code is in Apache's svn trunk and has been integrated with the build system by now. There are some lose ends and the biggest task is likely updating all documentation but I'm positive we aren't that far away from cutting the next release of log4net which will also include the .NET Core version. "not that far" may still get measured in weeks rather than days, though.

@wjdavis5

Hello, we are very patiently awaiting this next release. Thank you for putting this together.

@wjdavis5 wjdavis5 referenced this pull request in varshneyjayant/log4net-loggly Sep 27, 2016
Open

Updated References #26

@wjdavis5

Following the MSFT release yesterday - https://blogs.msdn.microsoft.com/dotnet/2016/09/26/introducing-net-standard/

It looks like this should be bumped to Net Standard 1.6
I did so locally and the build output is good, I'll PR back to this fork to hopefully get this PR updated.

@chlowell

Targeting netstandard1.6 here is more limiting than useful. Doing so would remove support for current UWP apps, and the larger API surface won't light up any major features.

@wjdavis5
wjdavis5 commented Sep 27, 2016 edited

Oh I see, I misread their chart. Thanks for clarifying.

@iby-dev
iby-dev commented Oct 3, 2016

Hi, do you guys have a release date for the new package? 2.0.6?

@NachbarsLumpi

It is done when it is done. If you need it anytime sooner, get involved.

On 3 Oct 2016 4:22 p.m., "Ibrar Mumtaz" notifications@github.com wrote:

Hi, do you guys have a release date for the new package? 2.0.6?

โ€”
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#16 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AIID6uKBzeKNLRNv1afKYssvwT7m16FCks5qwQ-ggaJpZM4GYooH
.

@derFunk
derFunk commented Oct 14, 2016

AFAIU it seems we could have a NuGet package release already, or at least a pre-release.
Is there anything else open we can help?
Unfortunately only the NuGet repo owner can push.

@bodewig
Member
bodewig commented Oct 14, 2016

log4net development is coordinated via the mailing list :-)

https://lists.apache.org/thread.html/3dafd7f063d6106ca9ca20379f5851a10e1588e9d1ce955d23e93a62@%3Clog4net-dev.logging.apache.org%3E

a test build has been available for about two weeks now, with nobody testing it, or so it seems.

@derFunk
derFunk commented Oct 14, 2016

@bodewig sorry for not using the mailing list ;) one last thing: I'd love to test basically right now. I don't have a public NuGet repo at hands, would it be possible for you to push it somewhere? NuGet.org/MyGet.org? I can test with my private repo until then, but it would be more convenient to have it publicly available.

GrรผรŸe aus Mรผnchen.

@bodewig
Member
bodewig commented Oct 14, 2016

@derFunk the mailing list comment was meant to say that there may be things going on that one might miss when not following the list. I must admit there isn't that much going on: https://blogs.apache.org/logging/entry/apache_log4net_needs_help

As for packages, I'm sorry, we're not prepared for that. We will be publishing the final release to nuget but the current test build looks like a real release internally, so we can't publish it there. I'd need to make myself familiar with myget first.

@bodewig
Member
bodewig commented Oct 14, 2016
@derFunk
derFunk commented Oct 14, 2016 edited

Awesome, thanks.

I shared your cry for help on Hacker News, maybe this gets some traction. Maybe you should also add log4net here: http://up-for-grabs.net/#/tags/logging to attract contributors.

@wjdavis5 wjdavis5 referenced this pull request in DataDog/dogstatsd-csharp-client Oct 21, 2016
Merged

[project] port to .NET Core #39

@SeanSnyders

@bodewig I've downloaded your 2.0.6 version from myget but get an exception thrown during init of my logger in a NetCoreApp 1.1.0 application targeting win10-x64.

Now, I'm a bit new to .Net Core, but my same code runs fine using latest 2.0.5 on .Net 4.6.1.

Any chance of getting a .pdb of 2.0.6 so I can dig a bit deeper into where the exception occur with a sensible stack trace?

At a high level, I get these:
image

in my code on line 176 here:
image

If I add the dependency of System.Collections.NonGeneric 4.3.0 to my project.json, I still get an exception of:
image

Is the nuget package for 2.0.6 specifying all the dependencies? What am I missing here?

@bodewig
Member
bodewig commented Nov 30, 2016

Many thanks @SeanSnyders . You are the first one actually given the binaries a try - or the first one who tells us so.

I've built the myget package using .NET Core 1.0.0 (SDK Preview 2), I really hope we don't need to provide assemblies built for different .NET Core 1.x versions.

As for dependencies of the package, I didn't add any for the .NET Core version, maybe I should have. To be honest I'm far from an expert WRT .NET Core.

A preview build of the traditional distributions can be found in http://stefan.samaflost.de/staging/log4net-2.0.6/log4net-2.0.6-bin-newkey.zip - this contains the pdb file.

@SeanSnyders

@bodewig Yeah, I'm also trying to get my head around .Net Core project setup. Things have been quite a bit in flux!

I think one will need to spec the dependencies, no? I could have it by the tail, though....
I'll try the other build you linked to as well.

@bodewig
Member
bodewig commented Nov 30, 2016

The nuspec doesn't list any dependencies, this is because all dependencies of log4net are part of the framework for the Mono and .NET versions.

Re-reading the nuspec schema we probably need to add a dependency group with the targetFramework set properly. I'll try to see what the nuspec created with dotnet pack looks like.

@bodewig
Member
bodewig commented Nov 30, 2016

I think c661441 holds the necessary changes. Unfortunately assembling the release bits for log4net still requires two different VMs and about an hour of time, so I may need a few days before I can re-create the package.

@bodewig
Member
bodewig commented Dec 2, 2016

@SeanSnyders I've updated the package at https://www.myget.org/feed/log4net-test/package/nuget/log4net (overwritten the original one)

@SeanSnyders

@bodewig Great, I'll try it again.

@SeanSnyders

@bodewig I can confirm that the dependencies now seem to be solved, thanks.

But I get that the my log file pattern does not seem to work using the envFolderPath

image

Is that a known issue? Any workarounds etc?

@bodewig
Member
bodewig commented Dec 4, 2016

Yes, that seems to be expected as src/Util/PatternStringConverters/EnvironmentFolderPathPatternConverter is among the excludes in https://github.com/apache/log4net/blob/trunk/netstandard/log4net/project.json#L32

We really need to document what is known to not work with .NET Core.

@SeanSnyders

Right, okay.
Yes a a list of things not working would be great.

@bodewig
Member
bodewig commented Dec 6, 2016

I've spelled out https://github.com/apache/log4net/blob/6e8c0db1407a398fa64d72f89cf6b460ad209808/src/site/xdoc/release/framework-support.xml#L578 which will become visible at http://logging.apache.org/log4net/release/framework-support.html once we cut the release. Also I'll make sure I list those limitations in the release notes and the announcement mail.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment