.NET Core 2.0 Preview 2

[leecow]

.NET Core 2.0.0 Preview 2 is available.

You can read about .NET Core 2.0.0 Preview 2 in the release notes and .NET blog announcement.

Please report any issues you find with .NET Core 2.0.0 Preview 2 here, either responding to this issue or creating a new issue.

Please note that this repo (dotnet/core) is not for filing product issues. Here are some repos where you can file an issue:

• dotnet/cli - for CLI tools and questions
• dotnet/corefx - for API issues and questions
• dotnet/coreclr - for runtime issues
• nuget/home - for NuGet questions and issues

[JeffreyMcBride]

dotnet --version
dotnet --info
dotnet --diagnostics

All work fine

dotnet -v
dotnet -i
dotnet -d

All return Unknown option even though help indicates

-v|--version
-i|--info
-d|--diagnostics

[Petermarcu]

@livarcocc , can you take a look?

[danwalmsley]

Since trying the preview2 building my project I get:

C:\dev\repos\AvalonStudio\AvalonStudio\AvalonStudio.Toolchains.LocalGCC\AvalonStudio.Toolchains.LocalGCC.csproj : error NU1003: PackageTargetFallback and AssetTargetFallback cannot be used together. Remove PackageTargetFallback(deprecated) references from the project environment. [C:\dev\repos\AvalonStudio\AvalonStudio\AvalonStudio\AvalonStudio.csproj]

I am referencing some .net 4.5 project and nugets, which has worked on preview 1, but now there is some asset fallback.

How do I make this work again?

[Petermarcu]

@rrelyea Can you give guidance on PTF and ATF?

[danwalmsley]

@Petermarcu ah I removed all in my project and it started to work again.

[Petermarcu]

@JeffreyMcBride , I have opened an issue in dotnet/cli to track your issue and mentioned you in it. Thanks.

[rrelyea]

@danwalmsley -
We have since improved that error to:
PackageTargetFallback is deprecated. Replace PackageTargetFallback references with AssetTargetFallback in the project environment.

More details...PackageTargetFallback worked like imports did in Project.json.
The teams have realized that our implementation of that wasn't ideal.
In order to not break old projects/packages -- we created AssetTargetFallback which is implicitly set for netcoreapp/netstandard2.0 projects via targets.
Some project templates, in the past, used PackageTargetFallback.
When upgrading those projects to v2.0, you end up with both PTF and ATF in effect. Thus we error.
Ideally, you just move to ATF from your existing PTF.

[cmaslen]

Not sure if this is the right place since this looks more like a VS issue but the following doesn't work after preview 2:

• Create ASP.NET Core Web project in VS 15.3.0 Preview 3.
• This defaults to targeting .NET Core 1.1.
• Open project properties and change project to target .NET Core 2.0

Building the project results in a bunch of package downgrade errors:

The work around is to manually edit the project file and change the dependencies as follows:
error NU1605: Detected package downgrade: System.Diagnostics.Tools from 4.3.0 to 4.0.1. Reference the package directly from the project to select a different version.
error NU1605: MVCPreview2App (>= 1.0.0) -> Microsoft.VisualStudio.Web.BrowserLink (>= 1.1.2) -> Microsoft.AspNetCore.Hosting.Abstractions (>= 1.1.2) -> NETStandard.Library (>= 1.6.1) -> System.Diagnostics.Tools (>= 4.3.0)
error NU1605: MVCPreview2App (>= 1.0.0) -> Microsoft.VisualStudio.Web.BrowserLink (>= 1.1.2) -> System.Diagnostics.Tools (>= 4.0.1)
error NU1605: Detected package downgrade: System.Net.Primitives from 4.3.0 to 4.0.11. Reference the package directly from the project to select a different version.
error NU1605: MVCPreview2App (>= 1.0.0) -> Microsoft.VisualStudio.Web.BrowserLink (>= 1.1.2) -> Microsoft.AspNetCore.Hosting.Abstractions (>= 1.1.2) -> NETStandard.Library (>= 1.6.1) -> System.Net.Primitives (>= 4.3.0)
error NU1605: MVCPreview2App (>= 1.0.0) -> Microsoft.VisualStudio.Web.BrowserLink (>= 1.1.2) -> System.Net.Primitives (>= 4.0.11)
error NU1605: Detected package downgrade: System.Net.Sockets from 4.3.0 to 4.1.0. Reference the package directly from the project to select a different version.
error NU1605: MVCPreview2App (>= 1.0.0) -> Microsoft.VisualStudio.Web.BrowserLink (>= 1.1.2) -> Microsoft.AspNetCore.Hosting.Abstractions (>= 1.1.2) -> NETStandard.Library (>= 1.6.1) -> System.Net.Sockets (>= 4.3.0)
error NU1605: MVCPreview2App (>= 1.0.0) -> Microsoft.VisualStudio.Web.BrowserLink (>= 1.1.2) -> System.Net.Sockets (>= 4.1.0)
error NU1605: Detected package downgrade: System.Diagnostics.Tools from 4.3.0 to 4.0.1. Reference the package directly from the project to select a different version.
error NU1605: MVCPreview2App (>= 1.0.0) -> Microsoft.VisualStudio.Web.BrowserLink (>= 1.1.2) -> Microsoft.AspNetCore.Http.Abstractions (>= 1.1.2) -> NETStandard.Library (>= 1.6.1) -> System.Diagnostics.Tools (>= 4.3.0)
error NU1605: MVCPreview2App (>= 1.0.0) -> Microsoft.VisualStudio.Web.BrowserLink (>= 1.1.2) -> System.Diagnostics.Tools (>= 4.0.1)
error NU1605: Detected package downgrade: System.Net.Primitives from 4.3.0 to 4.0.11. Reference the package directly from the project to select a different version.
error NU1605: MVCPreview2App (>= 1.0.0) -> Microsoft.VisualStudio.Web.BrowserLink (>= 1.1.2) -> Microsoft.AspNetCore.Http.Abstractions (>= 1.1.2) -> NETStandard.Library (>= 1.6.1) -> System.Net.Primitives (>= 4.3.0)
error NU1605: MVCPreview2App (>= 1.0.0) -> Microsoft.VisualStudio.Web.BrowserLink (>= 1.1.2) -> System.Net.Primitives (>= 4.0.11)
error NU1605: Detected package downgrade: System.Net.Sockets from 4.3.0 to 4.1.0. Reference the package directly from the project to select a different version.
error NU1605: MVCPreview2App (>= 1.0.0) -> Microsoft.VisualStudio.Web.BrowserLink (>= 1.1.2) -> Microsoft.AspNetCore.Http.Abstractions (>= 1.1.2) -> NETStandard.Library (>= 1.6.1) -> System.Net.Sockets (>= 4.3.0)
error NU1605: MVCPreview2App (>= 1.0.0) -> Microsoft.VisualStudio.Web.BrowserLink (>= 1.1.2) -> System.Net.Sockets (>= 4.1.0)
error NU1605: Detected package downgrade: System.Diagnostics.Tools from 4.3.0 to 4.0.1. Reference the package directly from the project to select a different version.
error NU1605: MVCPreview2App (>= 1.0.0) -> Microsoft.VisualStudio.Web.BrowserLink (>= 1.1.2) -> Microsoft.AspNetCore.Http.Extensions (>= 1.1.2) -> NETStandard.Library (>= 1.6.1) -> System.Diagnostics.Tools (>= 4.3.0)
error NU1605: MVCPreview2App (>= 1.0.0) -> Microsoft.VisualStudio.Web.BrowserLink (>= 1.1.2) -> System.Diagnostics.Tools (>= 4.0.1)
error NU1605: Detected package downgrade: System.Net.Primitives from 4.3.0 to 4.0.11. Reference the package directly from the project to select a different version.
error NU1605: MVCPreview2App (>= 1.0.0) -> Microsoft.VisualStudio.Web.BrowserLink (>= 1.1.2) -> Microsoft.AspNetCore.Http.Extensions (>= 1.1.2) -> NETStandard.Library (>= 1.6.1) -> System.Net.Primitives (>= 4.3.0)
error NU1605: MVCPreview2App (>= 1.0.0) -> Microsoft.VisualStudio.Web.BrowserLink (>= 1.1.2) -> System.Net.Primitives (>= 4.0.11)
error NU1605: Detected package downgrade: System.Net.Sockets from 4.3.0 to 4.1.0. Reference the package directly from the project to select a different version.
error NU1605: MVCPreview2App (>= 1.0.0) -> Microsoft.VisualStudio.Web.BrowserLink (>= 1.1.2) -> Microsoft.AspNetCore.Http.Extensions (>= 1.1.2) -> NETStandard.Library (>= 1.6.1) -> System.Net.Sockets (>= 4.3.0)
error NU1605: MVCPreview2App (>= 1.0.0) -> Microsoft.VisualStudio.Web.BrowserLink (>= 1.1.2) -> System.Net.Sockets (>= 4.1.0)
error NU1605: Detected package downgrade: System.Diagnostics.Tools from 4.3.0 to 4.0.1. Reference the package directly from the project to select a different version.
error NU1605: MVCPreview2App (>= 1.0.0) -> Microsoft.VisualStudio.Web.BrowserLink (>= 1.1.2) -> Microsoft.Extensions.FileProviders.Physical (>= 1.1.1) -> NETStandard.Library (>= 1.6.1) -> System.Diagnostics.Tools (>= 4.3.0)
error NU1605: MVCPreview2App (>= 1.0.0) -> Microsoft.VisualStudio.Web.BrowserLink (>= 1.1.2) -> System.Diagnostics.Tools (>= 4.0.1)
error NU1605: Detected package downgrade: System.Net.Primitives from 4.3.0 to 4.0.11. Reference the package directly from the project to select a different version.
error NU1605: MVCPreview2App (>= 1.0.0) -> Microsoft.VisualStudio.Web.BrowserLink (>= 1.1.2) -> Microsoft.Extensions.FileProviders.Physical (>= 1.1.1) -> NETStandard.Library (>= 1.6.1) -> System.Net.Primitives (>= 4.3.0)
error NU1605: MVCPreview2App (>= 1.0.0) -> Microsoft.VisualStudio.Web.BrowserLink (>= 1.1.2) -> System.Net.Primitives (>= 4.0.11)
error NU1605: Detected package downgrade: System.Net.Sockets from 4.3.0 to 4.1.0. Reference the package directly from the project to select a different version.
error NU1605: MVCPreview2App (>= 1.0.0) -> Microsoft.VisualStudio.Web.BrowserLink (>= 1.1.2) -> Microsoft.Extensions.FileProviders.Physical (>= 1.1.1) -> NETStandard.Library (>= 1.6.1) -> System.Net.Sockets (>= 4.3.0)
error NU1605: MVCPreview2App (>= 1.0.0) -> Microsoft.VisualStudio.Web.BrowserLink (>= 1.1.2) -> System.Net.Sockets (>= 4.1.0)
1>MVCPreview2App -> C:\gitcode\MVCPreview2App\MVCPreview2App\bin\Debug\netcoreapp2.0\MVCPreview2App.dll

The work around is to manually change the versions in the project file as follows

<ItemGroup>
    <PackageReference Include="Microsoft.ApplicationInsights.AspNetCore" Version="2.0.0" />
    <PackageReference Include="Microsoft.AspNetCore" Version="2.0.0-preview2-final" />
    <PackageReference Include="Microsoft.AspNetCore.Mvc" Version="2.0.0-preview2-final" />
    <PackageReference Include="Microsoft.AspNetCore.StaticFiles" Version="2.0.0-preview2-final" />
    <PackageReference Include="Microsoft.Extensions.Logging.Debug" Version="2.0.0-preview2-final" />
    <PackageReference Include="Microsoft.VisualStudio.Web.BrowserLink" Version="2.0.0-preview2-final" 
/>
</ItemGroup>

<ItemGroup>
    <DotNetCliToolReference Include="Microsoft.VisualStudio.Web.CodeGeneration.Tools" Version="2.0.0-preview2-final" />
</ItemGroup>

[Petermarcu]

Yeah, migration from asp.net core 1.X to 2.0 isn't as simple as just changing the target framework. @DamianEdwards are there any docs that tell people what to do. This issue may be better on the aspnet/home repo.

[DamianEdwards]

The migration docs for ASP.NET Core are in progress and will be done by the time we ship 2.0.0 RTW.

[WillooWisp]

Running a self-contained netcoreapp2.0 preview 2 on arm (RPI2) gives me this exception now matter what I do or what references I try to update.
Could not load file or assembly 'System.Private.ServiceModel, Version=4.1.2.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. The system cannot find the file specified.

[Petermarcu]

@WillooWisp , can you share your project? Are you referencing WCF? The trick will be figuring out which assembly you are pulling in that has that references to that assembly.

[ed-ilyin]

after I have upgraded from preview1 dotnet restore and dotnet fable yarn-run split-server takes minutes before anything appear on screen or hangs on macOs and Windows.
fable-compiler/Fable#1042

[dsyme]

Actually its hangs for long long time (on MacOs and on Windows)

I also have one Windows 10 machine where "dotnet restore" hangs indefinitely with the latest preview installed. It works on my other Windows 10 machine. I have no idea why it hangs - it seems a network request is just timing out indefinitely. No proxy involved. I tried resetting my firewall settings but that didn't seem to help.

[Petermarcu]

@rrelyea for the dotnet restore issue.

[WillooWisp]

@Petermarcu I cannot share the project, but I can try to reproduce it, my guess is that it might be due to referencing the Microsoft.AspNet.WebApi.Client 5.2.3, but I have tried the Microsoft.AspNet.WebApi.Client 5.2.4-alpha1-170629 as well without any difference. It is only a problem on arm, not on windows.

[WillooWisp]

@Petermarcu No that was a wrong guess from my side, removed the WebApi.Client dependency and commented out all code related to that. Still get: Could not load file or assembly 'System.Private.ServiceModel, Version=4.1.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. The system cannot find the file specified.

[richlander]

I moved the dotnet restore issue to #724. Let's discuss there.

[WillooWisp]

@Petermarcu I finally nailed it down to this line of code, throw new CommunicationException. When referencing CommunicationException in the code I get the "Could not load file or assembly 'System.Private.ServiceModel, Version=4.1.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'" when running the console app, otherwise not.

[rmunn]

https://github.com/dotnet/cli/issues/6286 (which is ultimately caused by NuGet/Home#4424 according to the comments in that thread) appears to not be fixed yet in preview2: I was able to reproduce that bug in TheAngryByrd/MiniScaffold#19. See NuGet/Home#4424 (comment) for specific version details of when that NuGet bug was fixed (in a commit that does not appear to have been included into dotnet preview2).

[richlander]

@livarcocc the comment by @rmunn seems like something we should get into preview3 ASAP. Yes?

[livarcocc]

@mlorbetske I wonder if this is actually an issue in dotnet new. Since it happens during dotnet new when instantiating the template. Mike, can you take a look?

[mlorbetske]

@livarcocc reading through the comments, there seems to be a variety of things being discussed - which thing is happening while instantiating templates?

[richlander]

@mlorbetske I assume @livarcocc is referriung to #711 (comment). Same as https://github.com/dotnet/cli/issues/6286.

[mlorbetske]

@livarcocc created dotnet/templating#1028 for the dotnet new file permissions issue

[Petermarcu]

That is a good place to report. If its clear which layer of the stack the problem is in, filing it in the matching repo can also work but it requires more knowledge of how the product is built. Reporting more details here can also work and we can help route.

[JeffreyMcBride]

@Petermarcu Thanks. Quick version, I can provide more detail if appropriate. VS2017 appears not to use dotnet publish for its publishing process. When I publish a web app using a win10-x64 RID SCD profile with VS2017 15.3 P7, no EXE is produced to start Kestrel in lieu of dotnet run. But dotnet publish --runtime win10-x64 does produce .exe, and it can start the app fine.

[Petermarcu]

@barrytang @livarcocc can you help look into issues with Publish from VS?

[JeffreyMcBride]

@Petermarcu FYI, I ran a class last week using ASP.NET Core 2 preview 2. Almost everything was fine!
3 issues:

1. .exe publish issue above
2. IsolatedScopes=true did not append the extra logging info with
   using (_logger.BeginScope("Message to append")) { // code and logging statements }
3. Installing controller scaffolding creates an error then a warning:
   Error: Microsoft.VisualStudio.Web.CodeGeneration.Design package targeting v2.0.0 (final release)
   Downgrading to v2.0.0-preview fixes issue and eliminates error
   Warning: Microsoft.Composition 1.0.27 is targeting .NET Framework
   Upgrading to 1.0.30 (or now 1.0.31) targets Core and eliminates warning

Not bad for preview version...

[barrytang]

I believe the publish issue is a .NET Core CLI issue. @livarcocc is currently on vacation. @nguerrera, are you right guy to take a look on Livar's absence? Adding @MattGertz as well.

@prafullbhosale, can you take a look at the Scaffolding issue above? Adding @mlorbetske as well.

[nguerrera]

@barrytang Happy to help however I can. The description of the publish issue mentions things working on the command line but not with VS: #711 (comment). Is there a way to get the msbuild invocation that VS uses when publishing? I would like to understand how it might be different from the dotnet publish command that is working.

[barrytang]

The description of the publish issue mentions things working on the command line but not with VS: #711 (comment).

Sorry, I missed that. @vijayrkn, can you take a look?

[prafullbhosale]

Installing controller scaffolding creates an error then a warning:
Error: Microsoft.VisualStudio.Web.CodeGeneration.Design package targeting v2.0.0 (final release)

This should no longer be happening as the 2.0.0 version of the package is available on NuGet.org.

[vijayrkn]

@JeffreyMcBride I just tried publishing a netcoreapp2.0 (empty web app) with win10-x64 rid from VS & it created an exe in the publish output folder. This is the sample project that I tried- https://github.com/vijayrkn-test/netcoreapp20_win10_x64/blob/master/WebApplication1/WebApplication1.csproj

Would it be possible to provide a sample project where publish from VS is not working correctly? I would be happy to take a look.

[patricksuo]

visual studio freeze ~15 seconds when:

1. switch git branch from command line
2. add/remove file/dir from solution resource manager

project size: 900 cs file / 200k LOC

dotnet --info:

.NET Command Line Tools (2.0.0-preview2-006497)

Product Information:
 Version:            2.0.0-preview2-006497
 Commit SHA-1 hash:  06a2093335

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.15063
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\2.0.0-preview2-006497\

Microsoft .NET Core Shared Framework Host

  Version  : 2.0.0-preview2-25407-01
  Build    : 40c565230930ead58a50719c0ec799df77bddee9

visual studio version:

Microsoft Visual Studio Community 2017 Preview
Version 15.3.0 Preview 5.0
VisualStudio.15.Preview/15.3.0-pre.5.0+26720.2
Microsoft .NET Framework
Version 4.7.02046

[JeffreyMcBride]

@vijayrkn Please find a solution with 3 projects, an Empty Web App, Web API, and Web App (MVC) at this location:
https://github.com/JeffreyMcBride/ASPNETCore2PreviewTemplates

These are unmodified project templates created using VS2017 15.3 Preview 7. I left the bin, obj, and wwwroot/lib folders as is so its a bit big. But wanted you to see the output from the publish I did on each of the 3 projects. No .EXE created on any of the 3. This is not the solution I originally noticed the issue, and I can push that as well but since these were clean I thought they would be more useful. Please note the other solution has multiple projects in it as well, MVC, Web API, and Class Library (Core), not sure if that is related.

Jeff

[vijayrkn]

@JeffreyMcBride
The publish profiles were missing the RuntimeIdentifier which was causing the issue:

Can you please add this to all the publish profiles?

<RuntimeIdentifier>win10-x64</RuntimeIdentifier>

https://github.com/JeffreyMcBride/ASPNETCore2PreviewTemplates/blob/master/01%20Empty/Properties/PublishProfiles/FolderProfile.pubxml

https://github.com/JeffreyMcBride/ASPNETCore2PreviewTemplates/blob/master/02%20Web%20API/Properties/PublishProfiles/FolderProfile.pubxml

https://github.com/JeffreyMcBride/ASPNETCore2PreviewTemplates/blob/master/03%20Web%20Application/Properties/PublishProfiles/FolderProfile.pubxml

Alternatively, if you are planning to have only 1 RID, then you can update the 'RuntimeIdentifiers' to 'RuntimeIdentifier' in the csproj and that should also work.

[JeffreyMcBride]

@vijayrkn Interesting results. Before I changed anything, I checked the Publish Profile Dialog Box | Settings options, and it showed that the profile was set to use win10-x64 as the RID, even though as you pointed out, there is no <RuntimeIdentifier>win10-x64</RuntimeIdentifier> in the PUBXML. See link for image:
https://github.com/JeffreyMcBride/ASPNETCore2PreviewTemplates/blob/master/PublishProfileDialogBeforeEditingPUBXML.png

Then I tried changing the CSPROJ to use <RuntimeIndentifer>win10-x64</RuntimeIdentifier>. This did produce an .EXE file, but curiously there was no <RuntimeIndentifer>win10-x64</RuntimeIdentifier> added to the .PUBXML. The Publish Profile Dialog | Settings again indicated that it was using the win10-x64 RID.

Then I changed the CSPROJ to use <RuntimeIdentifiers>win10-x64;osx.10.11-x64</RuntimeIdentifiers>. This did not produce an .EXE file and again no runtime was listed in the .PUBXML. The Publish Profile Dialog | Settings again indicated it was using win10-x64 RID.

I then changed Publish Profile Dialog | Settings to use the osx.10.11-x64 RID, but did not actually publish since .EXE wouldn't necessarily be produced for this RID, and I verified that the PUBXML now had <RuntimeIdentifier>osx.10.11-x64</RuntimeIdentifier>. If I then changed the setting back to win10-x64 RID, the PUBXML also had <RuntimeIdentifier>win10-x64</RuntimeIdentifier>. And this did produce an .EXE file.

So the issue seems to be with CSPROJ <RuntimeIndentifiers> not adding the appropriate RID to the PUBXML initially but will if you manually change the runtime setting, and CSPROJ <RuntimeIndentifier> doesn't seem to need to in order to produce the .EXE file.

[vijayrkn]

Then I tried changing the CSPROJ to use win10-x64. This did produce an .EXE file, but curiously there was no win10-x64 added to the .PUBXML.

This is the expected behavior. We don't write the RuntimeIndentifer to the pubxml if it is already present in the csproj. The pubxml automatically gets all the properties from the csproj since pubxml is an msbuild file.

From the description of the issue, It looks like there is still an issue here with the publish settings RID dropdown that it is not writing the RID to the pubxml unless a value is changed in the dropdown. We will investigate this issue. As a work-around , you can add the RID to the pubxml and publish from VS should work as expected. Thanks for reporting this issue.

[JeffreyMcBride]

@vijayrkn Thanks for taking the time to troubleshoot it with me and giving me some more insight into the inner workings of VS Publish.

Question if I may? Is VS using dotnet publish behind the scenes? Based on our findings, I'm thinking the difference between it not working in VS and the same project producing an EXE using dotnet publish is that I did not provide it a profile but instead specified a runtime directly dotnet publish --runtime win10-x64. Is that correct? Is there a way to pass a PUBXML to dotnet.exe?

[vijayrkn]

Is VS using dotnet publish behind the scenes?

VS does not call 'dotnet publish' directly, but uses the same set of targets that 'dotnet publish' uses. VS publish and dotnet publish should behave the same when the same set of parameters are passed to it.

In this case, a specific runtime property was passed to 'dotnet publish' from commandline but from VS this property was not passed

I did not provide it a profile but instead specified a runtime directly dotnet publish --runtime win10-x64. Is that correct? Is there a way to pass a PUBXML to dotnet.exe?

Both are fine. You can pass the properties directly to 'dotnet publish' or you can pass a profile to 'dotnet publish'. Passing the profile to dotnet publish is only supported for web projects.

for e.g: if you want to publish your web app to azure from commandline, then you can use

dotnet publish <webapp>.csproj /p:PublishProfile=<AzureProfile> /p:Password=<DeploymentPassword>

You can find samples of profiles here https://github.com/aspnet/websdk#microsoftnetsdkpublish. The above command will look for a profile named 'AzureProfile.pubxml' in Properties\PublishProfiles\

[Petermarcu]

@JeffreyMcBride thanks for providing the feedback. I was off the grid for the past couple of weeks and didn't get a chance to respond. Looks like your first issue is now understood. @barrytang and @Eilon who is the best person to take a look at the other two issues? Should we get them filed in a difference repo to make them easier to track?

2. IsolatedScopes=true did not append the extra logging info with
   using (_logger.BeginScope("Message to append")) { // code and logging statements }
3. Installing controller scaffolding creates an error then a warning:
   Error: Microsoft.VisualStudio.Web.CodeGeneration.Design package targeting v2.0.0 (final release)
   Downgrading to v2.0.0-preview fixes issue and eliminates error
   Warning: Microsoft.Composition 1.0.27 is targeting .NET Framework
   Upgrading to 1.0.30 (or now 1.0.31) targets Core and eliminates warning

[vdrasutis]

Using latest .NetCore:

C:\Users\dra60074\Dropbox\Temp\SV_ETL\SV_.NET\SingleView\Source>dotnet --version
2.0.0

Code compiles, but when I try to run it throws an error:

...\AlertManager.csproj : error NU1605: Detected package downgrade: System.Net.NameResolution from 4.3.
0 to 4.0.0. Reference the package directly from the project to select a different version. \r [AAA.sln]
...\Source\src\AlertManager\AlertManager.csproj : error NU1605:  AlertManager (>= 1.0.0) -> SingleView.Logging (>= 1.0.0) -> lo
g4net (>= 2.0.8) -> System.Net.Sockets (>= 4.1.0) -> runtime.win.System.Net.Sockets (>= 4.3.0) -> System.Net.NameResolution (>= 4.3.0) \r [..AAA.sln]
...\Source\src\AlertManager\AlertManager.csproj : error NU1605:  AlertManager (>= 1.0.0) -> SingleView.Logging (>= 1.0.0) -> lo
g4net (>= 2.0.8) -> System.Net.NameResolution (>= 4.0.0) [AAA.sln]
...\Source\src\AlertManager\AlertManager.csproj : error NU1605: Detected package downgrade: System.Net.Primitives from 4.3.0 to
 4.0.11. Reference the package directly from the project to select a different version. \r [AAA.sln]
...\Source\src\AlertManager\AlertManager.csproj : error NU1605:  AlertManager (>= 1.0.0) -> AAA.Logging (>= 1.0.0) -> lo
g4net (>= 2.0.8) -> System.Net.Sockets (>= 4.1.0) -> runtime.win.System.Net.Sockets (>= 4.3.0) -> System.Net.Primitives (>= 4.3.0) \r [AAA.sln]
...\Source\src\AlertManager\AlertManager.csproj : error NU1605:  AlertManager (>= 1.0.0) -> AAA.Logging (>= 1.0.0) -> lo
g4net (>= 2.0.8) -> System.Net.Sockets (>= 4.1.0) -> System.Net.Primitives (>= 4.0.11) [AAA.sln]

I want to implement/use Log4Net logger (v2.0.8).
VS version 15.3.2.
Please help how to resolve this.

[nguerrera]

@Drasius2 That error is from nuget restore, which happens before compilation, not after it. It is saying that there are indirect references to both v4.0.0 and v4.3.0 of System.Net.NameResolution, and the lower v4.0.0 was chosen because it is "nearer" to your project. Similarly for v4.0.11 and v4.1.0 of System.Net.Primitives. In previous versions of the .NET Core SDK, this would have been treated as a warning, but in 2.0 it is an error by default.

You can get back to the v1 warning only behavior by removing NU1605 from the warnings treated as error in the project property pages. But instead of doing that, we should get to the root cause and fix it.

This case is a little odd with the runtime.* 4.3.0 packages getting pulled in somehow without their non runtime.* companions. Can you share AlertManager.csproj so that I can see how that is happening and help you determine the best fix?

[barrytang]

Installing controller scaffolding creates an error then a warning:
Error: Microsoft.VisualStudio.Web.CodeGeneration.Design package targeting v2.0.0 (final release)
Downgrading to v2.0.0-preview fixes issue and eliminates error
Warning: Microsoft.Composition 1.0.27 is targeting .NET Framework
Upgrading to 1.0.30 (or now 1.0.31) targets Core and eliminates warning

@prafullbhosale , can you take a look?

[prafullbhosale]

Installing controller scaffolding creates an error then a warning:
Error: Microsoft.VisualStudio.Web.CodeGeneration.Design package targeting v2.0.0 (final release)
Downgrading to v2.0.0-preview fixes issue and eliminates error
Warning: Microsoft.Composition 1.0.27 is targeting .NET Framework
Upgrading to 1.0.30 (or now 1.0.31) targets Core and eliminates warning

@prafullbhosale , can you take a look?

I did comment about this earlier : #711 (comment)
This should be fixed already as 2.0 (final) packages are available on NuGet.org

Are you still seeing this issue?

[Eilon]

@muratg - who can look at the logging BeginScopes issue mentioned at #711 (comment) ?

[muratg]

@pakrym, could you take a look at that issue and file a bug for tracking it further?

[pakrym]

@muratg I suspect IsolatedScopes=true is IncludeScopes=true if so it's aspnet/Logging#643

[Petermarcu]

I think this issue has run it's course. We've shipped RTM. Any new issues that come up should be opened in the appropriate repo and be focused on that issue.