Move us to SDK 2.2.0 preview #23494
Move us to SDK 2.2.0 preview #23494
Conversation
When looking to see if we have the proper CLI installed for building need to check the SDK dir, not the CLI directory. This ensures that when we change SDK versions being used we download the appropriate SDK and don't accidentally used the previous install.
Move to the officially supported method of disabling transitive project references for VSIX files.
|
CC @dotnet/roslyn-infrastructure, @nguerrera |
| @@ -23,7 +23,7 @@ If a stack trace is displayed on .NET Framework older than 4.7.1 (e.g. by xUnit | |||
| 1. [Visual Studio 2017 Update 3](https://www.visualstudio.com/vs/) | |||
| - Ensure C#, VB, MSBuild and Visual Studio Extensibility are included in the selected work loads | |||
| - Ensure Visual Studio is on Version "15.3" or greater | |||
| 1. [.NET Core SDK 2.1](https://www.microsoft.com/net/download/core) (if you don't see the 2.1 SDK binaries there yet, the current previews are: [Windows x64 installer](https://dotnetcli.blob.core.windows.net/dotnet/Sdk/2.1.1-preview-007094/dotnet-sdk-2.1.1-preview-007094-win-x64.exe), [Windows x86 installer](https://dotnetcli.blob.core.windows.net/dotnet/Sdk/2.1.1-preview-007094/dotnet-sdk-2.1.1-preview-007094-win-x86.exe)) | |||
| 1. [.NET Core SDK 2.2](https://www.microsoft.com/net/download/core) (if you don't see the 2.1 SDK binaries there yet, the current previews are: [Windows x64 installer](https://dotnetcli.blob.core.windows.net/dotnet/Sdk/2.2.0-preview1-007622/dotnet-sdk-2.2.0-preview1-007622-win-x64.exe), [Windows x86 installer](https://dotnetcli.blob.core.windows.net/dotnet/Sdk/2.2.0-preview1-007622/dotnet-sdk-2.2.0-preview1-007622-win-x86.exe)) | |||
There was a problem hiding this comment.
Still a "2.1" in there.
There was a problem hiding this comment.
Ah good catch. Will fix.
The abscence of the 2.0.0 shared runtime seems to be the cause of our CoreClr based suite failures. Hard coding the download of the runtime to verify this is the case. Will work on a better fix after it's verified.
The .NET Core workload brings down the shared runtime component. That is needed when our core clr tests are run.
|
CC @khyperia as I made some changes to obtain_dotnet.sh |
Need to be on 15.4 in order for the .NET core workload to bring along the 2.0.0 runtime.
|
@jasonmalinowski addressed your feedback. |
Wait, did I forget to hit submit on this comment? Was going to say the changes to the shell script look good. Caching the download is possible, but then there's the headache of cleaning up the temp file, so it's up to you which you prefer (extra download, or manually managing a file) |
|
retest windows_release_unit32_prtest please |
Sounds like it was working before. :\ These changes are always a pain downstream. |
Can you clarify what you mean by that? |
We were using a workaround which was clumsy of course but got the job done. There may be other reasons why the new SDK is necessary, but I look at changes like this and just wish it could wait long enough until the SDK makes its way into a VS release so the separate install isn't necessary. |
Feel like this is conflating issues. There are two things you mention here:
As for (1) The repo has depended on a separate install of the SDK since before 15.3 released. This change doesn't impact that story, it only changes the version which we are using. As for (2) the primary motivator is the ability to disable transitive references as a feature, not as a hack. There are other changes in flight which also depend on the 2.2 SDK. |
Yes, localization work depends on it and a sane process for getting a localized compiler in to the CLI depends on the localization work. |
This moves us to the SDK version 2.2.0-preview1-007622. This version has the feature which allows us to disable implicit transitive project references. This is necessary for us to build and previously we were accomplishing it via a hacky
<Target>override.