Skip to content

Conversation

ladipro
Copy link
Member

@ladipro ladipro commented Feb 28, 2023

Fixes #8441

Context

This document aims to capture the core functionality provided by the ResolveAssemblyReference task when building .NET (Core - pun intended) projects. The goal is to rationalize and optimize the task, ultimately achieving substantially better performance and crossing out RAR from the list of notoriously slow build tasks.

Changes Made

Added the document (preview link).

@rainersigwald rainersigwald added the Area: Documentation Issues about docs, including errors and areas we should extend (this repo and learn.microsoft.com) label Mar 28, 2023
@ladipro ladipro added the merge-when-branch-open PRs that are approved, except that there is a problem that means we are not merging stuff right now. label Apr 4, 2023
@rainersigwald rainersigwald merged commit 82fa6f4 into dotnet:main Apr 4, 2023
signalling to RAR that it doesn't have to open the assembly files to read their AssemblyRef tables.

1. Project references. When a project depends on another project, the output file of the dependency is passed to RAR. Alternatively, a project may directly
reference a random file o disk, resulting in the same code path. Unlike SDK and NuGet, these references are not pre-resolved and RAR must open the assembly

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"file on disk"

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

Labels

Area: Documentation Issues about docs, including errors and areas we should extend (this repo and learn.microsoft.com) merge-when-branch-open PRs that are approved, except that there is a problem that means we are not merging stuff right now.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Review current RAR design in light of modern .NET projects

5 participants