Skip to content
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

Delpoy ExternalAccess.RazorCompiler with compiler #70203

Merged
merged 2 commits into from
Oct 2, 2023

Conversation

jaredpar
Copy link
Member

@jaredpar jaredpar commented Oct 1, 2023

This moves the MS.CA.EA.RazorCompiler to deploy with the roslyn compiler. This DLL has IVT with the compiler which means it's relationship is not tracked through the public API tracker.

This problem came to light by digging into the fallout from a subtle binary breaking change in the compiler that invalidated earlier versions of the EA.RazorCompiler DLL. That made it apparent our previous deployment strategy was incorrect.

Deploying with the compiler should both fix our present issue (inability to insert Roslyn) as well as tearing issues that could come once the change is released. The compiler will prefer dependencies in its directory over ones deployed with analyzers. That means existing versions of razor that deploy the EA DLL (compat or incompat version) will be overruled by the version deployed next to the compiler.

I locally verified that this copy is preferred over the the EA deployed with razor today (dotnet and msbuild). There are tests that verify this behavior in the compiler already but I wanted manual verification as well.

This moves the MS.CA.EA.RazorCompiler to deploy with the roslyn
compiler. This DLL has IVT with the compiler which means it's
relationship is not tracked through the public API tracker.

This problem came to light by digging into the fallout from a subtle
[binary breaking](dotnet#70082) change in
the compiler that invalidated earlier versions of the EA.RazorCompiler
DLL. That made it apparent our previous deployment strategy was
incorrect.

Deploying with the compiler should both fix our present issue (inability
to insert Roslyn) as well as tearing issues that could come once the
change is released. The compiler will prefer dependencies in its
directory over ones deployed with analyzers. That means existing
versions of razor that deploy the EA DLL (compat or incompat version)
will be overruled by the version deployed next to the compiler.

I locally verified that this copy is preferred over the the EA deployed
with razor today (dotnet and msbuild). There are tests that verify this
behavior in the compiler already but I wanted manual verification as
well.
@jaredpar jaredpar requested review from a team as code owners October 1, 2023 16:31
@dotnet-issue-labeler dotnet-issue-labeler bot added Area-Compilers untriaged Issues and PRs which have not yet been triaged by a lead labels Oct 1, 2023
@@ -81,4 +81,4 @@
"src\\Workspaces\\VisualBasic\\Portable\\Microsoft.CodeAnalysis.VisualBasic.Workspaces.vbproj"
]
}
}
}
Copy link
Contributor

Choose a reason for hiding this comment

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

was this change just a sort?

Copy link
Member Author

Choose a reason for hiding this comment

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

Appears to have been by solution explorer.

@RikkiGibson
Copy link
Contributor

Not sure if the determinism failure was actually related to the change. Let's try and merge and create an insertion today if we can, just so we can start Monday on the right foot.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-Compilers untriaged Issues and PRs which have not yet been triaged by a lead
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants