Support NETCoreApp1.0...

Question

Support NETCoreApp1.0...

muratg opened this issue 9 years ago · 26 comments

muratg commented 9 years ago

Just like we supported netstandard and netstandardapp.

See dotnet/cli#1810

cc @anurse @Eilon @NTaylorMullen @pranavkm

Answer 1 · 2016-03-11T21:41:05.000Z

See the corresponding NuGet change here: NuGet/Home#2299

Answer 2 · 2016-03-11T21:50:13.000Z

Is this essentially an alias for netstandardapp1.5?

Answer 3 · 2016-03-11T22:04:29.000Z

I think so, but @anurse can confirm.

Answer 4 · 2016-03-11T22:25:53.000Z

I believe it's not an alias, it's a different thing. We want to hold netstandardapp1.5 as something we could use in different ways later. /cc @DamianEdwards

Answer 5 · 2016-03-11T22:27:11.000Z

Would we need to rename netstandardapp1.5 -> netcoreapp1.0 in our project.jsons as a follow up to this?

Answer 6 · 2016-03-11T22:27:19.000Z

Also cc @emgarten

Answer 7 · 2016-03-11T22:36:45.000Z

@pranavkm Yep

Answer 8 · 2016-03-11T22:41:23.000Z

netcoreapp1.0 is the successor to dnxcore50. netstandard1.x and netstandardapp1.x are completely new concepts that are functionally equivalent to each other for now.

Answer 9 · 2016-03-11T22:47:28.000Z

@DamianEdwards NuGet/Home#2299 (comment)

... a new TFM called "netcoreapp" currently with only one version "netcoreapp1.0" which maps to netstandard1.5

Answer 10 · 2016-03-11T22:53:37.000Z

Will netcore1.0 be for packages?

Side note ... plz let us know when these latest updates are on the CI feed & dotnet cli-ready. I froze packages to ride out the changes, but I'd like to unfreeze and get in on this action asap.

Answer 11 · 2016-03-11T22:56:01.000Z

@guardrex netcoreapp1.0 (note the app in there) represents applications running on/via the .NET Core CLI infrastructure (which is CoreCLR and some number of libraries, just like dnxcore50 was). Libraries are free to target this TFM if they need API that only works in these app types, otherwise we'll be encouraging libraries to target netstandard1.x for the widest compatibility.

Answer 12 · 2016-03-11T22:59:33.000Z

Gotcha ...

netcoreapp1.0 for Core CLR apps
~~netstandard1.5~~ netcoreapp1.0 for Core CLR packages

Answer 13 · 2016-03-11T23:01:00.000Z

I'll go back and re-read the latest wiki docs on the plan. Note ... it's a bit confusing! ... but I'll get it.

Answer 14 · 2016-03-11T23:02:21.000Z

@guardrex basically, yeah. There are more docs coming very soon for this stuff, some of the ones that are public might be out of date with the absolute latest bits in GH repos as we're still working through this ourselves.

Answer 15 · 2016-03-11T23:03:37.000Z

Also note that netstandard1.5 will be supported by .NET Framework 4.6.2, it's not just about Core CLR.

Answer 16 · 2016-03-11T23:18:54.000Z

The app in netcoreapp is definitely important. Unfortunately netcore is already taken and is an alias for win ;). netcore45 maps to win8, netcore451 maps to win81, and netcore50 maps to uap10.0

Answer 17 · 2016-03-22T16:43:02.000Z

This was done but support if far from full, dnx run, restore, test are not working correctly for portable apps.

Answer 18 · 2016-03-22T17:36:17.000Z

@pakrym @anurse @ericstj I'm still working with standalone apps (win8-x64 RID). It looks like netcoreapp1.0 with -rc2-* packages and with NETStandard.Library 1.0.0-* runs ok. With either NETStandard.Library 1.5.0-* or adding in one of my NuGet packages, it breaks (that's open at aspnet/Razor#718).

May I ask for a few clarifications at this point? No rush ... "wait" is fine ... "idk" is fine ... just asking ...

Should I stay on NETStandard.Library 1.0.0-* or move to 1.5.0-* at some point? Seems like I should use the latest; but thus far, it breaks with netcoreapp1.0. If I will move to 1.5.0-*, how will I know when to do that?
What's the current status of imports on the TFM? When "imports": [ "dnxcore50", "portable-net45+win8" ] is removed from netcoreapp1.0, I get a lot of packages not ready for it ... e.g., error: System.Diagnostics.TraceSource 4.0.0-rc2-23826 is not compatible with .NETCoreApp,Version=v1.0.. We'll have imports around for a while, correct? Is the best way to get a "poor man's progress report" to just remove it and see how many packages choke? ... eventually that should dwindle down to a fully restoring app without the imports on the TFM, correct?
I'm still having difficulty getting a straight answer on which RID's to use with which Windows Server platforms. I thought that win8-x64 would be a WS 2012/R2-ish sort of RID, while win10-x64 would be a WS 2016/Nano-ish sort of RID; but apparently from what I've gathered on JabbR that isn't true. They produce different outputs, but there is no guidance on what to use for the standalone app situation with WS. Can you shed any light on that?

Answer 19 · 2016-03-22T20:22:17.000Z

it breaks (that's open at aspnet/Razor#718).

I put a workaround in today's build to address that problem until the whole stack can get on the latest packages: dotnet/corefx@0f268ed

Should I stay on NETStandard.Library 1.0.0-* or move to 1.5.0-*

/cc @weshaggard You should be able to move now. All that was done was change the major.minor version of this package. We're only building one version, so using 1.0.0 means you are on old builds.

What's the current status of imports on the TFM?

It should work without import.

error: System.Diagnostics.TraceSource 4.0.0-rc2-23826 is not compatible with .NETCoreApp,Version=v1.0

That's an old package

which RID's to use with which Windows Server platforms

We haven't created separate RIDs for Server. The main differences between the Windows version RIDs as used by the CoreFx packages are as follows;
win7 - contains the most API set dlls since none were inbox
win8/win81 - contains fewer API set dlls since some were inbox, also enables a couple WindowsRuntime packages that are only supported on Win8 and later
win10 - contains API set dlls since almost all are inbox. Right now this RID should only be used by UWP apps since there is a case with CLRCompression where we package the appx DLL under this RID.

The intent is that apps will be compatible with future versions, so if you did a standalone app for Win7 it will still work when upgraded to Win8, and so-forth. However, do to the size of the app (number of DLLs for all those API sets) you might want to use the RID for your minimally supported platform.
Server 2012 > Win8
Server 2012 R2 > Win81
I'd avoid using the Win10 RID for now.

Answer 20 · 2016-03-22T20:42:26.000Z

Thank you so much for this info. Very helpful.
On Mar 22, 2016 1:22 PM, "Eric StJohn" notifications@github.com wrote:

it breaks (that's open at aspnet/Razor#718
aspnet/Razor#718).

I put a workaround in today's build to address that problem until the
whole stack can get on the latest packages: dotnet/corefx@0f268ed
dotnet/corefx@0f268ed

Should I stay on NETStandard.Library 1.0.0-* or move to 1.5.0-*

/cc @weshaggard https://github.com/weshaggard You should be able to
move now. All that was done was change the major.minor version of this
package. We're only building one version, so using 1.0.0 means you are on
old builds.

What's the current status of imports on the TFM?

It should work without import.

error: System.Diagnostics.TraceSource 4.0.0-rc2-23826 is not compatible
with .NETCoreApp,Version=v1.0

That's an old package

which RID's to use with which Windows Server platforms

We haven't created separate RIDs for Server. The main differences between
the Windows version RIDs as used by the CoreFx packages are as follows;
win7 - contains the most API set dlls since none were inbox
win8/win81 - contains fewer API set dlls since some were inbox, also
enables a couple WindowsRuntime packages that are only supported on Win8
and later
win10 - contains API set dlls since almost all are inbox. Right now this
RID should only be used by UWP apps since there is a case with
CLRCompression where we package the appx DLL under this RID.

The intent is that apps will be compatible with future versions, so if you
did a standalone app for Win7 it will still work when upgraded to Win8, and
so-forth. However, do to the size of the app (number of DLLs for all those
API sets) you might want to use the RID for your minimally supported
platform.
Server 2012 > Win8
Server 2012 R2 > Win81
I'd avoid using the Win10 RID for now.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#3378 (comment)

Answer 21 · 2016-03-23T14:55:52.000Z

@ericstj Regarding dropping the imports from netcoreapp1.0. For my package ...

{
"dependencies": {
    "NETStandard.Library": "1.5.0-*",
    "System.Net.Http": "4.0.1-*"
},
"frameworks": {
    "netcoreapp1.0": {}
},
"runtimes": {
    "win81-x64": {}
}

... I do not need the imports. The package restores and dotnet pack's-up fine. For app that consumes the package ...

"dependencies": {
    "Microsoft.AspNetCore.Diagnostics": "1.0.0-*",
    "Microsoft.AspNetCore.Mvc": "1.0.0-*",
    "Microsoft.AspNetCore.Server.Kestrel": "1.0.0-*",
    "Microsoft.Extensions.Logging.Console": "1.0.0-*",
    "NETStandard.Library": "1.5.0-*",
    "razor_issue_pkg": "1.0.0"
},
"frameworks": {
    "netcoreapp1.0": {}
},
"runtimes": {
    "win81-x64": {}
},

I'm still getting many errors when I attempt to drop "imports": [ "dnxcore50", "portable-net45+win8" ]. With the imports all is well ... full restore and it compiles fine.

Errors without imports ...

Errors in c:\_APPLICATIONS\razor_issue_app\project.json
    System.Diagnostics.TraceSource 4.0.0-rc2-23826 is not compatible with .NETCoreApp,Version=v1.0.
    System.Threading.ThreadPool 4.0.10-rc2-23826 is not compatible with .NETCoreApp,Version=v1.0.
    System.Numerics.Vectors 4.1.1-rc2-23826 is not compatible with .NETCoreApp,Version=v1.0.
    System.Reflection.TypeExtensions 4.1.0-rc2-23826 is not compatible with .NETCoreApp,Version=v1.0.
    System.Text.Encodings.Web 4.0.0-rc2-23826 is not compatible with .NETCoreApp,Version=v1.0.
    System.ComponentModel 4.0.1-rc2-23826 is not compatible with .NETCoreApp,Version=v1.0.
    System.Linq.Expressions 4.0.11-rc2-23826 is not compatible with .NETCoreApp,Version=v1.0.
    System.Diagnostics.StackTrace 4.0.1-rc2-23826 is not compatible with .NETCoreApp,Version=v1.0.
    System.ComponentModel.Annotations 4.1.0-rc2-23826 is not compatible with .NETCoreApp,Version=v1.0.
    System.Threading.Tasks.Parallel 4.0.1-rc2-23826 is not compatible with .NETCoreApp,Version=v1.0.
    System.Runtime.Loader 4.0.0-rc2-23826 is not compatible with .NETCoreApp,Version=v1.0.
    Microsoft.CodeAnalysis.CSharp 1.1.0-rc1-20151109-01 is not compatible with .NETCoreApp,Version=v1.0.
    Newtonsoft.Json 8.0.3 is not compatible with .NETCoreApp,Version=v1.0.
    System.Net.WebSockets 4.0.0-rc2-23826 is not compatible with .NETCoreApp,Version=v1.0.
    System.Diagnostics.Contracts 4.0.1-rc2-23826 is not compatible with .NETCoreApp,Version=v1.0.
    System.Dynamic.Runtime 4.0.11-rc2-23826 is not compatible with .NETCoreApp,Version=v1.0.
    System.Resources.Reader 4.0.0-rc2-23826 is not compatible with .NETCoreApp,Version=v1.0.
    Microsoft.CSharp 4.0.1-rc2-23826 is not compatible with .NETCoreApp,Version=v1.0.
    System.ComponentModel.TypeConverter 4.0.1-rc2-23826 is not compatible with .NETCoreApp,Version=v1.0.
    System.Runtime.Serialization.Primitives 4.1.0 is not compatible with .NETCoreApp,Version=v1.0.
    Microsoft.CodeAnalysis.Common 1.1.0-rc1-20151109-01 is not compatible with .NETCoreApp,Version=v1.0.
    System.Security.Claims 4.0.1-rc2-23826 is not compatible with .NETCoreApp,Version=v1.0.
    System.Security.Principal 4.0.1-rc2-23826 is not compatible with .NETCoreApp,Version=v1.0.
    System.Collections.Immutable 1.1.37 is not compatible with .NETCoreApp,Version=v1.0.
    System.Reflection.Metadata 1.1.0 is not compatible with .NETCoreApp,Version=v1.0.
    Microsoft.Win32.Registry 4.0.0-rc2-23826 is not compatible with .NETCoreApp,Version=v1.0.
    System.Security.Principal.Windows 4.0.0-rc2-23826 is not compatible with .NETCoreApp,Version=v1.0.
    Some packages are not compatible with .NETCoreApp,Version=v1.0.
    System.Diagnostics.TraceSource 4.0.0-rc2-23826 is not compatible with .NETCoreApp,Version=v1.0 (win81-x64).
    System.Threading.ThreadPool 4.0.10-rc2-23826 is not compatible with .NETCoreApp,Version=v1.0 (win81-x64).
    System.Numerics.Vectors 4.1.1-rc2-23826 is not compatible with .NETCoreApp,Version=v1.0 (win81-x64).
    System.Text.Encodings.Web 4.0.0-rc2-23826 is not compatible with .NETCoreApp,Version=v1.0 (win81-x64).
    System.ComponentModel 4.0.1-rc2-23826 is not compatible with .NETCoreApp,Version=v1.0 (win81-x64).
    System.Linq.Expressions 4.0.11-rc2-23826 is not compatible with .NETCoreApp,Version=v1.0 (win81-x64).
    System.Reflection.TypeExtensions 4.1.0-rc2-23826 is not compatible with .NETCoreApp,Version=v1.0 (win81-x64).
    System.ComponentModel.Annotations 4.1.0-rc2-23826 is not compatible with .NETCoreApp,Version=v1.0 (win81-x64).
    System.Threading.Tasks.Parallel 4.0.1-rc2-23826 is not compatible with .NETCoreApp,Version=v1.0 (win81-x64).
    System.Runtime.Loader 4.0.0-rc2-23826 is not compatible with .NETCoreApp,Version=v1.0 (win81-x64).
    Microsoft.CodeAnalysis.CSharp 1.1.0-rc1-20151109-01 is not compatible with .NETCoreApp,Version=v1.0 (win81-x64).
    Newtonsoft.Json 8.0.3 is not compatible with .NETCoreApp,Version=v1.0 (win81-x64).
    runtime.win7.System.Diagnostics.TraceSource 4.0.0-rc2-23826 is not compatible with .NETCoreApp,Version=v1.0 (win81-x64).
    System.Diagnostics.StackTrace 4.0.1-rc2-23826 is not compatible with .NETCoreApp,Version=v1.0 (win81-x64).
    System.Net.WebSockets 4.0.0-rc2-23826 is not compatible with .NETCoreApp,Version=v1.0 (win81-x64).
    System.Diagnostics.Contracts 4.0.1-rc2-23826 is not compatible with .NETCoreApp,Version=v1.0 (win81-x64).
    runtime.any.System.Linq.Expressions 4.0.11-rc2-23826 is not compatible with .NETCoreApp,Version=v1.0 (win81-x64).
    runtime.any.System.Reflection.TypeExtensions 4.1.0-rc2-23826 is not compatible with .NETCoreApp,Version=v1.0 (win81-x64).
    System.Resources.Reader 4.0.0-rc2-23826 is not compatible with .NETCoreApp,Version=v1.0 (win81-x64).
    Microsoft.CSharp 4.0.1-rc2-23826 is not compatible with .NETCoreApp,Version=v1.0 (win81-x64).
    System.ComponentModel.TypeConverter 4.0.1-rc2-23826 is not compatible with .NETCoreApp,Version=v1.0 (win81-x64).
    System.Runtime.Serialization.Primitives 4.1.0 is not compatible with .NETCoreApp,Version=v1.0 (win81-x64).
    Microsoft.CodeAnalysis.Common 1.1.0-rc1-20151109-01 is not compatible with .NETCoreApp,Version=v1.0 (win81-x64).
    System.Dynamic.Runtime 4.0.11-rc2-23826 is not compatible with .NETCoreApp,Version=v1.0 (win81-x64).
    System.Collections.Immutable 1.1.37 is not compatible with .NETCoreApp,Version=v1.0 (win81-x64).
    System.Reflection.Metadata 1.1.0 is not compatible with .NETCoreApp,Version=v1.0 (win81-x64).
    Microsoft.Win32.Registry 4.0.0-rc2-23826 is not compatible with .NETCoreApp,Version=v1.0 (win81-x64).
    Some packages are not compatible with .NETCoreApp,Version=v1.0 (win81-x64).

.NET Command Line Tools (1.0.0-beta-001937)

Product Information:
Version: 1.0.0-beta-001937
Commit Sha: 3616378130

Runtime Environment:
OS Name: Windows
OS Version: 10.0.10586
OS Platform: Windows
Runtime Id: win10-x64

NuGet.config ...

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <packageSources>
    <clear />
    <add key="AspNetCI" value="https://www.myget.org/F/aspnetcidev/api/v3/index.json" />
    <add key="NuGet.org" value="https://api.nuget.org/v3/index.json" />
    <add key="dotnet-core" value="https://www.myget.org/F/dotnet-core/api/v3/index.json" />
    <add key="dotnet-cli" value="https://www.myget.org/F/dotnet-cli/api/v3/index.json" />
    <add key="AspNetvNext" value="https://www.myget.org/F/aspnetvnext/api/v3/index.json" />
    <add key="LocalPkg" value="C:\_APPLICATIONS\razor_issue_pkg\bin\Release" />
  </packageSources>
</configuration>

Answer 22 · 2016-03-23T14:59:46.000Z

@guardrex looks like you're picking up old packages rc2-23826. The latest on dotnet-core feed is rc3-23923 or rc2-23923.

Answer 23 · 2016-03-23T15:01:31.000Z

@ericstj nuke the cache and try restore again?

[EDIT] A little confused here, b/c what's wrong with the project.json files and dotnet cli that it can't get the correct packages? ... Is it just a work in progress/in-design to a certain extent? 😄 I'm always (probably) jumping the gun around here a little bit. I might need to slow this 🐴 down a bit.

[EDIT^2] sry ... cross-discussing the same prob in two issues. The packages I'm using with the package and project are in the last issue comment ... all * packages.

Answer 24 · 2016-03-23T15:42:55.000Z

Looks like the ASP.NET packages are still bringing in old packages that don't support 'netstandard' moniker. When you use * it only chooses latest direct references, indirect are still whatever was referenced by direct referenced packages. You need a newer build of ASP.NET that references the latest packages.

Previously CoreFx would try to unify all the packages to a single version/build with entries in the runtime.json, however this caused issues like https://github.com/dotnet/corefx/issues/6603 as well as upset folks who wanted more control of getting exactly the version referenced by their packages. As a result we stopped doing this. What that means during pre-release is that you have to be more careful about mixing/matching builds.

One thing you could try is directly referencing the latest build of all packages with something like https://gist.github.com/ericstj/2cda9163e22016893733. When doing this I see that only the following errors:

    Microsoft.CodeAnalysis.CSharp 1.1.0-rc1-20151109-01 is not compatible with .NETCoreApp,Version=v1.0.
    Newtonsoft.Json 8.0.3 is not compatible with .NETCoreApp,Version=v1.0.
    Microsoft.CodeAnalysis.Common 1.1.0-rc1-20151109-01 is not compatible with .NETCoreApp,Version=v1.0.

That leaves us with Roslyn and JSon.NET as the only packages still requiring an import. I believe Roslyn is working on this now: dotnet/roslyn#9891.

Answer 25 · 2016-03-23T15:47:54.000Z

@ericstj I see. This has turned out after all (and along with the package downgrade issue) to be just a work-in-progress situation.

I'll do as you suggest and work more directly with matching latest packages. Regarding the imports, I'll perform a "poor man's import test" by just keeping the imports while I'm still getting "not compatible" mentions. It looks like those will just melt away eventually, leaving me with packages/apps that restore just fine.

Answer 26 · 2016-03-23T15:50:01.000Z

guardrex commented 9 years ago