Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Change projects to target netcoreapp3.0 #3754

Closed
13 tasks done
natemcmaster opened this issue Oct 29, 2018 · 43 comments
Closed
13 tasks done

Change projects to target netcoreapp3.0 #3754

natemcmaster opened this issue Oct 29, 2018 · 43 comments
Assignees
Labels
area-infrastructure Includes: MSBuild projects/targets, build scripts, CI, Installers and shared framework Done This issue has been fixed task

Comments

@natemcmaster
Copy link
Contributor

natemcmaster commented Oct 29, 2018

As a part of only supporting .NET Core, we can change most projects to target netcoreapp3.0 instead of netstandard2.0.
This change applies to test projects, which no longer need to cross-target .NET Framework.

See aspnet/Announcements#324

Remaining feature areas (I likely missed a few here, keep adding them ~Chris):

  • Html
  • Razor - make sure to ping @rynowak on this one. We're splitting code here into a new repo soon.
  • Http - (Chris) - With exceptions Change projects to target netcoreapp3.0 #3754 (comment)
  • Hosting (Chris)
  • DataProtection (Chris)
  • HttpSysServer (Chris)
  • Kestrel (Chris)
  • BasicMiddleware (Chris)
  • IISIntegration (Justin)
  • Antiforgery (Chris)
  • StaticFiles (Chris)
  • ResponseCaching (Chris)
  • Middleware (Chris)
@natemcmaster natemcmaster added task feature-platform Deprecated: Cross-cutting issues related to ASP.NET Core as a platform labels Oct 29, 2018
@natemcmaster natemcmaster added this to the 3.0.0 milestone Oct 29, 2018
@natemcmaster
Copy link
Contributor Author

I want to emphasize the "most" part of the original post. Some libraries, like the SignalR .NET client, must continue to target .NET Standard when the library is intended for use on other .NET runtimes like Xamarin and UWP. This decision is being made on a case-by-base basis. We should finish going through our list of assemblies and post the decisions to clarify exactly which assemblies should change to netcoreapp3.0-only.

@bdominguez
Copy link

What about WPF applications that host asp net core? It will no longer be possible to do this.

@khellang
Copy link
Member

What about WPF applications that host asp net core?

Just port it over to .NET Core? 😉 https://blogs.msdn.microsoft.com/dotnet/2018/10/04/update-on-net-core-3-0-and-net-framework-4-8/

@natemcmaster
Copy link
Contributor Author

@khellang is correct, WPF and AspNetCore can be used together. A WPF app will be able to set TargetFramework to netcoreapp3.0 and also have a FrameworkReference to Microsoft.AspNetCore.App.

@benaadams
Copy link
Member

What about WPF applications that host asp net core? It will no longer be possible to do this.

And if you don't want to port your WPF to .NET Core (though you should 😉) you can keep using ASP.NET Core 2.1 #3753 (comment)

In order to give customers a reasonable stepping stone on their path to migrating applications to ASP.NET Core on .NET Core, we are going to extend support and servicing for ASP.NET Core 2.1.x on .NET Framework to match the current support policy for the other package-based ASP.NET frameworks, e.g. MVC 5.x, Web API 2.x, SignalR 2.x. This effectively means the ASP.NET Core 2.1.x related packages (final detailed list TBD) will be supported indefinitely, beyond the 3 year LTS period for the .NET Core 2.1 train overall.

@natemcmaster
Copy link
Contributor Author

@dougbu
Copy link
Member

dougbu commented Nov 30, 2018

/cc @Tratcher

@SteveSandersonMS
Copy link
Member

SteveSandersonMS commented Dec 14, 2018 via email

@dougbu
Copy link
Member

dougbu commented Dec 14, 2018

@SteveSandersonMS your email responded to a message about JsonPatch. Is that used in projects that target WebAssembly too?

@natemcmaster
Copy link
Contributor Author

Btw, I'm updating Doug's check list above. Yes, ZipManifestGenerator could be updated, but it doesn't really matter. It's a developer tool for this repo only. We don't re-distribute.

@dougbu
Copy link
Member

dougbu commented Dec 14, 2018

I double-checked the src/Identity test projects and they're fine, controlled by src\Identity\test\Directory.Build.props

@SteveSandersonMS
Copy link
Member

SteveSandersonMS commented Dec 14, 2018 via email

@dougbu
Copy link
Member

dougbu commented Dec 14, 2018

@Tratcher was Microsoft.AspNetCore.Connections.Abstractions.csproj left out of #4405 on purpose?

@rynowak
Copy link
Member

rynowak commented Dec 14, 2018

JsonPatch should change to netcoreapp3.0.

Components stuff can be left alone. We'll be doing more surgery there soon, and much of it will be ns2.0 forever

@rynowak
Copy link
Member

rynowak commented Dec 14, 2018

Precompilation can be deleted.

@Tratcher
Copy link
Member

@natemcmaster wasn't SignalR client going to need Microsoft.AspNetCore.Connections.Abstractions.csproj transitively?

@dougbu
Copy link
Member

dougbu commented Dec 14, 2018

Actions so far:

  • convert to netcoreapp3.0:
    • src\Features\JsonPatch\src\Microsoft.AspNetCore.JsonPatch.csproj
    • src\PackageArchive\ZipManifestGenerator\ZipManifestGenerator.csproj
  • delete
    • src/MvcPrecompilation/**

@natemcmaster
Copy link
Contributor Author

@Tratcher yes, Microsoft.AspNetCore.Connections.Abstractions is intentionally netstandard2.0. I updated the checklist.

@dougbu
Copy link
Member

dougbu commented Dec 14, 2018

@pranavkm that leaves just Microsoft.AspNetCore.Mvc.Analyzers.csproj and Microsoft.AspNetCore.Mvc.Api.Analyzers.csproj. Must the analyzers target netstandard1.3?

@dougbu
Copy link
Member

dougbu commented Dec 14, 2018

FYI I'll take the remaining few actions

dougbu added a commit that referenced this issue Dec 15, 2018
- out-of-date and no longer shipped
- related to #3754
dougbu added a commit that referenced this issue Dec 15, 2018
- #3754
- remove `#if`'s for multi-targeting where source is never multi-targeted
@dougbu
Copy link
Member

dougbu commented Dec 15, 2018

PRs #5124 and #5128 address known TODOs

dougbu added a commit that referenced this issue Dec 17, 2018
- out-of-date and no longer shipped
- related to #3754
@dougbu
Copy link
Member

dougbu commented Dec 17, 2018

#5124 closed with 826f950

dougbu added a commit that referenced this issue Dec 17, 2018
- #3754
- remove `#if`'s for multi-targeting where source is never multi-targeted
- left `StreamPipeReader`, `StreamPipeWriter` and their test classes alone because they're moving to CoreFx
@dougbu
Copy link
Member

dougbu commented Dec 17, 2018

Last bit done in e717a84

@dougbu dougbu closed this as completed Dec 17, 2018
@dougbu dougbu added the Done This issue has been fixed label Dec 17, 2018
@dougbu
Copy link
Member

dougbu commented Dec 17, 2018

Actually, @pranavkm should the analysers be converted to target netcoreapp3.0?

@natemcmaster
Copy link
Contributor Author

I believe analyzers should target netstandard2.0, since csc runs on both framework (in VS) and core (everywhere else).

@dotnet dotnet locked as resolved and limited conversation to collaborators Dec 3, 2019
@JunTaoLuo JunTaoLuo added area-infrastructure Includes: MSBuild projects/targets, build scripts, CI, Installers and shared framework and removed feature-platform Deprecated: Cross-cutting issues related to ASP.NET Core as a platform labels Jan 28, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area-infrastructure Includes: MSBuild projects/targets, build scripts, CI, Installers and shared framework Done This issue has been fixed task
Projects
None yet
Development

No branches or pull requests