COLLECTED BY

Organization: Archive Team

Formed in 2009, the Archive Team (not to be confused with the archive.org Archive-It Team) is a rogue archivist collective dedicated to saving copies of rapidly dying or deleted websites for the sake of history and digital heritage. The group is 100% composed of volunteers and interested parties, and has expanded into a large amount of related projects for saving online and digital history.

History is littered with hundreds of conflicts over the future of a community, group, location or business that were "resolved" when one of the parties stepped ahead and destroyed what was there. With the original point of contention destroyed, the debates would fall to the wayside. Archive Team believes that by duplicated condemned data, the conversation and debate can continue, as well as the richness and insight gained by keeping the materials. Our projects have ranged in size from a single volunteer downloading the data to a small-but-critical site, to over 100 volunteers stepping forward to acquire terabytes of user-created data to save for future generations.

The main site for Archive Team is at archiveteam.org and contains up to the date information on various projects, manifestos, plans and walkthroughs.

This collection contains the output of many Archive Team projects, both ongoing and completed. Thanks to the generous providing of disk space by the Internet Archive, multi-terabyte datasets can be made available, as well as in use by the Wayback Machine, providing a path back to lost websites and work.

Our collection has grown to the point of having sub-collections for the type of data we acquire. If you are seeking to browse the contents of these collections, the Wayback Machine is the best first stop. Otherwise, you are free to dig into the stacks to see what you may find.

The Archive Team Panic Downloads are full pulldowns of currently extant websites, meant to serve as emergency backups for needed sites that are in danger of closing, or which will be missed dearly if suddenly lost due to hard drive crashes or server failures.

Collection: Archive Team: URLs

TIMESTAMPS

The Wayback Machine - https://web.archive.org/web/20220203211752/https://github.com/dotnet/aspnetcore/pull/39965

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

Jump to bottom

Update KnownRuntimePack as part of updating KnownFrameworkReference #39965

Open

pranavkm wants to merge 3 commits into dotnet:main from pranavkm:update-runtime-pack

+10 −0

Contributor

pranavkm commented Feb 3, 2022

No description provided.


          Update KnownRuntimePack as part of updating KnownFrameworkReference

16d4349

pranavkm requested a review from as a code owner

msftbot bot added the area-infrastructure label

wtgodbe mentioned this pull request

Test workaround #39967

Closed

Member

wtgodbe commented Feb 3, 2022

https://dev.azure.com/dnceng/public/_build/results?buildId=1590349&view=results tests this workaround against the commits from #39853 pre-SDK update

dougbu requested changes

View changes

Member

dougbu left a comment

It's not clear what you intend @pranavkm. As-is, the change does nothing because the %(LatestRuntimeFrameworkVersion) metadata is updated earlier in exactly the same way.

https://github.com/dotnet/aspnetcore/pull/39965/files#diff-9fb67cbc0a7ba3b793455ec41e7f36e1d019d5152674d669551810b308510d37R44-R45

Contributor Author

pranavkm commented Feb 3, 2022

@dougbu the targets currently update KnownFrameworkReference but not KnownRuntimePacks. In a Blazor WASM app, the latter is used to resolve the rid-specific runtime pack (Microsoft.NETCore.App.Mono.browser-wasm). Screenshot of the build logs before this change:

dougbu approved these changes

View changes

Member

dougbu left a comment

Ah, I understand now. Do we need to do this w/ the @(KnownAppHostPack) item for the default Core TFM too❔

Contributor Author

pranavkm commented Feb 3, 2022 •

edited

Further details - the version for KnownRuntimePacks currently comes from the value the SDK bakes in. With a blazor app, it currently compiles using the version of the runtime specified by the targeting park that we override, but runs against the version from the SDK. This is problematic in that we're not testing blazor against new runtime ingestions. Additionally, it also prevents runtime insertions when the targeting pack and the runtime pack don't align. #39853 was a recent example of this.

Contributor Author

pranavkm commented Feb 3, 2022

Do we need to do this w/ the @(KnownAppHostPack)

I suppose we should - it's also got the SDK-specified version. That said, I don't know how that package gets used in the build.


          Also update KnownAppHostPackVersion

34cce50

Member

dougbu commented Feb 3, 2022

I don't know how that package gets used in the build.

I'm not positive either. I suspect your new commit will primarily affect tests that execute dotnet {something}.

@wtgodbe anything we should be concerned about❔ For example, are there cases where the versions won't align❔ Versions for the app host, runtime pack, and framework reference all match in the couple of SDKs I checked. Just wondering if I'm missing anything in how dotnet/runtime pushes new packages during servicing.

dougbu reviewed

View changes

eng/tools/GenerateFiles/Directory.Build.targets.in Outdated Show resolved Hide resolved


          Update eng/tools/GenerateFiles/Directory.Build.targets.in

0af9400

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment