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

Remove live runtime dependencies #8138

Merged
merged 2 commits into from
Jun 19, 2024
Merged

Conversation

ViktorHofer
Copy link
Member

@ViktorHofer ViktorHofer commented Jun 19, 2024

... use the shared framework that comes with the
SDK instead.

We determined that a live runtime doesn't provide
much benefit anymore and in contrast often
causes pain when flowing dependencies to
dotnet/sdk.

Note: The VMR should react to this when the change reaches dotnet/sdk. This line should be removed: https://github.com/dotnet/sdk/blob/a5ccfef7bea1d8883142ffa632439ca848da9378/src/SourceBuild/content/repo-projects/templating.proj#L12

... use the shared framework that comes with the
SDK instead.

We determined that a live runtime doesn't provide
much benefit anymore and in contrast often
causes pain when flowing dependencies to
dotnet/sdk.
@ViktorHofer ViktorHofer requested a review from a team as a code owner June 19, 2024 07:33
@mmitche
Copy link
Member

mmitche commented Jun 19, 2024

Removed additional args from the YAML

@ViktorHofer
Copy link
Member Author

Cool. So you are OK with this @mmitche and @marcpopMSFT?

@baronfel
Copy link
Member

We had the live runtime flow for testing purposes IIRC - I guess this need was largely removed when the dotnet new command migrated to dotnet/sdk?

@ViktorHofer ViktorHofer merged commit 5a1e982 into main Jun 19, 2024
10 checks passed
@ViktorHofer ViktorHofer deleted the RemoveLiveRuntimeDependency branch June 19, 2024 15:27
@marcpopMSFT
Copy link
Member

nymore and in contrast often
causes pain when flowing dependencies to
dotnet/sdk.

This was my thinking as well. I think there is some marginal benefit but it's not significantly different than any of the other tooling repos (ie we might catch something in the runtime because of how the tooling is implemented but because of limitations in our build system, better to just add a test to the sdk repo if we need coverage).

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.

5 participants