Number one in using latest tools and contributing to projects with your expertise 👍

Just to avoid confusion I would rename this PR as "VS 2017 and .NET Standard 2.0"

@luigiberrettini You can now play around with this nuget-package:

https://ci.appveyor.com/project/nlog/nlog/build/4.5.0-beta5831/artifacts

@304NotModified It would be nice if this PR is merged before any other PR (When it looks stable), as the conflict rate is quite high with this one. So please delay any merging of any other PR.

Codecov Report

Merging #2263 into master will increase coverage by <1%.
The diff coverage is 60%.

@@           Coverage Diff           @@
##           master   #2263    +/-   ##
=======================================
+ Coverage      82%     82%   +<1%     
=======================================
  Files         304     304            
  Lines       21312   21374    +62     
  Branches     2570    2576     +6     
=======================================
+ Hits        17407   17463    +56     
- Misses       3250    3256     +6     
  Partials      655     655

@304NotModified Seems that the AppVeyor-build-image for VS2017 includes NetCore2, but VS2017 has dropped support for Silverlight. And the AppVeyor-build-image for VS2015 does not include NetCore 2.0 SDK.

Any ideas how to solve this? Moving forward without Silverlight ? Am I missing a magic parameter?

Seems I found the solution. Just needed to specify some extra magic parameters for the Silverlight and Windows Phone build. New Nuget-package ready:

https://ci.appveyor.com/project/nlog/nlog/build/4.5.0-beta5853/artifacts

As for SandCastle I think you cannot put everything in this PR: you should guarantee the current behavior not the hoped future one 😉

It should be enough to keep Sandcastle Help File Builder files in NLog\src\Docs\Frameworks and enable building docs as it is done now, as @304NotModified explains in #655, with something like:

msbuild NLog.proj /t:rebuild /t:BuildIndividualDocumentation /p:BuildLastMajorVersion=4.0.0 /p:AssemblyFileVersion=4.1.2 /p:BuildVersion=4.1.2 /p:configuration=release /p:BuildLabelOverride=NONE

which relies on the target:

<Target Name="BuildIndividualDocumentation">
    <Exec Command='"$(WinDir)\Microsoft.NET\Framework\v3.5\MSBuild.exe" Docs\NLog.shfbproj /p:Framework="%(TargetFramework.Identity)" /p:Configuration=$(Configuration) /p:BuildLabel="$(BuildLabel)" /p:BuildVersion="$(BuildVersion)"' ContinueOnError="$(BuildAllFrameworks)" />
</Target>

A developer working on #655 will then start from master improving docs on the base of the work merged from this PR

Made a very crude comparison of build-timings:

Maybe xunit ver. 1.9.1 is faster than xunit ver. 2.3 BETA ? OpenCover is using the same configuration and same test-runner, and the only difference is that the NLogUnitTest-dll depends on xUnit ver. 2.3 (instead of xUnit ver. 1.9)

xunit/xunit#353

Can see that "UnitTest - Net45 Release" in older builds took 284 sec (2221 tests), so dotnet test doesn't seem faster (But it is also just a wrapper around xUnit 2.3)

any idea why this error is red?

Made a very crude comparison of build-timings:

Thanks, I think the xunit warnings aren't helping

@304NotModified any idea why this error is red?

Nope. But it seems the console-output from the unit-tests is now flowing into the normal test-runner-output (change from xUnit ver. 1.9.1 to 2.3). And when using Console.Error, then it becomes red.

OK, double checked the packages. Looks good!

Last question, any idea why appveyor shows only 4291 unit tests? It should be +8000 ?

Last question, any idea why appveyor shows only 4291 unit tests? It should be +8000 ?

No idea how xUnit and AppVeyor is working together. Will try and change my net35 + net40 hack, so it doesn't reuse the same net452-FilePath for the 3 tests (net452, net40-client + net35)

Seems the AppVeyor-logic for xUnit has two identifiers for the unit-test-assembly-name (HandleTestAssemblyStarting):

• FileName of the unit-test-dll (Cannot change this because of InternalsVisibleTo)
• TargetFrameworkAttribute of the unit-test-dll (Will require artificial build of net461 and net462, so it differs from net452)

Little annoying it is not possible to reuse the same unit-test-dll with different configuration options (and add a prefix/suffix to the unit-test-assembly-name.

FileName of the unit-test-dll (Cannot change this because of InternalsVisibleTo)

Can't we add multiple InternalsVisibleTo attributes?

Well we can add multiple InternalsVisibleTo attributes?

Sure make a PR, that works, then I will merge it into this. Or you can just do it after having merged this to master :)

The PowerShell error is caused by the launch of an external command and the handling of streams:
http://mnaoumov.wordpress.com/2015/01/11/execution-of-external-commands-in-powershell-done-right/

The PowerShell error is caused by the launch of an external command and the handling of stream

Trying a newer version of xunit.console.runner, instead of the one provided by AppVeyor. Maybe it is better at shielding the PowerShell from the rogue NLog-Unit-Tests. ** Update ** Nope didn't help

Have now fixed the rogue NLog UnitTests that spat into Console.Error and Console.Out. Now the PowerShell can sleep at night.

As for snippets:

• VSIntegration contains files from 6 years ago
• uninstall is manual
• they should definitely be moved to another repo those build creates a NuGet package that people interested in snippets can download and use (maybe snipppets fro mi the NLog repo can be merged with what has been done I need the NLogSnippetsVSIX repo)

Since snippets are six years old I suppose they are not updated on each release and this PR could ignore including their NuGet package creation, but this should be confirmed by @304NotModified 😉

Since snippets are six years old I suppose they are not updated on each release and this PR could ignore including their NuGet package creation, but this should be confirmed by @304NotModified 😉

yes we could ignore the Vsintergration now. Will check this in the list

reminder for myself

• tests results summary on Appveyor: "Total tests:" (1x) and "=== TEST EXECUTION SUMMARY ==" (3x)
• tests results summary on Travis: "Total tests:" (1x) and "=== TEST EXECUTION SUMMARY ==" (1x)

merged! Great job @snakefoot ! thanks! thanks @luigiberrettini ! 🎉

@304NotModified Glad it is done. Not a funny PR to get through. Lots of old skeletons suddenly came jumping out of the closet. And the VS2017 tooling was not super obvious when all sources were saying "always use the new dotnet command".

I guess we should checkout if nUnit or MsTest2 (or something else) would perform better than xUnit, so the build-time could be reduced.

I think we could win some time by disabling the xunit warnings (could be disabled I assume). Also the build log is then more readable ;)

Hi all.
Sorry if this is a stupid question.
I'm working right now in a .Net Standard 2.0 project. So I would need use this last NLog version supporting it.
But looking in Nuget gallery I see the package NLog.Web.AspNetCore is not updated since more than 3 months ago, so it obviously doesn't contain all this new stuff.

Do you have in mind upload it? How could I use it in the meantime? Am I forced to include the libraries inside my project? Thank yoj.

@304NotModified I think we could win some time by disabling the xunit warnings (could be disabled I assume).

I think the reason for the slower builds is the change to VS2017 AppVeyor-Build-Image. These are the build-timings on Travis, before and after the change to VS2017:

Before: https://travis-ci.org/NLog/NLog/builds/262388322 - 82.205 (NLog.UnitTests Total: 2042)
After: https://travis-ci.org/NLog/NLog/builds/280157224 - 85.508s (NLog.UnitTests Total: 2135)

Maybe the AppVeyor-build-servers that supports VS2017-images are configured differently?

at least 2017 preview is slower: source