Add target framework 'netcoreapp3.0' or replace target framework 'netcoreapp2.1' with 'netcoreapp3.0' when adding is not possible #37823
Conversation
…coreapp2.1' with 'netcoreapp3.0' when adding is not possible.
|
|
There was a problem hiding this comment.
Sorry but at this point we can't take this change as is. The executables which ship in the .NET SDK, csc, csi, etc ..., must continue to have a netcoreapp2.1 output. That's because our binaries still ship in 2.2 / 2.1 environments. Wholesale switching these to netcoreapp3.0 would break those scenarios.
|
Let me try and elaborate a bit more here. At the moment the compilers ship to a number of different products: .NET SDK 2.2, .NET SDK 3.0, some internal teams, MS.Net.Compiliers.Toolset NuPkg, etc ... Many of these environments continue to use a 2.1 runtime as this is the latest RTM version. I don't expect them all to update to 3.0 until probably several months after we've shipped 3.0. Even then we'll need to work with various partner teams to ensure they have switched over to netcoreapp3.0 before we can full sale update the product.
That seems odd. The bootstrap CLI should indeed support targeting netcoreapp2.1 at build time. After all we currently participate in source build and this is how our project is setup. Is the problem that the executable's won't run because the runtime.json file lists netcoreapp2.1 and roll forward is disabled? If so then just update the roll forward property to get the compilers to execute. |
|
What do we do for ARM64 @jaredpar ? There is no 2.1 AFAIK? |
Target or runtime? |
|
According to the source build repository ARM support isn't expected yet dotnet/source-build#750 (comment) |
|
You're right @jaredpar:
But it doesn't. Building a simple console app that targets If it's really planned
this would likely delay the development of .NET Core for FreeBSD until next year. So what about targeting |
jinujoseph
added
Area-Infrastructure
Community
…f Bind, to be sure that we don't return type expression info instead of actual expression info.
Including more projects that have a dependency on ilasm.
Co-Authored-By: Nick Guerrera <nicholg@microsoft.com>
The desktop ilasm contains features not present in coreclr; specifically the ability to generate PDB files for net modules. Need to continue using desktop ilasm as long as our tests depend on this.
for now, it only reports method calls and member references from metadata reference. it reports data as hash value to protect privacy
…erProvider.cs Co-Authored-By: Joey Robichaud <joseph.robichaud@microsoft.com>
…erProvider.cs Co-Authored-By: Joey Robichaud <joseph.robichaud@microsoft.com>
…ocess" rather than "live analysis" to reduce confusion on what "live analysis" means since term "live analysis" has strong association with "errors" in VS. also, it now shows ## of pending work and whether BG process is paused or not.
This DLL should be marked for splitting in our test runner. When we did the great assembly rename though this was missed. Fixing.
…rementalAnalyzerProcessor.cs Co-Authored-By: Sam Harwell <sam@tunnelvisionlabs.com>
…ressReporter.cs Co-Authored-By: CyrusNajmabadi <cyrus.najmabadi@gmail.com>
I've tried to build dotnet/source-build which uses dotnet/roslyn on FreeBSD with a bootstrap CLI. Building
SoureBuild.slnfailed because it targetsnetcoreapp2.1on FreeBSD, which is not supported by the bootstrap CLI. Therefore, I've applied the patches mentioned in dotnet/source-build#1139 to build it on FreeBSD. To avoid destroying the build on other platforms, I've changed the target framework in the whole project tonetcoreapp3.0, which is also a future goal, I think.cc: @wfurt