Bump MSBuild Version to 15.1.0-preview-000503-01 #5199
7 participants
|
@jeffkl looks like the change you were telling us about [ |
|
For reference: |
|
Yes you'll need to either place the Roslyn stuff under a Roslyn subfolder or set |
|
@dotnet-bot test Ubuntu x64 Release Build please. |
|
@jaredpar FYI, 2.0.0-rc3-61212-03 is the maximum version of Roslyn we were able to move to. The next version took on System.Security.Cryptography* 4.3.0 which is > what is in the 1.0.0-1.0.3 shared frameworks. 4.3.0 IS available in NetCore.App 1.1, but we have a number of blockers to get through before CLI can be made to function there, so we're capped at the moment. |
| @@ -124,7 +124,7 @@ Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "Microsoft.DotNet.TestFramew | ||
| EndProject | ||
| Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "redist", "src\redist\redist.csproj", "{098D9321-1201-4974-A75E-F58EBCD98ACF}" | ||
| EndProject | ||
| -Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "tool_csc", "src\tool_csc\tool_csc.csproj", "{A0670C63-BA7A-4C1B-B9A7-1CA26A7F235C}" | ||
| +Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "tool_roslyn", "src\tool_roslyn\tool_roslyn.csproj", "{A0670C63-BA7A-4C1B-B9A7-1CA26A7F235C}" |
| @@ -5,6 +5,7 @@ | ||
| <clear /> | ||
| <add key="dotnet-core" value="https://dotnet.myget.org/F/dotnet-core/api/v3/index.json" /> | ||
| <add key="cli-deps" value="https://dotnet.myget.org/F/cli-deps/api/v3/index.json" /> | ||
| + <add key="roslyn" value="https://dotnet.myget.org/f/roslyn/api/v3/index.json" /> |
CLI-Deps wasn't caught up yet. Will remove once it's back up to speed, in a future PR.
| @@ -15,9 +16,6 @@ | ||
| <CLITargets Condition=" '$(CLITargets)' == '' ">Prepare;Compile;Test;Package;Publish</CLITargets> | ||
| <Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration> | ||
| - <RepoRoot>$(MSBuildThisFileDirectory)</RepoRoot> | ||
| - <CLIBuildFileName>$(RepoRoot)/build_projects/dotnet-cli-build/bin/dotnet-cli-build</CLIBuildFileName> | ||
| - <CLIBuildDll>$(CLIBuildFileName).dll</CLIBuildDll> |
| @@ -10,9 +10,8 @@ | ||
| <ItemGroup> | ||
| <PublishOutputExtensions Include="$(ExeExtension);.dll;.pdb;.deps.json;.runtimeconfig.json" /> | ||
| - <FilesToMove Include="$(BinaryToCorehostifyRelDir)/csc.exe;" /> |
| + Output="$(SdkOutputDirectory)/Roslyn" | ||
| + Configuration="$(Configuration)" | ||
| + VersionSuffix="$(CommitCount)" | ||
| + ProjectPath="$(SrcDirectory)/tool_roslyn/tool_roslyn.csproj" /> |
Note, did not duplicate /p:GenerateRuntimeConfigurationFiles=true, setting the property in tool_csproj instead. This and other changes allow that csproj file to be independently build/publish-able. That greatly improved my dev cycle.
| <CLI_NETSDK_Version>1.0.0-alpha-20161230-1</CLI_NETSDK_Version> | ||
| + <CLI_Roslyn_Version>2.0.0-rc3-61212-03</CLI_Roslyn_Version> | ||
| <CLI_WEBSDK_Version>1.0.0-alpha-20161205-1-154</CLI_WEBSDK_Version> |
Had to bump Roslyn so dependencies of it + MSBuild didn't clash. This is the maximum Roslyn version CLI can take until we move to NetCore.App 1.1+
| - <PropertyGroup> | ||
| - <NuGetPackagesDir>$(NUGET_PACKAGES)</NuGetPackagesDir> | ||
| - <NuGetPackagesDir Condition=" '$(NuGetPackagesDir)' == '' ">$(RepoRoot)/.nuget/packages</NuGetPackagesDir> | ||
| - </PropertyGroup> |
|
Is the plan to eventually move to Net Core App 1.1 though? |
|
@jaredpar eventually... We hoped to do this in 1.0 but hit blockers. Right now moving cli onto 1.1 is not a priority. |
|
Think we need to start a conversation with @tmat then. He is the one that pushed us to Net Core 1.1. Based on my understanding of the dependencies here, admittedly limited, this means that CLI would need to be a Net App 1.1 in order to properly consume us. |
| + ProjectPath="$(SrcDirectory)/redist/redist.csproj" | ||
| + MSBuildArgs="/p:GenerateRuntimeConfigurationFiles=true" /> | ||
| + | ||
| + <!-- Publish DotNet --> |
Publish Roslyn? Personally, I find this comment kind of useless. Just look at the ProjectPath.
| @@ -0,0 +1,63 @@ | ||
| +<Project Sdk="Microsoft.NET.Sdk" ToolsVersion="15.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003"> | ||
| + <Import Project="$([MSBuild]::GetDirectoryNameOfFileAbove($(MSBuildThisFileDirectory), dir.props))\dir.props" /> | ||
| + <Import Project="$([MSBuild]::GetDirectoryNameOfFileAbove($(MSBuildThisFileDirectory), dir.props))\dir.tasks" /> |
Should we go ahead and create a PreReq target in our build just to prep these things?
|
|
piotrpMSFT |
f121fc2
|
|||
|
|
piotrpMSFT |
ea3bace
|
|||
|
|
jonsequitur |
7f0f2ea
|
|||
|
|
piotrpMSFT |
080aafa
|
|||
|
|
piotrpMSFT |
1346aa7
|
|||
|
|
piotrpMSFT |
f411db5
|
|||
|
|
piotrpMSFT |
d68e0c3
|
|||
|
|
piotrpMSFT |
All checks have passed |
19bbe20
|
This PR bumps:
The change required CLI to absorb the new layout of Roslyn on-disk. Specifically, Roslyn now must be deployed to
$(MSBuildToolsPath)/Roslyninstead of being deployed to$(MSBuildToolsPath)directly. The CLI must still compose a runnable CSC.exe [generate runtimeconfig.json + deps.json] but this now happens inside of the Roslyn directory.This change required performing a second publish during the CLI build. A side-effect of that is the duplication of a number of Framework binaries that do not ship in the Shared Framework, specifically:
as well as some framework-specific implementation binaries. We will likely need to do some de-duping work in CLI [likely with --additional-probing-path] during our final 1.0 size push. The duplication led to an 18MB [20%] size increase on my dev build. I chose to move forward so we have functionality in-place and can improve perf [size] in the RTM milestone.
While making this change we identified that a change in Roslyn 2.0.0-rc3-61212-04 prevents CLI from picking up that, or a higher, Roslyn version so I locked this PR back to this December build. The specific issue is that Roslyn took on a Microsoft.NetCore.App dependency [at least for System.Security.Cryptography.] which is not available in the 1.0. Shared Framework. Since CLI is built on 1.0 at the moment and @eerhardt just ran into blockers that prevent us from moving forward, we are not currently able to move forward to newer compilers. I ping'd @jaredpar about this below as FYI.
Since this change touches a lot of CLI build system internals, I've commented the code in this PR to help folks see what's going on.
@jonsequitur @jgoshi @krwq @livarcocc @piotroko for code review
@srivatsn for signoff
@jeffkl @rainersigwald FYI