This addresses part of #1623. Unfortunately, because the CLI takes Nuget
as a binary, it is hard to get to where I think we should really be.
This change makes default verbosity "minimal", which is the first level
where you get any status output. Unfortunately, things like package
downgrade warnings and the like still appear there. This does hide all
the "info" and "trace" messages by default.
I also removed the now useless (and previously undocumented)
--quiet.
Crossgen is failing in the CI machines with the below error. So trying to add an explicit reference to see if this issue goes away.
17:53:44 Error: Could not load file or assembly 'System.Text.RegularExpressions, Version=4.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
17:53:44 Error compiling /mnt/resource/j/workspace/dotnet_cli/rel_1.0.0/debug_debian8.2_x64_prtest/artifacts/debian.8-x64/stage1/sdk/1.0.0-preview2-002767/dotnet.dll: Could not find or load a specific file. (Exception from HRESULT: 0x80131621)
If invalid parameters are specified in `dotnet test`, the CLI does not
catch exceptions that can be thrown such as when specifying `-r` without
a runtime.
Fixes 3084.
PR #2493 introduced the new project.json schema. The tree has 118 files
with the old schema, which added several hundred warnings.
This change can't go in until PR #2864 does - it relies on those bug
fixes.
There were still README.md files in the dotnet-compile and dotnet-compile-csc folders.
There was also a reference to it in dotnet-publish README.md doc. Removed that.
Fix#2622
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
This is required to update the corefx dependencies from RC2 to RC3. Some
of the corefx libs have 'netstandard1.6' as TFM and this version of Nuget
supports that TFM.
Also the 'VersionRange.IncludePrerelease' has been removed from nuget and by
default 'VersionRange.Satisfies' returns true for any prerelease version.
The following packages are changing:
Microsoft.NetCore.App: 1.0.0-rc2-3002702 -> 1.0.0-rc3-002702
Microsoft.NETCore.DotNetHost: 1.0.1-rc2-002702-00 -> 1.0.1-rc3-002702-00
Microsoft.NETCore.DotNetHostPolicy: 1.0.1-rc2-002702-00 ->
1.0.1-rc3-002702-00
Microsoft.NETCore.DotNetHostResolver: 1.0.1-rc2-002702-00 ->
1.0.1-rc3-002702-00
Also publishing the *deb file to teh debian repo feed is disabled -
https://github.com/dotnet/cli/issues/2973
Moves CLI version suffix from preview1 to preview2
Sets channel for preview2 to 1.0.0-preview2, abandoning the Beta channel to the 1.0.0-preview1 release. Once @sokket's publishing cleanup work is complete we can re-converge the channels if desired.
Removed all unnecesary code if opted out of telemetry.
Shanged sample rate to 1 for testing purposes.
CI to just regular Test
Changed hash helper function to handle a list<string> to optimize unneceary duplicate sha256 creation
Reduced new memory allocations
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
- 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
Since we write to the console and create new processes and read from their stdout and stderr, we need to ensure we have all the code pages in our process. This way we can encode/decode strings correctly when writing to our Console, and when reading from spawned process's output.
Fix#2486
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.
- 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
