Improve dotnetup Muxer Handling, In-Use Muxer + Perf#9
Closed
nagilson wants to merge 2 commits intonagilson-dnup-install-runtimes-implfrom
Closed
Improve dotnetup Muxer Handling, In-Use Muxer + Perf#9nagilson wants to merge 2 commits intonagilson-dnup-install-runtimes-implfrom
dotnetup Muxer Handling, In-Use Muxer + Perf#9nagilson wants to merge 2 commits intonagilson-dnup-install-runtimes-implfrom
Conversation
When moving the .NET SDK build to use `dotnetup`, I hit several issues. The main issue is that the dotnet muxer may be in use when dotnetup tries to replace it, which would cause a failure. I don't think we want to fail in this case and instead we want to emit a warning. Maybe there should be an option to fail instead, however. What I also realized is that the approach of renaming the muxer even if it doesn't need to be replaced would cause the warning message to appear even if we didn't need to replace the muxer. Then I realized, we can do something clever. The windowsdesktop runtime has no runtime so we can skip muxer logic there. The other runtimes versions are the deciding factor for the muxer version since the muxer doesn't have its own version, so we can skip the resolution to find the version there. For the SDK, what we can do to avoid an extra rename of the existing muxer if it doesn't need to be replaced, is to extract out the new muxer to a different name temporarily, and then look and see if the latest runtime in the dotnet install root target changed after that install. If so then the runtime that came with the SDK is newer so the new muxer should be used. This lets us gracefully handle when the muxer is in use as well as avoid any extra work we don't need to do.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
When moving the .NET SDK build to use
dotnetupin #8, I hit several issues. The main issue is that the dotnet muxer may be in use when dotnetup tries to replace it, which would cause a failure.I don't think we want to fail in this case and instead we want to emit a warning. I've added an option to fail instead, however.
What I also realized is that the approach of renaming the muxer even if it doesn't need to be replaced would cause the warning message to appear even if we didn't need to replace the muxer. Then I realized, we can do something clever. The windowsdesktop runtime has no runtime so we can skip muxer logic there. The other runtimes versions are the deciding factor for the muxer version since the muxer doesn't have its own version, so we can skip the resolution to find the version there. For the SDK, what we can do to avoid an extra rename of the existing muxer if it doesn't need to be replaced, is to extract out the new muxer to a different name temporarily, and then look and see if the latest runtime in the dotnet install root target changed after that install. If so then the runtime that came with the SDK is newer so the new muxer should be used. This lets us gracefully handle when the muxer is in use as well as avoid any extra work we don't need to do.