-
Notifications
You must be signed in to change notification settings - Fork 325
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
Make vstest.console, and datacollector upgrade across major .NET version #3561
Conversation
My only concern here is what dotnet SDK actually does with our runtimeconfig.json and if we can strip the preference there, because we want to keep it working as is. What users currently see:
|
Updated the description and code to use Major, instead of LatestMajor, so we can ship this asap. No shipments in sdk use LatestMajor, except for dotnet-format which is a dotnet-tool. C:\Program Files\dotnet> ls *.runtimeconfig.json -re | sls rollForward |
/fyi @rouke-broersma @peterwald this will ship in .NET 7, and TP17.3. You both have DOTNET_ROLL_FORWARD policy in place to work around this. |
Cool! I am liking these recent improvements to the portable/client-wrapper workload :) |
@nohwnd Do we need .net7 AND TP17.3 for this to work? I'm currently testing with TP17.3 and .net6 and it's failing with this message:
|
Description
vstest.console and datacollector are our tools and they should be able to run on any .NET version from netcoreapp2.1 onwards. But in the cli, and portable packages we ship runtime config with them that ties them to netcoreapp2.1.
dotnet SDK rewrites our runtime.config.json to use the same version as what the SDK is, but our nugets don't have that change, and tooling authors work around this by setting DOTNET_ROLL_FORWARD policy by environment variables, which inherits downwards to testhost where that policy is undesirable.
Setting RollForward in our project will emit it in runtimeconfig.json and will tell vstest.console and datacollector and allows us to upgrade to a newer runtime even across major version. This won't upgrade to pre-releases, and won't upgrade to the latest version available, because we currently have no way to rewrite this option in the actual SDK shipment.