When the current directory contains a valid project.json, and the user just says `dotnet test project.json`, normalizing the path fails becuase we end up calling Path.GetFullPath with an empty string.
To fix this, if the directory of the file is empty, use the current directory.
Fixing this for all "dotnet XXX" commands.
Fix#2691
- Added PackOptions, RuntimeOptions, PublishOptions and updated CompilationOptions
- Added IncludeFilesResolver to parse include, exclude patterns
- Added compile, embed and copyToOutput to compilationOptions
- Renamed compilationOptions to buildOptions
- Moved compilerName into buildOptions
- This change is backwards compatible
- Added warnings to be shown when the old schema is used
- Handled diagnostic messages in ProjectReader
- Added unit and end to end tests
* 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.
Added unit tests covering parsing of Json for all the pieces of the project.json
Added a RawRuntimeOptions to Project and made Executable deserialize that into the runtimeOptions of runtimeconfig.json
Added tests to cover copying runtimeoptions during dotnet build.
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.
Rather than keep a map that will have to be constantly updated every time
a new argument gets added to a compiler, the 'additionalArguments' option
will allow users to directly add arguments to the underlying compiler.
With this change, any referenced analyzer project will be parsed by the
project system and the assemblies will be passed down to the compiler.
By default, the analyzer language is considered to be "cs". If another
language is used, the "languageID" option should be specified inside the
"analyzerOptions" section of the project.json file.
Resolves#83
Provides a few benefits:
1) The new package has the correct dependencies listed, so I removed the
-MissingDependenciesOK flag from the crossgen scripts.
2) The new compiler supports -publicSign (formerly called "OSS sign"),
which I patched through dotnet-compile-csc .
