Is there going to be a .NET Core 2.2 Preview 1 in source-build?

[omajid]

I see that .NET Core 2.2 Preview 1 was announced: https://github.com/dotnet/core/blob/master/release-notes/2.2/preview/2.2.0-preview1.md

Is source-build going to include a version of that? Or is source-build going to catch up closer to when 2.2 is about to be released?

Sorry if a ticket/tracker for this exists. I took a quick look and didn't see one.

[dagood]

Merging #694 got us on the same build/sources as the 2.2 Preview 1 release, but we haven't tagged it quite yet. @dseefeld @crummel @dleeapho

Thanks for filing this, I think it'll be a good tracking issue. 😄

[dagood]

I tagged v2.2.0-preview1 and v2.2.100-preview1-SDK. We're considering making a GitHub "release" for this, so I'm leaving this open tracking that.

[dagood]

Done! In addition to the tags we have https://github.com/dotnet/source-build/releases/tag/v2.2.0-preview1.

[omajid]

I did a comparsion between source-build's result and Microsoft's download (from https://www.microsoft.com/net/download/thank-you/dotnet-sdk-2.2.100-preview1-linux-x64-binaries). Just based on the file names and versions, some things jumped out:

name	source-build	microsoft
sdk tarball name	dotnet-sdk-2.2.100-linux-x64.tar.gz	dotnet-sdk-2.2.100-preview1-009349-linux-x64.tar.gz
framework version	2.2.0-servicing-26820-02	2.2.0-preview-26820-02
sdk version	2.2.100	2.2.100-preview1-009349

[omajid]

I did a diff of the file listings between the two versions of .NET Core 2.2.0-preview1 after renaming the sdk and shared dirs to make the versions match. Generated via diff -u <(cd "${DIR1}" && find | sort) <(cd "${DIR2}" && find | sort): https://gist.github.com/omajid/7eec96d6011b800a609b02a9fb531e4f

Things mostly look like what I would expect. But there were a few surprises:

• Some files are only present in source-build's output and not in Microsoft's download:
  • System.Security.Cryptography.Native.Apple.dylib is present in source-build onlly (did it get built locally? is this prebuilt binary leaking in?)
  • Is it expected that System.CodeDom.dll is included with .NET Core? Looking at Is System.CodeDom a part of .NET Core 2? core#1117, I dont know if this is expected.
  • A number of files in /sdk/2.2.100-preview1-009349/Sdks/NuGet.Build.Tasks.Pack/
• There are some unexpected changes in ./sdk/2.2.100-preview1-009349/Templates/ and ./sdk/2.2.100-preview1-009349/TestHost/.
• source-build includes SdkResolvers/NuGet.MSBuildSdkResolver but Microsoft's download includes SdkResolvers/Microsoft.Build.NuGetSdkResolver instead. Are they the same?

[crummel]

Thanks for checking on this Omair!

• For the version number differences, this looks like we didn't stabilize the versions correctly. Unfortunately we've seen this in the past, we have Update output version stabilization settings from ProdCon auto-update #550 for a long-term fix and I've added it to our release checklist for next time.
• I think the Apple files are getting pulled in somehow, not built. I filed Source-build should not include Apple-specific runtime files in its output #737 to fix this.
• I don't think System.CodeDom being omitted will hurt anything - the issue mentioned there with PlatformNotSupported exists in the System.CodeDom we build, but we don't include it in the SDK. I logged an issue to look into why this is happening though, Should we be including System.CodeDom.dll in the SDK? #738.
• The NuGet and MSBuild (SDKResolver) issues are likely the same problem - something was changed in the submodules but they use different project files for source-build so we missed the change. Logged ILMerge does not run in source-build #739 for NuGet and MSBuild project files need fixup #740 for MSBuild.
• The Templates changes are in version numbers only, which don't match the ProdCon version numbers in either case. @dagood any idea what's going on there? Official build has 1.0.2-beta4-20180819-1962051 vs their ProdCon version 20180820-01. Our build has our supplied version number 1.0.2-beta2-20170727-301.
• TestHost is interesting because at one point we did not think it should be included. Needing the full-framework assemblies is in general a problem we know how to deal with now but I'm curious why this changed. Bringing the original issue back up to triage.

[omajid]

Thanks for following up!

[dagood]

The Templates changes are in version numbers only, which don't match the ProdCon version numbers in either case. @dagood any idea what's going on there? Official build has 1.0.2-beta4-20180819-1962051 vs their ProdCon version 20180820-01.

This is a mismatch in how the package versions are generated vs how the version is passed into the manifest Build element. I don't think this will be fixed (but I don't think we need these to match).

Our build has our supplied version number 1.0.2-beta2-20170727-301.

For this, filed #742 for followup.