Fix compiler references when building inside VS #54614
Conversation
If for a source project a contract project exists, then the contract project's TargetPath should be passed to the compiler. This is handled by the SDK by default when `ProduceReferenceAssembly` is true. As dotnet/runtime doesn't use the `ProduceReferenceAssembly` feature yet, a custom target adds the necessary `ReferenceAssembly` metadata to the `TargetPathWithTargetPlatformMoniker` item which then is transformed to references for the compiler. That works fine on the CLI as the `GetTargetPathWithTargetPlatformMoniker` target runs after the ProjectReference to the ContractProject is resolved and its target path is available. Inside VS the target ordering is different and the `ResolvedMatchingContract` item was empty as the ProjectReference to the contract wasn't yet resolved. The fix for that is to add a dependency onto the `ResolveProjectReferences` target to guarantee that the `ResolvedMatchingContract` item is populated in time. Noticed this when the build of System.ComponentModel.Composition.Registration failed because the implementation assembly of System.ComponentModel.Composition was passed to the compiler instead of the reference assembly.
|
Tagging subscribers to this area: @Anipik, @safern, @ViktorHofer Issue DetailsIf for a source project a contract project exists, then the contract project's TargetPath should be passed to the compiler. This is handled by the SDK by default when Noticed this when the build of System.ComponentModel.Composition.Registration failed because the implementation assembly of System.ComponentModel.Composition was passed to the compiler instead of the reference assembly.
|
|
Failure is #54643 |
…bugger2 * origin/main: (107 commits) Disable MacCatalyst arm64 PR test runs on staging pipeline (dotnet#54678) [WASM] Fix async/await in config loading (dotnet#54652) Fix for heap_use_after_free flagged by sanitizer (dotnet#54679) [wasm] Bump emscripten to 2.0.23 (dotnet#53603) Fix compiler references when building inside VS (dotnet#54614) process more TLS frames at one when available (dotnet#50815) Add PeriodicTimer (dotnet#53899) UdpClient with span support (dotnet#53429) exclude fragile tests (dotnet#54671) get last error before calling a method that might fail as well (dotnet#54667) [FileStream] add tests for device and UNC paths (dotnet#54545) Fix sporadic double fd close (dotnet#54660) Remove Version.Clone from AssemblyName.Clone (dotnet#54621) [wasm] Enable fixed libraries tests (dotnet#54641) [wasm] Fix blazor/aot builds (dotnet#54651) [mono][wasm] Fix compilation error on wasm (dotnet#54659) Fix telemetry for Socket connects to Dns endpoints (dotnet#54071) [wasm] Build static components; include hot_reload in runtime (dotnet#54568) [wasm][debugger] Reuse debugger-agent on wasm debugger (dotnet#52300) Put Crossgen2 in sync with dotnet#54235 (dotnet#54438) ...
ghost
locked as resolved and limited conversation to collaborators
If for a source project a contract project exists, then the contract project's TargetPath should be passed to the compiler. This is handled by the SDK by default when
ProduceReferenceAssemblyis true. As dotnet/runtime doesn't use theProduceReferenceAssemblyfeature yet, a custom target adds the necessaryReferenceAssemblymetadata to theTargetPathWithTargetPlatformMonikeritem which then is transformed to references for the compiler. That works fine on the CLI as theGetTargetPathWithTargetPlatformMonikertarget runs after the ProjectReference to the ContractProject is resolved and its target path is available.Inside VS the target ordering is different and the
ResolvedMatchingContractitem was empty as the ProjectReference to the contract wasn't yet resolved. The fix for that is to add a dependency onto theResolveProjectReferencestarget to guarantee that theResolvedMatchingContractitem is populated in time.Noticed this when the build of System.ComponentModel.Composition.Registration failed because the implementation assembly of System.ComponentModel.Composition was passed to the compiler instead of the reference assembly.