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.
dotnet-build will produce a deps file for portable builds, and will now
create "runnable" outputs for RID-less targets
the outputs won't actually be runnable today because we need corehost
changes and to generate a deps.json file for corehost to use.
- Added --version-suffix to build and publish
- Support reading DOTNET_* version variables everywhere versions can be read
- Show the commit sha in dotnet --version
- Added tests that check the assembly output version
- Set DOTNET_BUILD_VERSION when producing the CLI app itself so that it has the version information stamped in for help.
Add TargetFramework and FullTargetFramework to compile and publish script
variables.
Add ProjectLocal Command Resolution Strategy.
Fixup ArgumentEscaper to not always quote things.
Fixes#1216Fixes#1016Fixes#982
- Project dependencies are always built into their specific folders and the main project is the only one that uses the output path and intermediate output path variable.
- Publish respects the output path for publish only, not compile as part of publish. This means that publishing multiple runtimes will stomp on each other. So don't do that. We can throw if you specify and output location and you haven't specified a specific combination of RID and framework. Alternatively it should probably just pick the first TFM/RID pair from the lock file. This is similar to how `dotnet run` works.
- Cleaned up the incremental build output formatting
- Use a single stream (output stream) since interleaving them was causing formatting issues (like losing random characters in the middle of outputting things).
- Didn't change how pack works, it still preserves the output structure when passing `--output`, this one is worth discussing. We could leave the build output inplace and only move the package to the output location. That's more consistent with how everything else works and can be a follow up PR.