Core: .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.
https://github.com/fable-compiler/Fable/issues/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 https://github.com/NuGet/Home/issues/4424 according to the comments in that thread) appears to not be fixed yet in preview2: I was able to reproduce that bug in https://github.com/TheAngryByrd/MiniScaffold/issues/19. See https://github.com/NuGet/Home/issues/4424#issuecomment-307315106 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 https://github.com/dotnet/core/issues/711#issuecomment-312776555. Same as https://github.com/dotnet/cli/issues/6286.

[mlorbetske]

@livarcocc created https://github.com/dotnet/templating/issues/1028 for the dotnet new file permissions issue

[egilh]

Encountering error when trying to install Setting up dotnet-sdk-2.0.0-preview2-006497 on a Ubuntu 16.04 based machine having fish installed as default shell:

$ sudo apt install dotnet-sdk-2.0.0-preview2-006497 
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Starting pkgProblemResolver with broken count: 0
Starting 2 pkgProblemResolver with broken count: 0
Done
The following additional packages will be installed:
  dotnet-host dotnet-hostfxr-2.0.0-preview2-25407-01 dotnet-runtime-2.0.0-preview2-25407-01 liblttng-ust-ctl2
  liblttng-ust0 liburcu4
The following NEW packages will be installed:
  dotnet-host dotnet-hostfxr-2.0.0-preview2-25407-01 dotnet-runtime-2.0.0-preview2-25407-01
  dotnet-sdk-2.0.0-preview2-006497 liblttng-ust-ctl2 liblttng-ust0 liburcu4
0 upgraded, 7 newly installed, 0 to remove and 0 not upgraded.
Need to get 104 MB of archives.
After this operation, 293 MB of additional disk space will be used.
Do you want to continue? [Y/n] y
Get:1 http://no.archive.ubuntu.com/ubuntu xenial/universe amd64 liburcu4 amd64 0.9.1-3 [47,3 kB]
Get:2 http://no.archive.ubuntu.com/ubuntu xenial/universe amd64 liblttng-ust-ctl2 amd64 2.7.1-1 [72,2 kB]
Get:3 http://no.archive.ubuntu.com/ubuntu xenial/universe amd64 liblttng-ust0 amd64 2.7.1-1 [127 kB]
Get:4 https://apt-mo.trafficmanager.net/repos/dotnet-release xenial/main amd64 dotnet-host amd64 2.0.0-preview2-25407-01-1 [36,5 kB]
Get:5 https://apt-mo.trafficmanager.net/repos/dotnet-release xenial/main amd64 dotnet-hostfxr-2.0.0-preview2-25407-01 amd64 2.0.0-preview2-25407-01-1 [134 kB]
Get:6 https://apt-mo.trafficmanager.net/repos/dotnet-release xenial/main amd64 dotnet-runtime-2.0.0-preview2-25407-01 amd64 2.0.0-preview2-25407-01-1 [18,5 MB]
Get:7 https://apt-mo.trafficmanager.net/repos/dotnet-release xenial/main amd64 dotnet-sdk-2.0.0-preview2-006497 amd64 2.0.0-preview2-006497-1 [85,0 MB]
Fetched 104 MB in 1min 9s (1 489 kB/s)                                                                         
Selecting previously unselected package dotnet-host.
(Reading database ... 206889 files and directories currently installed.)
Preparing to unpack .../dotnet-host_2.0.0-preview2-25407-01-1_amd64.deb ...
Unpacking dotnet-host (2.0.0-preview2-25407-01-1) ...
Selecting previously unselected package dotnet-hostfxr-2.0.0-preview2-25407-01.
Preparing to unpack .../dotnet-hostfxr-2.0.0-preview2-25407-01_2.0.0-preview2-25407-01-1_amd64.deb ...
Unpacking dotnet-hostfxr-2.0.0-preview2-25407-01 (2.0.0-preview2-25407-01-1) ...
Selecting previously unselected package liburcu4:amd64.
Preparing to unpack .../liburcu4_0.9.1-3_amd64.deb ...
Unpacking liburcu4:amd64 (0.9.1-3) ...
Selecting previously unselected package liblttng-ust-ctl2:amd64.
Preparing to unpack .../liblttng-ust-ctl2_2.7.1-1_amd64.deb ...
Unpacking liblttng-ust-ctl2:amd64 (2.7.1-1) ...
Selecting previously unselected package liblttng-ust0:amd64.
Preparing to unpack .../liblttng-ust0_2.7.1-1_amd64.deb ...
Unpacking liblttng-ust0:amd64 (2.7.1-1) ...
Selecting previously unselected package dotnet-runtime-2.0.0-preview2-25407-01.
Preparing to unpack .../dotnet-runtime-2.0.0-preview2-25407-01_2.0.0-preview2-25407-01-1_amd64.deb ...
Unpacking dotnet-runtime-2.0.0-preview2-25407-01 (2.0.0-preview2-25407-01-1) ...
Selecting previously unselected package dotnet-sdk-2.0.0-preview2-006497.
Preparing to unpack .../dotnet-sdk-2.0.0-preview2-006497_2.0.0-preview2-006497-1_amd64.deb ...
Unpacking dotnet-sdk-2.0.0-preview2-006497 (2.0.0-preview2-006497-1) ...
Processing triggers for man-db (2.7.5-1) ...
Processing triggers for libc-bin (2.23-0ubuntu9) ...
Setting up dotnet-host (2.0.0-preview2-25407-01-1) ...
Setting up dotnet-hostfxr-2.0.0-preview2-25407-01 (2.0.0-preview2-25407-01-1) ...
Setting up liburcu4:amd64 (0.9.1-3) ...
Setting up liblttng-ust-ctl2:amd64 (2.7.1-1) ...
Setting up liblttng-ust0:amd64 (2.7.1-1) ...
Setting up dotnet-runtime-2.0.0-preview2-25407-01 (2.0.0-preview2-25407-01-1) ...
Setting up dotnet-sdk-2.0.0-preview2-006497 (2.0.0-preview2-006497-1) ...
This software may collect information about you and your use of the software, and send that to Microsoft.
Please visit http://aka.ms/dotnet-cli-eula for more information.
Welcome to .NET Core!
---------------------
Learn more about .NET Core @ https://aka.ms/dotnet-docs. Use dotnet --help to see available commands or go to https://aka.ms/dotnet-cli-docs.

.NET Core Tools Telemetry
--------------
The .NET Core Tools include a telemetry feature that collects usage information. It is important that the .NET Team understands how the tools are being used so that we can improve them.

The data collected is anonymous and will be published in an aggregated form for use by both Microsoft and community engineers under the Creative Commons Attribution License.

The .NET Core Tools telemetry feature is enabled by default. You can opt-out of the telemetry feature by setting an environment variable DOTNET_CLI_TELEMETRY_OPTOUT (for example, 'export' on macOS/Linux, 'set' on Windows) to true (for example, 'true', 1). You can read more about .NET Core tools telemetry at https://aka.ms/dotnet-cli-telemetry.
Initializing new SSH agent ...
succeeded
fish: Unknown command 'nice_hostname'
~/.config/fish/functions/start_agent.fish (line 1): nice_hostname
                                                    ^
in command substitution
        called on line 1 of file ~/.config/fish/functions/start_agent.fish

in function “start_agent”
        called on line 19 of file ~/.config/fish/config.fish

from sourcing file ~/.config/fish/config.fish
        called during startup

Unsupported use of '||'. In fish, please use 'COMMAND; or COMMAND'.
fish: dotnet new > /dev/null 2>&1 || true
                                   ^
dpkg: error processing package dotnet-sdk-2.0.0-preview2-006497 (--configure):
 subprocess installed post-installation script returned error exit status 127
Processing triggers for libc-bin (2.23-0ubuntu9) ...
Errors were encountered while processing:
 dotnet-sdk-2.0.0-preview2-006497
E: Sub-process /usr/bin/dpkg returned an error code (1)

Unlike preview1, it doesn't help to change to bash as long as fish is default:

$ bash
egil@egil-XPS:~/$ sudo apt install dotnet-sdk-2.0.0-preview2-006497 
Reading package lists... Done
Building dependency tree       
Reading state information... Done
dotnet-sdk-2.0.0-preview2-006497 is already the newest version (2.0.0-preview2-006497-1).
Starting pkgProblemResolver with broken count: 0
Starting 2 pkgProblemResolver with broken count: 0
Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
1 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n] y
Setting up dotnet-sdk-2.0.0-preview2-006497 (2.0.0-preview2-006497-1) ...
This software may collect information about you and your use of the software, and send that to Microsoft.
Please visit http://aka.ms/dotnet-cli-eula for more information.
Welcome to .NET Core!
---------------------
Learn more about .NET Core @ https://aka.ms/dotnet-docs. Use dotnet --help to see available commands or go to https://aka.ms/dotnet-cli-docs.

.NET Core Tools Telemetry
--------------
The .NET Core Tools include a telemetry feature that collects usage information. It is important that the .NET Team understands how the tools are being used so that we can improve them.

The data collected is anonymous and will be published in an aggregated form for use by both Microsoft and community engineers under the Creative Commons Attribution License.

The .NET Core Tools telemetry feature is enabled by default. You can opt-out of the telemetry feature by setting an environment variable DOTNET_CLI_TELEMETRY_OPTOUT (for example, 'export' on macOS/Linux, 'set' on Windows) to true (for example, 'true', 1). You can read more about .NET Core tools telemetry at https://aka.ms/dotnet-cli-telemetry.
Unsupported use of '||'. In fish, please use 'COMMAND; or COMMAND'.
fish: dotnet new > /dev/null 2>&1 || true
                                   ^
dpkg: error processing package dotnet-sdk-2.0.0-preview2-006497 (--configure):
 subprocess installed post-installation script returned error exit status 127
Errors were encountered while processing:
 dotnet-sdk-2.0.0-preview2-006497
E: Sub-process /usr/bin/dpkg returned an error code (1)

Switching to root which uses bash as default:

$ sudo su -
root@egil-XPS:~# apt install dotnet-sdk-2.0.0-preview2-006497 
Reading package lists... Done
Building dependency tree       
Reading state information... Done
dotnet-sdk-2.0.0-preview2-006497 is already the newest version (2.0.0-preview2-006497-1).
Starting pkgProblemResolver with broken count: 0
Starting 2 pkgProblemResolver with broken count: 0
Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
1 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n] y
Setting up dotnet-sdk-2.0.0-preview2-006497 (2.0.0-preview2-006497-1) ...
This software may collect information about you and your use of the software, and send that to Microsoft.
Please visit http://aka.ms/dotnet-cli-eula for more information.
Welcome to .NET Core!
---------------------
Learn more about .NET Core @ https://aka.ms/dotnet-docs. Use dotnet --help to see available commands or go to https://aka.ms/dotnet-cli-docs.

.NET Core Tools Telemetry
--------------
The .NET Core Tools include a telemetry feature that collects usage information. It is important that the .NET Team understands how the tools are being used so that we can improve them.

The data collected is anonymous and will be published in an aggregated form for use by both Microsoft and community engineers under the Creative Commons Attribution License.

The .NET Core Tools telemetry feature is enabled by default. You can opt-out of the telemetry feature by setting an environment variable DOTNET_CLI_TELEMETRY_OPTOUT (for example, 'export' on macOS/Linux, 'set' on Windows) to true (for example, 'true', 1). You can read more about .NET Core tools telemetry at https://aka.ms/dotnet-cli-telemetry.

[richlander]

Thanks @egilh. I moved your issue to #739. Please mail me at rlander@ms. I some additional questions to ask.

[TAGC]

After installing this version of .NET Core, my downgrade warnings have become errors. I'm _forced_ to rely on an older version of AspNetCore.JsonPatch due to aspnet/JsonPatch#59. I know from testing that my application works fine even with this downgrade, and breaks if I upgrade it. Is there a way to turn the errors back to warnings again so that I can successfully run dotnet restore?

[Petermarcu]

@TAGC. Can you open an issue on Nuget/home?

[WillooWisp]

I am able to build and run our ported .NET Core 2.0 app with CLI tools, dotnet build and publish. It is not possible in latest preview of Visual Studio 2017 with latest updates however. I get different build errors. Is this a know issue or something you want to investigate further?

[richlander]

@WillooWisp can you provide more insight into what is happening? Please file a new issue here and include the errors that you are seeing.

[WillooWisp]

@richlander I nailed it down to this: Unable to build .NET Core 2.0 app in Visual Studio 2017 (latest preview) when referencing the one and only NuGet package "Microsoft.AspNetCore.All". Referencing the individual packages as in .NET Core 1.1 works though.

Errors:
error CS0234: The type or namespace name 'Mvc' does not exist in the namespace 'Microsoft.AspNetCore' (are you missing an assembly reference?)
error CS0246: The type or namespace name 'Controller' could not be found (are you missing a using directive or an assembly reference?)
error CS0246: The type or namespace name 'RouteAttribute' could not be found (are you missing a using directive or an assembly reference?)
error CS0246: The type or namespace name 'HttpGetAttribute' could not be found (are you missing a using directive or an assembly reference?)
error CS0246: The type or namespace name 'HttpPostAttribute' could not be found (are you missing a using directive or an assembly reference?)

[rmunn]

I don't know if this should be reported here or not, since it might simply be a PEBKAC issue. But I've been getting what appears to be the same error as https://github.com/OmniSharp/omnisharp-vscode/issues/1495#issuecomment-302751595:

error MSB4018: System.MissingMethodException: Method not found: 'System.Collections.Generic.IList`1 NuGet.ProjectModel.LockFileTargetLibrary.get_Dependencies()'.

I have SDK version 2.0.0-preview2-006497 installed, but the project I'm running was written to work with .NET Core 1.0.4 according to its README. This is surprising to me: I would expect that a project written against .NET Core 1.x would continue to work when run with the .NET Core 2.x SDK. Is there a breaking change documented anywhere that I missed (in which case it's a simple PEBKAC issue), or is this really a bug that should be reported here?

[bartread]

I'm brand new to .NET Core and wanted to try experimenting with ASP.NET Core 2.0. I'm following this tutorial here:

https://docs.microsoft.com/en-us/aspnet/core/tutorials/web-api-vsc

I realise this is probably aimed at 1.x but the problem I'm running into is weird. Basically I can create the app fine and have no problem debugging it, but every URL I browse to returns a 404. For example, the following should work but doesn't: http://localhost:5000/api/values.

You'll see that I've posted at the bottom of the tutorial, so I've tried changing the listen port and have verified that the process is listening on the correct port using netstat. Clearly something is listening because I'm getting 404s back, which I suppose is a form of progress.

I'd think this was just a mismatch with the tutorial, but the CLI does create an app with a ValuesController class whose route is set as [Route("api/[controller]")] so I must admit I was expecting it to just work (TM), and I'm now slightly baffled that it doesn't.

[bartread]

The issue seems to be that the controllers just aren't hooked up. For example, I created a simple catch-all controller to return a 429 regardless of the URL that is used, but what I still invariably get back is a 404:

    public class CatchAllController : Controller
    {
        [Route("{*url}", Order = 999)]
        [HttpGet]
        public IActionResult Get()
        {
            Response.StatusCode = 429;
            return View();
        }
    }

What I will say, and this strikes me as a bit weird, is that the Controllers folder, containing both ValuesController.cs and my new CatchAllController.cs, has been placed below the obj folder in my hierarchy. This might be expected in .NET Core but is certainly very odd when coming at it from a .NET Classic (or whatever the original version of .NET is called these days) background. Is this actually the correct structure?

I also have an obj\Debug folder that contains MyProjectName.AssemblyInfo.cs. Again, that seems odd. Is it expected?

[bartread]

Sorry, false alarm.

That whole controllers in the obj folder thing got me deeply suspicious so I went and created another test project. This time the _Controllers_ folder was in the project root folder so I can only imagine I somehow managed to inadvertently drag it into the _obj_ folder in VS Code. Whatever, definitely a PEBKAC.

[TAGC]

When I try to publish a .NET Core 2.0 project as a standalone application targeting the win7-x64 runtime, I get the following error trying to execute it (<project>/bin/Release/netcoreapp2.0/win7-x64/publish/product.exe):

Failed to initialize CoreCLR, HRESULT: 0x80004005

I'm developing this on a 64-bit Windows 7 machine and it works fine trying to run it in Visual Studio. There's another executable version of it in the directory right above the publish directory (<project>/bin/Release/netcoreapp2.0/win7-x64/product.exe) and that works fine too.

$ dotnet --version
2.0.0-preview2-006497

[Petermarcu]

can you try win-x64 instead of win7-x64?

[TAGC]

@Petermarcu Thanks, that works. Will win10-x64 still work for Windows 10, or do I need to change that too?

[Petermarcu]

Honestly, it should have worked with win7-x64 and there is probably a bug there somewhere but in 2.0 we're really encouraging people just to use win-x64.

[TAGC]

@Petermarcu Where are you encouraging people to make that switch? All the docs I've seen (like this) reference RIDs like win7-x64, win10-x64, etc.

I can't actually find reference to "win-x64" anywhere. Is it safe to assume that I can use win-x64 for versions of the app targeting 64-bit Windows 10 too?

[Petermarcu]

@richlander @mairaw, we need to make sure the docs are updated for 2.0 to make sure people know that they should basically be using win-x64, linux-x64, and osx-x64 for everything by default.

@TAGC , yes, for apps targeting any version of Windows that .NET Core 2.0 supports, you should be able to publish one application using win-x64 and it should run on all the versions.

[TAGC]

That should simplify my deployment. Nice.

[Petermarcu]

Yes, that is the hope ;)

[TAGC]

.NET Core 2.0 Docker images are based on Debian Stretch, which uses a slightly newer (but still ancient) version of NuGet - v2.8.7.0 as opposed to v2.8.1.0 which came with Debian Jessie (used by .NET Core 1.1). Somewhere between these two releases, a bug was introduced that broke nuget sources update (see NuGet/Home#5707 for further details).

I recently updated one of my ASP.NET Core projects to target netcoreapp2.0. This meant that I needed to switch to using the .NET Core 2.0 SDK Docker image to build and test my project during CI builds. During that CI build, I need to inject private credentials into my NuGet.Config file, but this fails due to the bug in the version of NuGet that comes with the .NET Core 2.0 SDK image.

- BUILD_CONFIGURATION=Debug

# Add credentials
- nuget setapikey $MYGET_API_KEY -source https://www.myget.org/F/<company>/api/v3/index.json -configFile NuGet.Config
- nuget sources update -name "<Company Feed>" -source https://www.myget.org/F/<company>/api/v3/index.json -user $MYGET_USER -pass $MYGET_PASS -StorePasswordInClearText -configFile NuGet.Config

# Restore dependencies
- dotnet restore

I'm probably not the only person who needs to update their NuGet.Config during CI builds to resolve private NuGet packages, so other people may encounter this issue as they update to using .NET Core 2. Can you or anyone at Microsoft advise a workaround until the Stretch maintainers upload a newer NuGet package?

[troncomputers]

How to upgrade from 2.0-preview1-final to 2.0-preview2-final?
Latest runtime & sdk installed with latest VS2017 15.3 preview 7.0

PM> dotnet restore
  Restoring packages for C:\OptimoKasiarz_Zdarzenia\OptimoKasiarz\OptimoKasiarz.csproj...
  Restoring packages for C:\OptimoKasiarz_Zdarzenia\OptimoKasiarz\OptimoKasiarz.csproj...
  Restoring packages for C:\OptimoKasiarz_Zdarzenia\OptimoKasiarz\OptimoKasiarz.csproj...
  Restore completed in 1.15 sec for C:\OptimoKasiarz_Zdarzenia\OptimoKasiarz\OptimoKasiarz.csproj.
C:\OptimoKasiarz_Zdarzenia\OptimoKasiarz\OptimoKasiarz.csproj : warning NU1701: Package 'Microsoft.AspNet.Razor 3.2.3' was restored using '.NETFramework,Version=v4.6.1' instead the project target framework '.NETCoreApp,Version=v2.0'. This may cause compatibility problems. [C:\OptimoKasiarz_Zdarzenia\OptimoKasiarz.sln]
C:\OptimoKasiarz_Zdarzenia\OptimoKasiarz\OptimoKasiarz.csproj : warning NU1701: Package 'Microsoft.Composition 1.0.27' was restored using '.NETFramework,Version=v4.6.1' instead the project target framework '.NETCoreApp,Version=v2.0'. This may cause compatibility problems. [C:\OptimoKasiarz_Zdarzenia\OptimoKasiarz.sln]
  Restore completed in 1.5 sec for C:\OptimoKasiarz_Zdarzenia\OptimoKasiarz\OptimoKasiarz.csproj.
C:\OptimoKasiarz_Zdarzenia\OptimoKasiarz\OptimoKasiarz.csproj : error NU1607: Version conflict detected for Microsoft.CodeAnalysis.Common. Reference the package directly from the project to resolve this issue.  [C:\OptimoKasiarz_Zdarzenia\OptimoKasiarz.sln]
C:\OptimoKasiarz_Zdarzenia\OptimoKasiarz\OptimoKasiarz.csproj : error NU1607:  OptimoKasiarz (>= 1.0.0) -> Microsoft.AspNetCore.All (>= 2.0.0-preview2-final) -> Microsoft.AspNetCore.Mvc.Razor (>= 2.0.0-preview2-final) -> Microsoft.CodeAnalysis.CSharp (>= 2.3.0-beta1) -> Microsoft.CodeAnalysis.Common (>= 2.3.0-beta1)  [C:\OptimoKasiarz_Zdarzenia\OptimoKasiarz.sln]
C:\OptimoKasiarz_Zdarzenia\OptimoKasiarz\OptimoKasiarz.csproj : error NU1607:  OptimoKasiarz (>= 1.0.0) -> Microsoft.VisualStudio.Web.CodeGeneration.Design (>= 2.0.0-preview1-final) -> Microsoft.VisualStudio.Web.CodeGenerators.Mvc (>= 2.0.0-preview1-final) -> Microsoft.VisualStudio.Web.CodeGeneration (>= 2.0.0-preview1-final) -> Microsoft.VisualStudio.Web.CodeGeneration.EntityFrameworkCore (>= 2.0.0-preview1-final) -> Microsoft.VisualStudio.Web.CodeGeneration.Core (>= 2.0.0-preview1-final) -> Microsoft.VisualStudio.Web.CodeGeneration.Templating (>= 2.0.0-preview1-final) -> Microsoft.VisualStudio.Web.CodeGeneration.Utils (>= 2.0.0-preview1-final) -> Microsoft.CodeAnalysis.CSharp.Workspaces (>= 2.0.0) -> Microsoft.CodeAnalysis.Workspaces.Common (>= 2.0.0) -> Microsoft.CodeAnalysis.Common (>= 2.0.0). [C:\OptimoKasiarz_Zdarzenia\OptimoKasiarz.sln]
  Restore failed in 3.73 sec for C:\OptimoKasiarz_Zdarzenia\OptimoKasiarz\OptimoKasiarz.csproj.

[mairaw]

@Petermarcu, @weshaggard has created an issue for us to add that: https://github.com/dotnet/docs/issues/2843 but I'm still working on CLI updates. I'll include you on a thread about this offline.

[TAGC]

@troncomputers I think having a global.json file in the solution directory with this content helps:

{
  "sdk": {
    "version": "2.0.0-preview2-006497"
  }
}

If you run dotnet --version in the terminal with the solution folder as its working directory, you should see: 2.0.0-preview2-006497.

[JeffreyMcBride]

@Petermarcu, is there an appropriate place to post VS2017 Preview issues related to .NET Core 2 Preview in addition to the normal in-app "Report a Problem..." system? Thanks.

[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: https://github.com/dotnet/core/issues/711#issuecomment-322046436. 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 : https://github.com/dotnet/core/issues/711#issuecomment-322364947
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 https://github.com/dotnet/core/issues/711#issuecomment-324781916 ?

[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 https://github.com/aspnet/Logging/issues/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.