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

Update .NET Core SDK Url in build on Windows instructions #36939

Merged
merged 1 commit into from
Jul 3, 2019

Conversation

JoeRobich
Copy link
Member

@JoeRobich JoeRobich commented Jul 2, 2019

dotnet-maestro was inconsiderate and updated the dotnet version in global.json without updating the url in Building on Windows documentation.

@JoeRobich
Copy link
Member Author

fyi @agocke & @sharwell

@sharwell
Copy link
Member

sharwell commented Jul 3, 2019

@dotnet/roslyn-infrastructure @nguerrera This is an ongoing problem for external contributors. Visual Studio failed with unusable messages, left me unable to build Roslyn, and there were no links or documentation to fix it. I had to manually craft a download URL using the output from Restore.cmd. We need a solution earlier rather than later.

@JoeRobich JoeRobich merged commit b1a8046 into master Jul 3, 2019
@nguerrera
Copy link
Contributor

@sharwell There are some changes coming in that should help:

  1. Implement roll-forward policies for .NET Core SDK resolution. core-setup#6953 (Will allow setting a proper minimum version without pinning. Also allows setting usePreview=true in global.json without pinning .)
  2. Then we need to do https://github.com/dotnet/cli/issues/11651 to make sure that the most precise error is shown in VS. I'll make sure this gets prioritized.

@nguerrera
Copy link
Contributor

nguerrera commented Jul 3, 2019

Looking a little closer, though, at this specific case, I would not have expected a failure here.

  1. Roslyn does not pin sdk in global.json (It does not use sdk/version field. Arcade repos generally don't due to issues still being resolved as mentioned above. Once those are in, we can specify min version in sdk/version and get good errors when not available.)

  2. ea4ab12#diff-274660eb4b1b1d963a330b471e10f41c took no real dependencies on the new SDK so I would not expect a build using the prior one to fail.

Was the error an issue with a task having bad parameters or failing to load? If so, I think it was the issue where we stopped bumping our assembly version between builds due to an infrastructure change. That was recently fixed as well: dotnet/sdk#3340.

@JoeRobich
Copy link
Member Author

JoeRobich commented Jul 3, 2019

@nguerrera Is this (#36840) the type of error that you expect would be fixed by dotnet/sdk#3340?

1>------ Build started: Project: Microsoft.CodeAnalysis, Configuration: Debug Any CPU ------
1>C:\Program Files\dotnet\sdk\3.0.100-preview6-012264\Sdks\Microsoft.NET.Sdk\targets\Microsoft.PackageDependencyResolution.targets(257,7): error MSB4064: The "DesignTimeBuild" parameter is not supported by the "ResolvePackageAssets" task. Verify the parameter exists on the task, and it is a settable public instance property.
1>C:\Program Files\dotnet\sdk\3.0.100-preview6-012264\Sdks\Microsoft.NET.Sdk\targets\Microsoft.PackageDependencyResolution.targets(234,5): error MSB4063: The "ResolvePackageAssets" task could not be initialized with its input parameters.
1>Done building project "Microsoft.CodeAnalysis.csproj" -- FAILED.

@nguerrera
Copy link
Contributor

Yes, exactly!

@jaredpar jaredpar deleted the dev/jorobich/update-build-sdk branch August 14, 2019 19:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants