Skip to content

Conversation

@oleksandr-didyk
Copy link
Contributor

Summary of the changes

Contributes to dotnet/source-build#3043

Declaring the Microsoft.Extensions.ObjectPool dependency in Version.Details.xml will allow source-build to replace the currently used 6.0.0 version with the n-1 version coming from previously source-built artifacts in the product / VMR build.

Without this change, once repo PvP is enabled for razor, a ref pack of Microsoft.Extensions.ObjectPool would be used instead of a live version, causing a build break for projects that want to utilize the package for source generation. Example of such failure - https://dev.azure.com/dnceng-public/public/_build/results?buildId=284887&view=results

</Dependency>
<!-- Necessary for source-build. This allows the package to be retrieved from previously-source-built artifacts
and flow in as dependencies of the packages produced by razor. -->
<Dependency Name="Microsoft.Extensions.ObjectPool" Version="6.0.0">
Copy link
Member

Choose a reason for hiding this comment

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

Can this be a live version? I am surprised the repo source-build legs don't encounter the same issue as the product build in that it is trying to load the reference package.

Copy link
Contributor Author

@oleksandr-didyk oleksandr-didyk May 25, 2023

Choose a reason for hiding this comment

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

I'm guessing since it only packages the DLL in the intermediate and does not actually load it in, similar to what Arcade did with CodeAnalysis.CSharp and DependencyModel (with the issue with these ref packs only surfacing in its consumer - runtime)

Copy link
Member

Choose a reason for hiding this comment

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

Right, I understand that part.

I think I just answered my question in that the smoke-tests are what caught this. We don't have anything that is running tests against the intermediate packages.

Copy link
Member

Choose a reason for hiding this comment

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

Ideally this would be a live version in order to eliminate potential differences in the product source-build versus the source-build repo leg.

Copy link
Member

Choose a reason for hiding this comment

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

Not sure that is possible with the tooling repos since they potentially go into multiple releases...IDK

@oleksandr-didyk
Copy link
Contributor Author

oleksandr-didyk commented May 31, 2023

@dotnet/razor-tooling soft ping, would be great if we could have someone review this small PR, thank you!

@oleksandr-didyk
Copy link
Contributor Author

@davidwengier thank you for the review!

Could you also please merge the PR? I unfortunately do not have write permissions to the repo so can't do it myself. Thanks!

@davidwengier davidwengier enabled auto-merge June 1, 2023 12:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants