* Migrate "runtimes" section as a RuntimeIdentifiers property in the resulting csproj file. Also do not call restore3 from publish3 anymore.
* Fix up the publish3 tests to call restore3 first and the csproj files to have RuntimeIdentifiers
* Implemented vstest verb which will run the test from given container.
* Fixed Nitpick.
* 1) Addressed PR comment
2) Added tests for vstest verb
* Using specific version of Microsoft.TestPlatform.
* Address PR comments.
Modified help text for the vstest command.
Removed unused function.
* Fixed package related issue.
--Taking reference of microsoft.testplatform.cli nuget package which has contentFolder in it so that sub folder of this nuget can also be added in cli package.
-- Removing vstest.console, vshost and datacollector from Bundletools as we dont want *.deps.json to be override
* Nitpick
* Making vstest.console arguments compatible for non windows platform
* Fix tests to run on linux machine
* Updated the microsoft.testplatform.cli nuget package version. This version has fix related to non windows machine.
* changed dapter path from bin/debug to bin/Debug
* updated nuget version of package Microsoft.TestPlatform.CLI.
* Revert "updated nuget version of package Microsoft.TestPlatform.CLI."
This reverts commit bcc26c21d11c2bd2e5259a74f9890b0fd75962c7.
* Updated version of nuget package Microsoft.TestPlatform.CLI
Added Test project in solution file
* Addressed PR comment.
* Removed unnecessary --platform argument from test
Creates a TestDirectory abstraction under TestInstance to manage creation of test-specific working directories
Enables TestAssetManager to create TestDirectory instances
Enables fluent addition of Environment Variables to TestCommand
Adds PathUtility support for ensuring a directory exists
When using a ruleset with a relative path in buildOptions, csc can't
find the file because it is not working in the same directory as the
project.
Fix#2710
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.
