-
Notifications
You must be signed in to change notification settings - Fork 136
[3.0.102/3.1.101] various assemblies no longer r2r compiled since service release #1452
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
Comments
The following line was added by a5cd250, for #1260 (the 3.0.1 merge). This suppresses crossgen and causes the outputs not to be ready-to-run compiled (R2R). @crummel do you remember why you tried this change? source-build/repos/aspnetcore.proj Line 22 in 3085962
(FWIW, in my experience, AOT describes the more extensive efforts of e.g. CoreRT, distinct from R2R. In case it causes confusion down the line.) |
AzDO deleted the build, but GitHub remembers this error from the previous commit in that PR:
I think the logs right before the error would reveal more about the cause, but we'll have to run a new build to see what happens. |
This is what I get when I enable it on
On NuGet.org, |
Huh. I get the same weird lib-less nupkg if I clone dotnet/[email protected] and run |
It turns out I filed dotnet/extensions#2897 under false pretense: checking out [email protected] and building it standalone also has the same packing problem. Based on that, it seems unrelated to the issue. I'll open a new issue once I get something more actionable for them. Now I see that 3.0.0 has a patch called |
My build worked--I see crossgen happening in the binlog, the nupkgs are correct, and file sizes are back up. Opened PR #1458. |
@dagood thanks a lot for looking into this, and fixing the issue! |
Verify that assemblies are compiled in READYTORUN mode to catch issues like these: dotnet/source-build#1452 This change merges the test previously written in python ("dlls-in-release-mode") with this new test to avoid duplication. We are mostly interested in assemblies in the shared framework, not in the SDK or targeting packs. Fixes: redhat-developer#103
Verify that assemblies are compiled in READYTORUN mode to catch issues like these: dotnet/source-build#1452 This change merges the test previously written in python ("dlls-in-release-mode") with this new test to avoid duplication. We are mostly interested in assemblies in the shared framework, not in the SDK or targeting packs. Fixes: redhat-developer#103
I've confirmed that the file sizes look good in a 3.1.102 we're in the progress of putting together, after applying the same fix there. |
Verify that assemblies are compiled in READYTORUN mode to catch issues like these: dotnet/source-build#1452 This change merges the test previously written in python ("dlls-in-release-mode") with this new test to avoid duplication. We are mostly interested in assemblies in the shared framework, not in the SDK or targeting packs. Fixes: #103
There was a hiccup with |
Verify that assemblies are compiled in READYTORUN mode to catch issues like these: dotnet/source-build#1452 This change merges the test previously written in python ("dlls-in-release-mode") with this new test to avoid duplication. We are mostly interested in assemblies in the shared framework, not in the SDK or targeting packs. Fixes: #103
@omajid noticed file sizes changed for various assemblies with the servicing release:
Looking at these assemblies showed they are no longer being compiled ahead-of-time.
Microsoft service builds for 3.0 and 3.1 are still being compiled ahead-of-time.
ref: https://bugzilla.redhat.com/show_bug.cgi?id=1791462
cc @crummel @dagood @dseefeld @omajid
The text was updated successfully, but these errors were encountered: