When run “dotnet run -- foo”, foo should be the argument passed to the
subject app. After replacing the original parser, dotnet-run did not
utilize the “unparsedtoken” of the parsed result.
To append unparsedtoken to RunCommand’s argument is not straight
forward. RunCommand has an “immutable constructor”, which is a good
thing, so I made update RunCommand’s argument following the immutable
pattern -- create a new object with the original field but only change
the arguments. I also made these filed private set.
Removing duplicate space in "The Current OutputType is" usage
The LocalizableStrings.RunCommandExceptionUnableToRun3 always has as trailing space. Every instances does. Here we are adding a SECOND space so the result is:
The current OutputType is 'Library'.
Microsoft.Extensions.Testing.Abstractions is the only one I couldn't move to netstandard1.3 that should be. But this library should be removed with the new `dotnet test` strategy.
This enables users to use the CLI on newer versions of the OS that aren't fully supported yet - for example using a new OSX version that isn't listed in the runtime graph in the current NuGet packages.
Fix#4238
When running an app with `dotnet run`, we are redirecting the standard out and error just to print it out to our standard out and error. However, we are batching the output until we hit a newline, which isn't ideal for console apps.
To fix this, `dotnet run` no longer redirects the standard out and error.
Fix#2777
we used to use different code when --framework was specified than when it was not specified, this synchronizes them to use the same code path which removes a hidden NullRef
also adds tests to cover both cases
* 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.
DOTNET_HOME is no longer required, though it is a documented override, so this change removes all unnecessary references to DOTNET_HOME from the CLI Repo.
