Restore Microsoft.Private.CoreFX.NETCoreApp package #58
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
I haven't figured out what to do with it yet, but it's clear we can't package the framework out of the CoreCLR NuGet infra and we need one for Microsoft.DotNet.ILCompiler. This is the rollback of the commit that deleted the transport package with tweaks to account for the endless build infra churn. frameworkPackage.targets has some validation to ensure there's no cycle in assembly dependencies. I've deleted it because we now have at least one such cycle (`netstandard > System.Xml.XDocument > System.Private.Xml.Linq > System.Private.Xml > System.Security.Cryptography.Algorithms > System.Formats.Asn1 > netstandard`).
MichalStrehovsky
added
the
area-NativeAOT-coreclr
Does this need a bug in dotnet/runtime ? |
We would need to create the runtime packs in installer partition, same as where they are created for other runtimes. |
jkotas
approved these changes
Aug 19, 2020
@ericstj I'm restoring Microsoft.Private.CoreFX.NETCoreApp package here for... reasons.... One of the things building this package did was the VerifyClosure thing that you added around dotnet/corefx@e04090e. Do we still care about cycles in the closure? We now apparently have some in .NET 5. |
https://github.com/dotnet/runtimelab/blob/NativeAOT/src/installer/pkg/projects/netcoreapp/pkg/Microsoft.NETCore.App.Runtime.pkgproj is pretty obfuscated in terms of what it is doing (I have no clue how that things turns into a package). I'll spend some time over a MSBuild binlog and try to figure out what it does and how to clone it into what we need. Maybe the extra transport package is not worth it. I'm afraid of touching too many files because people keep redoing this all the time. Whatever we build here might get broken more often than JitInterface and fixing the fallout will probably always involve inspecting binlogs because the build infra is too clever and churns too much to keep track of. |
The fix for this issue is to add a $(NetCoreAppCurrent) configuration to Asn1. I'll file an issue. cc @bartonjs |
|
@MichalStrehovsky the building of the runtime pack will be significantly simplified once I get dotnet/arcade#5714 and dotnet/runtime#38457 merged. |
|
Closing in favor of #64.
Thanks for the pointers! |
scalablecory
pushed a commit
that referenced
this pull request
Sep 22, 2020
For some reason, the build issue was only caught internally.
MichalStrehovsky
added a commit
to MichalStrehovsky/runtimelab
that referenced
this pull request
Oct 15, 2021
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I haven't figured out what to do with it yet, but it's clear we can't package the framework out of the CoreCLR NuGet infra and we need one for Microsoft.DotNet.ILCompiler.
This is the rollback of the commit that deleted the transport package with tweaks to account for the endless build infra churn.
frameworkPackage.targets has some validation to ensure there's no cycle in assembly dependencies. I've deleted it because we now have at least one such cycle (
netstandard > System.Xml.XDocument > System.Private.Xml.Linq > System.Private.Xml > System.Security.Cryptography.Algorithms > System.Formats.Asn1 > netstandard).