* Use a WorkspaceContext in dotnet-build to cache project data across
multiple compilations in a single build action
* Dramatically reduce string and object duplication by introducing a
"Symbol Table" that shares instances of NuGetVersion, NuGetFramework,
VersionRange and string across multiple lock-file parses
Test Results:
* Testing was done by compiling Microsoft.AspNetCore.Mvc (and it's
dependencies) and taking memory snapshots after each compilation in
dotMemory
* We used to allocate ~3MB and deallocate ~2.5MB on EACH compilation in
a single build action. This has been reduced to ~120KB
allocated/deallocated
* After introducing WorkspaceContext, total memory usage spiked from 6MB
across the whole build action to about 13MB, introducing the symbol
table dropped it back to about 5-6MB.
- Every project.json needs portable-net451+win8 and dotnet5.4 imports (required by dotnet-test-xunit).
- If a test references NuGet, it also needs "netstandardapp1.5", because that the TFM NuGet uses currently.
* Fix duplicate dependency issue
If a package has the same name as a framework assembly in the dependency
graph, we usually replace it with the framework assembly if the package
provides no assets. If the framework assembly wasn't resolved, it would
skip this logic and end up adding dupes to the list, which blows up later on.
This is a tactical fix to solve the issue, we need to do some more thinking
to determine how we want to resolve conflicts between framework assemblies,
packages and dlls with the same name.
- Ensure the long names start with `--`
- Handle null strings in UnescapeNewlines
- Handle bool options correctly.
- Allow dotnet run, compile-csc, and compile-fsc to handle .rsp files.
- Allow CommandLineApplication to handle .rsp files.
- Allow CommandOption to handle MultilpeValue options that have "..." at the end of their template.
- Allow CommandOption to handle boolean values with explicit or null values.
Also removed the dependency on Microsoft.Extensions.CommandLineUtils.Sources NuGet package and instead just checking the source files into our repo as internal classes.
Fix#2526
