Analyze prebuilts for msbuild

[dseefeld]

The following prebuilt packages are included as dependencies in source-build by msbuild. These need to be analyzed to determine how to avoid requiring packages that source-build doesn’t build.

1. Change to use the source-built version
2. Package is not critical to product and can be removed. (i.e.test-specific, windows-specific, etc)
3. The package is used as reference only
4. The package should be built in source-build
5. Other – please elaborate on what you think should be done.

For more detailed usage information for these, please see the Usage Exploration tab of the SourceBuildPrebuiltReport.

Prebuilt Status Updated 2019-06-24

Up to date prebuilt status can now be found in the SourceBuildPrebuiltReport in the Repo Status Data tab.

Prebuilt Table Updated 2019-05-07

PackageName	PackageVersion	SourceBuiltVersion	Category
System.CodeDom	4.4.0
System.Collections.Immutable	1.5.0
System.Linq.Parallel	4.0.1
System.Reflection.Metadata	1.6.0
System.Resources.Writer	4.0.0
System.Text.Encoding.CodePages	4.0.1
System.Threading.Tasks.Dataflow	4.6.0

Original Prebuilt Table

PackageName	PackageVersion	SourceBuiltVersion	Category
Microsoft.DiaSymReader.Pdb2Pdb	1.1.0-beta1-62506-02
Microsoft.DotNet.SignTool	1.0.0-beta.19067.6
Microsoft.NETCore.Compilers	2.10.0	3.1.0-beta1-19067-14
Microsoft.Net.Compilers	2.8.0
Microsoft.SymbolUploader.Build.Task	1.0.0-beta-63604-05
System.CodeDom	4.4.0
System.Collections.Immutable	1.5.0
System.Linq.Parallel	4.0.1
System.Reflection.Metadata	1.6.0
System.Resources.Writer	4.0.0
System.Text.Encoding.CodePages	4.0.1
System.Threading.Tasks.Dataflow	4.6.0
XliffTasks	0.2.0-beta-63004-01	0.2.0-beta-000048
sn	1.0.0
vswhere	2.5.2

[rainersigwald]

This will go to @livarcocc (or me); MSBuild is moving from Andy's team.

[livarcocc]

How will source-build interact with Arcade? Is this something that will just work then?

Also, assigned the issue to me.

[rainersigwald]

I suspect that we only really need most of these for our full framework builds, and we could scope the references out in .net core builds in sourcebuild--all of those APIs exist in Core AFAIK, even if sourcebuild isn't building the packages. Shouldn't be a problem to update to Microsoft.NETCore.Compilers or change XliffTasks version.

[nguerrera]

(4) The package should be built in source-build

I don't know why they aren't. They are built by corefx repo, just not in shared framework.

System.CodeDom | 4.4.0 |   |  
System.Text.Encoding.CodePages | 4.0.1 |   |  

(3) The package is used as reference only

(These are all in the shared framework)

System.Collections.Immutable | 1.5.0 |   |  
System.Linq.Parallel | 4.0.1 |   |  
System.Reflection.Metadata | 1.6.0 |   |  
System.Resources.Writer | 4.0.0 |   |  
System.Threading.Tasks.Dataflow | 4.6.0

[nguerrera]

I suspect that we only really need most of these for our full framework builds,

All of the ones in the new list are used for .NET Core. Maybe full framework build is excluded already.

[nguerrera]

System.CodeDom and System.Text.Encoding.CodePages are interesting in that they are not in the shared framework. There are actually a bunch like this spread throughout the tooling with multiple copies. I have some ideas on how to reduce them, and I'm writing a proposal.

[nguerrera]

@dseefeld @dleeapho I've categorized the latest list: #888 (comment)

Two should be source built and the rest are reference only

[nguerrera]

I can't find anytning in corefx repo or patches that would exclude System.CodeDom or System.Text.Encoding.CodePages. Is it a bug in the report that there's no source-built version?

[dseefeld]

I think they aren't built because we don't build allConfigurations in source-build. See #210