* Rebase
* Remove Multi-Project Validator
* Remove projectmodelserver tests
* Enable test package creation
* Incremental test restore
* WiP
* Enable Test Asset Project restore
* Build Test Assets & Restore Test Projects
* Build Test projects
* Enable Test Execution
also moves Test Targets to a well-known CLI Version [Stage 2]
* Pass throuh existing telemetry profile
* 2-space tabs
* Revert TestTargets.cs
* WiP PR feedback
* Refactoring
* Fix naming of RestoreTestAssetPackages
* DotNetTest task
* Fix merge issue
* ExecuteWithCapturedOutput
MSBuild considers StdErr output to be failures. This causes output of any test command which is expected to produce an error to be swallowed in the test.
* Workaround for always-on tracing functionality in dotnet-test
* Fix Path Separator Windows/Unix
* Seperate package build from pack
* Windows Pathing issues
* PR Feedback
* Workaround for msbuild #773https://github.com/Microsoft/msbuild/issues/773
* Update README.md
* Moving Ubuntu 16.04 to be next to Ubuntu 14.04
* Adding Oracle Linux and Linux Mint to the titles
Adding Oracle Linux and Linux Mint to the titles next to their compatible binaries.
* Remove showing firsttime eula for non verbs.
* Add Serviceable assembly attribute and nuspec attributes for all shipping CLI assemblies.
Fix#3345
* Use NugetCache Sentinel for Telemetry setting.
* Fix Oracle Linux version in README.md
Oracle Linux 7 -> Oracle Linux 7.1
* Fix README to use hostfxr download links (#3622)
Also fix a rebase error from b524fd079e6dcdd744faeb6061ccbfe99d1f810f#diff-04c6e90faac2675aa89e2176d2eec7d8
* Remove the VS2012 CRT dependency from docs (#3632)
* fix typo in dotnet-install file
This was needed to rebuild the CLI with the updated Roslyn NuGet packages.
Thanks goes to @akoken for the fix.
* Fix the project.json for C# library and add tests
This commit fixes the bug introduced in project.json for the C# Library
template. It also adds two simple tests for the library template that
drop the class library and then restore and another that also builds.
Fixes#3496
- Created a Configurer class that is responsible for deciding when to run the dotnet first time use
experience and invoke the NuGetCachePrimer.
- Added the NuGetCachePrimer which extract the archive and primes the cache.
-- This is just missing creating the sentinel once restore succeeds.
- Added a shell for the NugetPackagesArchiver, which will be responsible for expanding the archive (likely
replaced in the future by an abstraction from Eric's code or its implementation will simply call Eric's code).
- Added a TemporaryFolder abstration to Internal Abstractions that handles deleting the temporary folder once
we are done with it.
The perf tests use `dotnet restore` to download test dependencies. The
perf tests' project.json may sometimes refer to a version of the
framework that is not yet published, which can cause the restore command
to fail. This change addresses the issue by adding a fallback nuget feed
that contains not-yet-published version of the framework.
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.
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.
When building a project.json that has schema warnings (and other warnings), we are not writing the warnings to the console. This is a regression.
The fix is to add all diagnostic messages to the LibraryManager, which is responsible to hold all the diagnostic messages.
Fix 3021
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
* Throw Command Unknown for dependency tools in libraries.
* Add testProjects to test tools command for libraries.
* update failing tests
* Add tests verifying that dependency tools are not available in libraries
The issue is when the ProjectContextBuilder sees a CompileTimePlaceholder "_._" file on a full framework, it assumes that dependency has to come from the "Reference Assemblies" directory. If it can't be found there, an error is raised. However, there are other reasons "_._" placeholders are created (when a NuGet package doesn't want its dependencies to be exposed in the Compile dependencies of its consumers). And these placeholders can exist for assemblies that aren't in the full framework - in this case System.Diagnostics.FileVersionInfo and others.
To fix this, if the reference can't be resolved from the "Reference Assemblies" folder, it is just skipped. If the compiler really needs that assembly, it will raise an error to the user. Dotnet build shouldn't raise the error.
Fix#2906
Simple tests which does static analysis of managed assemblies metadata to
make sure that they are crossgened. Currently it verifies that all the
assemblies in CLI SDK and SharedFx directroty are crossgened.
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
* Add script to run and compare CLI perf tests
tests/Performance/run-perftests.py is a Python3 script that fetches all
of the dependencies needed to run the perf tests in test/Performance
locally. It can run the perf tests for a single dotnet.exe, or run two
dotnet.exe instances sequentially and compare the results between them.
Basic usage for a single test:
run-perftests.py --name "runid" ...\dotnet.exe
Usage for a comparison run:
run-perftests.py --name "runid" ...\dotnet.exe --base ...\dotnet.exe
For more detailed usage:
run-perftests.py -h
* run-perftests: fix publish xunit.perf.runner.cli
The code that builds xunit-performance would skip publishing
Microsoft.DotNet.xunit.performance.runner.cli due to a bug in the
condition to check whether it was published already or not. To fix the
issue and simplify the logic, I'm making it always publish when
building the project, instead of building and publishing separately.
* run-perftests: add support for python2
* run-perftests.py: fix framework version issue
The perf test harness was failing with "stage 0" binaries due to an issue
finding the correct installed framework version. The fix is to delete the
project.lock.json followed by a dotnet restore before each run, using the
dotnet.exe that is about to be tested. (Kudos to @brianrob for the debugging
help and suggested fix!)
The BuiltInCommandTests sets the current Console.Out and Console.Error, which causes the test to fail if some other test is running and writes to the console at the same time.
Fix#2768
The compile unit test needed to be updated to mock out a new call to ICommand.WorkingDirectory.
The test unit test needed to account for build-base-path getting fully qualified.
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
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.
- Every project.json needs portable-net451+win8 and dotnet5.4 imports (required by dotnet-test-xunit).
- If a test references NuGet, it also needs "netstandardapp1.5", because that the TFM NuGet uses currently.
* Fix duplicate dependency issue
If a package has the same name as a framework assembly in the dependency
graph, we usually replace it with the framework assembly if the package
provides no assets. If the framework assembly wasn't resolved, it would
skip this logic and end up adding dupes to the list, which blows up later on.
This is a tactical fix to solve the issue, we need to do some more thinking
to determine how we want to resolve conflicts between framework assemblies,
packages and dlls with the same name.
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
add tests for the projectdependenciescommandfactor
Add a test variation to test overriding the configuration provided in the constructor
update test asset name
* Add satellite assemblies to deps file with locale data
* Publish satellite assemblies to output during publish
* Copy satellite assemblies from project-to-project dependencies on
build and publish
