Add and modify commands' README files (#2338)
* Add and modify commands' README files Update those READMEs that are outdated. Add READMEs for dotnet pack and dotnet restore as well. * Removing private info, adding feedback alias
This commit is contained in:
Zlatko Knezevic
parent
3a423b1080
commit
c83a2fb6f9
8 changed files with 348 additions and 79 deletions
|
|
@ -1,5 +1,5 @@
|
|||
% DOTNET(1)
|
||||
% Zlatko Knezevic zlakne@microsoft.com
|
||||
% Microsoft Corporation dotnetclifeedback@microsoft.com
|
||||
% January 2016
|
||||
|
||||
# NAME
|
||||
|
|
|
|||
|
|
@ -1,38 +1,87 @@
|
|||
dotnet-build
|
||||
===========
|
||||
% DOTNET-BUILD(1)
|
||||
% Microsoft Corporation dotnetclifeedback@microsoft.com
|
||||
% April 2016
|
||||
|
||||
**NAME**
|
||||
dotnet-build -- Orchestrates the compilation of a project and all its dependencies.
|
||||
## NAME
|
||||
dotnet-build -- builds a project and all of its' dependencies
|
||||
|
||||
**SYNOPSIS**
|
||||
dotnet build[options]
|
||||
## SYNOPSIS
|
||||
|
||||
**DESCRIPTION**
|
||||
dotnet-build [--output]
|
||||
[--build-base-path] [--framework]
|
||||
[--configuration] [--runtime] [--version-suffix]
|
||||
[--build-profile] [--no-incremental] [--no-dependencies]
|
||||
[< project >]
|
||||
|
||||
The build verb orchestrates the compilation of a project: it gathers the dependencies of a project and decides which to compile.
|
||||
## DESCRIPTION
|
||||
|
||||
Users should invoke the Build verb when they want the entire dependency graph compiled, and Compile when they want only a specific project compiled.
|
||||
`dotnet-build` builds multiple source file from a source project and its dependencies into a binary.
|
||||
The binary will be in Intermmidiate Language (IL) by default and will have a DLL extension.
|
||||
`dotnet-build` will also drop a \*.deps file which outlines what the runner needs to run the application.
|
||||
|
||||
Before any compilation begins, the build verb analyzes the project and its dependencies for incremental safety checks. If all checks clear out, then build proceeds with incremental compilation of the project and its dependencies. Otherwise it falls back to non-incremental compilation. Via a profile flag users can choose to receive additional information on how they can improve their build times.
|
||||
Building requires an existence of a lock file which means that a `dotnet-restore` call needs to happen
|
||||
previous to building.
|
||||
|
||||
All the projects in the dependency graph that need compilation must pass the following safety checks in order for the compilation process to be incremental:
|
||||
Before any compilation begins, the build verb analyzes the project and its dependencies for incremental safety checks.
|
||||
If all checks clear out, then build proceeds with incremental compilation of the project and its dependencies;
|
||||
otherwise it falls back to non-incremental compilation. Via a profile flag, users can choose to receive additional
|
||||
information on how they can improve their build times.
|
||||
|
||||
All the projects in the dependency graph that need compilation must pass the following safety checks in order for the
|
||||
compilation process to be incremental:
|
||||
- not use pre / post compile scripts
|
||||
- not load compilation tools from PATH (e.g., resgen, compilers)
|
||||
- use only known compilers (csc, vbc, fsc)
|
||||
|
||||
Please read the [documentation](https://github.com/dotnet/cli/blob/master/src/Microsoft.DotNet.Tools.Compiler/README.md) on Compile for details on compilation and project structure:
|
||||
In order to build an executable application (console application), you need a special configuration section in project.json:
|
||||
|
||||
**Options**
|
||||
```json
|
||||
{
|
||||
"compilerOptions": {
|
||||
"emitEntryPoint": true
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Build inherits all the [Compile command line parameters](https://github.com/dotnet/cli/blob/master/src/Microsoft.DotNet.Tools.Compiler/README.md).
|
||||
Class libraries do not need this special piece of configuration.
|
||||
|
||||
In addition Compile's parameters, Build adds the following flag:
|
||||
## OPTIONS
|
||||
|
||||
`-o`, `--output` [DIR]
|
||||
|
||||
Directory in which to place the built binaries.
|
||||
|
||||
`-b`, `--build-base-path` [DIR]
|
||||
|
||||
Directory in which to place temporary outputs
|
||||
|
||||
`-f`, `--framework` [FRAMEWORK]
|
||||
|
||||
Compile for a specific framework. The framework needs to be defined in the project.json file.
|
||||
|
||||
`-c`, `--configuration` [CONFIGURATION]
|
||||
|
||||
Configuration under which to build. If omitted defaults to "Debug". Possible configuration options are:
|
||||
|
||||
* Debug
|
||||
* Release
|
||||
|
||||
`-r`, `--runtime` [RUNTIME_IDENTIFIER]
|
||||
|
||||
Target runtime to build for.
|
||||
|
||||
--version-suffix [VERSION_SUFFIX]
|
||||
|
||||
Defines what `*` should be replaced with in the version field in project.json.
|
||||
|
||||
`--build-profile`
|
||||
|
||||
--build-profile
|
||||
Prints out the incremental safety checks that users need to address in order for incremental compilation to be automatically turned on.
|
||||
|
||||
--no-incremental
|
||||
Marks the build as unsafe for incrementality. This turns off incremental compilation and forces a clean rebuild of the project dependency graph.
|
||||
`--no-incremental`
|
||||
|
||||
--no-dependencies
|
||||
Ignore project to project references and only build the root project specified to build.
|
||||
Marks the build as unsafe for incremental build. This turns off incremental compilation and forces a clean rebuild of the project dependency graph.
|
||||
|
||||
`--no-dependencies`
|
||||
|
||||
Ignore project-to-project references and only build the root project specified to build.
|
||||
|
|
|
|||
|
|
@ -1,14 +1,14 @@
|
|||
% DOTNET-NEW(1)
|
||||
% Zlatko Knezevic zlakne@microsoft.com
|
||||
% January 2016
|
||||
% Microsoft Corporation dotnetclifeedback@microsoft.com
|
||||
% April 2016
|
||||
|
||||
# NAME
|
||||
## NAME
|
||||
dotnet-new -- Create a new sample .NET Core project
|
||||
|
||||
# SYNOPSIS
|
||||
dotnet new
|
||||
## SYNOPSIS
|
||||
dotnet-new [--type] [--lang]
|
||||
|
||||
# DESCRIPTION
|
||||
## DESCRIPTION
|
||||
The new command provides a convenient way to initalize a valid .NET Core project and sample source code to try out the CLI toolset.
|
||||
|
||||
This command is invoked in the context of a directory. When invoked, the command will result in two main artifacts being dropped to the directory:
|
||||
|
|
@ -16,26 +16,34 @@ This command is invoked in the context of a directory. When invoked, the command
|
|||
1. A sample "Hello World" program that exists in `Program.cs` ( or `Program.fs` ) file.
|
||||
2. A valid `project.json` file
|
||||
|
||||
> **Note:** As a workaround for packages not being on NuGet.org yet (since this is prelease software) the `dotnet-new`
|
||||
> command will also drop a `NuGet.config` file. This will be removed at RC2 release.
|
||||
|
||||
After this, the project is ready to be compiled and/or edited further.
|
||||
|
||||
# Options
|
||||
## Options
|
||||
|
||||
`-l`, `--lang [C#|F#]`
|
||||
Language of project. Defaults to `C#`. Also `csharp` ( `fsharp` ) or `cs` ( `fs` ) works.
|
||||
`-l`, `--lang [C##|F##]`
|
||||
|
||||
# EXAMPLES
|
||||
Language of project. Defaults to `C##`. Also `csharp` ( `fsharp` ) or `cs` ( `fs` ) works.
|
||||
|
||||
`-t`, `--type`
|
||||
|
||||
Type of the project. Valid values are "console" (default), "lib" and "xunittest"
|
||||
|
||||
## EXAMPLES
|
||||
|
||||
`dotnet new`
|
||||
|
||||
Drops a sample C# project in the current directory.
|
||||
Drops a sample C## project in the current directory.
|
||||
|
||||
`dotnet new --lang f#`
|
||||
`dotnet new --lang f##`
|
||||
|
||||
Drops a sample F# project in the current directory.
|
||||
Drops a sample F## project in the current directory.
|
||||
|
||||
`dotnet new --lang c#`
|
||||
`dotnet new --lang c##`
|
||||
|
||||
Drops a sample C# project in the current directory.
|
||||
Drops a sample C## project in the current directory.
|
||||
|
||||
# SEE ALSO
|
||||
dotnet-run(1)
|
||||
|
|
|
|||
83
src/dotnet/commands/dotnet-pack/README.md
Normal file
83
src/dotnet/commands/dotnet-pack/README.md
Normal file
|
|
@ -0,0 +1,83 @@
|
|||
% DOTNET-PACK(1)
|
||||
% Microsoft Corporation dotnetclifeedback@microsoft.com
|
||||
% April 2016
|
||||
|
||||
## NAME
|
||||
|
||||
dotnet-pack - packs the code into a NuGet package
|
||||
|
||||
## SYNOPSIS
|
||||
|
||||
dotnet-pack [--output]
|
||||
[--no-build] [--build-base-path]
|
||||
[--configuration] [--version-suffix]
|
||||
[< project >]
|
||||
|
||||
## DESCRIPTION
|
||||
|
||||
`dotnet-pack` will build the project and package it up as a NuGet file. The result of this operation are two packages
|
||||
with the extension of `nupkg`. One package contains the code and another contains the debug symbols.
|
||||
|
||||
NuGet dependencies of the project being packed are added to the nuspec file so they are able to be resolved when the
|
||||
package is installed. Project-to-project references are not packaged inside the project by default. If you wish to do
|
||||
this, you need to reference the required project in your dependencies node with a `type` set to "build":
|
||||
|
||||
```json
|
||||
{
|
||||
"version": "1.0.0-*",
|
||||
"dependencies": {
|
||||
"ProjectA": {
|
||||
"target": "project",
|
||||
"type": "build"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
`dotnet-pack` will by default build the project. If you wish to avoid this pass the `--no-build` option. This would be
|
||||
useful in CI build scenarios in which you know the code was just previously built.
|
||||
|
||||
## OPTIONS
|
||||
|
||||
`[project]`
|
||||
|
||||
The project to pack. It can be either a path to a `project.json` file or a path to a directory. If omitted, will
|
||||
default to the current directory.
|
||||
|
||||
`-o`, `--output` [DIR]
|
||||
|
||||
Place the built packages in the directory specified.
|
||||
|
||||
|
||||
`--no-build`
|
||||
|
||||
Skip the building phase of the packing process.
|
||||
|
||||
`--build-base-path`
|
||||
|
||||
Place the temporary build artifacts in the specified directory. By default, they go to obj directory in the current directory.
|
||||
|
||||
`-c`, `--configuration [Debug|Release]`
|
||||
|
||||
Configuration to use when building the project. If not specified, will default to "Debug".
|
||||
|
||||
## EXAMPLES
|
||||
|
||||
`dotnet-pack`
|
||||
|
||||
Pack the current project.
|
||||
|
||||
`dotnet-pack ~/projects/app1/project.json`
|
||||
|
||||
Pack the app1 project.
|
||||
|
||||
`dotnet-pack --output nupkgs`
|
||||
|
||||
Pack the current application and place the resulting packages into the specified folder.
|
||||
|
||||
`dotnet-pack --no-build --output nupkgs`
|
||||
|
||||
Pack the current project into the specified folder and skip the build step.
|
||||
|
||||
## SEE ALSO
|
||||
|
||||
|
|
@ -1,70 +1,86 @@
|
|||
% DOTNET-PUBLISH(1)
|
||||
% Zlatko Knezevic zlakne@microsoft.com
|
||||
% January 2016
|
||||
% Microsoft Corporation dotnetclifeedback@microsoft.com
|
||||
% April 2016
|
||||
|
||||
# NAME
|
||||
|
||||
## NAME
|
||||
|
||||
`dotnet-publish` - packs the application and all of its dependencies into a folder getting it ready for publishing
|
||||
|
||||
# SYNOPSIS
|
||||
## SYNOPSIS
|
||||
|
||||
dotnet-publish [--framework]
|
||||
[--runtime] [--output]
|
||||
[--configuration]
|
||||
[--runtime] [--build-base-path] [--output]
|
||||
[--version-suffix] [--configuration]
|
||||
[< project >]
|
||||
|
||||
# DESCRIPTION
|
||||
## DESCRIPTION
|
||||
|
||||
`dotnet-publish` will compile the application, read through its dependencies specified in `project.json` and publish the resulting set of files to a directory.
|
||||
This directory will contain the assemblies, the runtime as well as the executable version of the application. This directory can then be moved to a different machine and the application will be able to run regardless of existence of any other runtime.
|
||||
`dotnet-publish` compiles the application, reads through its dependencies specified in `project.json` and publishes the resulting set of files to a directory.
|
||||
|
||||
The native dependencies of the runtime are not packaged with the application. This means that the target machine needs to have the native dependencies installed in order for the application to run.
|
||||
Depending on the type of portable app, the directory contains the following:
|
||||
|
||||
# OPTIONS
|
||||
1. **Portable application** - application's intermediate language (IL) code and all of application's managed dependencies.
|
||||
* **Portable application with native dependencies** - as above with a sub-directory for each native dependencies'
|
||||
supported platform.
|
||||
2. **Self-contained application** - as above as well as the entire runtime for the targeted platform.
|
||||
|
||||
The above types are covered in more details in the [types of portable applications](app-types.md) document.
|
||||
|
||||
## OPTIONS
|
||||
|
||||
`[project]`
|
||||
|
||||
`dotnet-publish` needs access to `project.json` to work. If it is not specified on invocation via [project], `project.json` in the current directory will be the default. If no `project.json` can be found, `dotnet-publish` will error out. `dotnet-publish` command also requires certain dependencies in the `project.json` to work. Namely the `Microsoft.NETCore.Runtime` package must be referenced as a dependency in order for the command to copy the runtime files as well as the application's files to the published location.
|
||||
`dotnet-publish` needs access to `project.json` to work. If it is not specified on invocation via [project],
|
||||
`project.json` in the current directory will be the default.
|
||||
If no `project.json` can be found, `dotnet-publish` will error out.
|
||||
|
||||
`-f`, `--framework` [FID]
|
||||
|
||||
Publish the application for a given framework identifier (FID). If not specified, FID is read from `project.json`. In case of no valid framework found, the command will error out. In case of multiple valid frameworks found, the command will publish for all valid frameworks.
|
||||
Publish the application for a given framework identifier (FID). If not specified, FID is read from `project.json`. In case of no valid framework found, the command will error out. In case of multiple valid frameworks found, the command will publish for all valid frameworks.
|
||||
|
||||
|
||||
`-r`, `--runtime` [RID]
|
||||
|
||||
Publish the application for a given runtime. If the option is not specified, the command will default to the runtime for the current operationg system. Supported values for the option at this time are:
|
||||
Publish the application for a given runtime.
|
||||
|
||||
* ubuntu.14.04-x64
|
||||
* win7-x64
|
||||
* osx.10.10-x64
|
||||
`-b`, `--build-base-path` [DIR]
|
||||
|
||||
Directory in which to place temporary outputs
|
||||
|
||||
`-o`, `--output`
|
||||
|
||||
Specify the path where to place the directory. If not specified, will default to _./bin/[configuration]/[framework]/[runtime]/_
|
||||
Specify the path where to place the directory. If not specified, will default to _./bin/[configuration]/[framework]/_
|
||||
for portable applications. For self-contained applications, will default to _./bin/[configuration]/[framework]/[runtime]_
|
||||
|
||||
--version-suffix [VERSION_SUFFIX]
|
||||
|
||||
Defines what `*` should be replaced with in the version field in project.json.
|
||||
|
||||
`-c`, `--configuration [Debug|Release]`
|
||||
|
||||
Configuration to use when publishing. If not specified, will default to "Debug".
|
||||
Configuration to use when publishing. If not specified, will default to "Debug".
|
||||
|
||||
# EXAMPLES
|
||||
## EXAMPLES
|
||||
|
||||
`dotnet-publish`
|
||||
`dotnet publish`
|
||||
|
||||
Publish the current application using the `project.json` framework and runtime for the current operating system.
|
||||
Publish an application using the framework found in `project.json`. If `project.json` contains `runtimes` node, publish
|
||||
for the RID of the current platform.
|
||||
|
||||
`dotnet-publish ~/projects/app1/project.json`
|
||||
`dotnet publish ~/projects/app1/project.json`
|
||||
|
||||
Publish the application using the specified `project.json`; also use framework specified withing and runtime for the current operating system.
|
||||
Publish the application using the specified `project.json`.
|
||||
|
||||
`dotnet-publish --framework dnxcore50`
|
||||
`dotnet publish --framework netcoreapp1.0`
|
||||
|
||||
Publish the current application using the `dnxcore50` framework and runtime for the current operating system.
|
||||
Publish the current application using the `netcoreapp1.0` framework.
|
||||
|
||||
`dotnet-publish --framework dnxcore50 --runtime osx.10.10-x64`
|
||||
`dotnet publish --framework netcoreapp1.0 --runtime osx.10.11-x64`
|
||||
|
||||
Publish the current application using the `dnxcore50` framework and runtime for `OS X 10.10`
|
||||
Publish the current application using the `netcoreapp1.0` framework and runtime for `OS X 10.10`. This RID has to
|
||||
exist in the `project.json` `runtimes` node.
|
||||
|
||||
# SEE ALSO
|
||||
## SEE ALSO
|
||||
|
||||
dotnet-restore(1), dotnet-compile(1)
|
||||
|
|
|
|||
83
src/dotnet/commands/dotnet-restore/README.md
Normal file
83
src/dotnet/commands/dotnet-restore/README.md
Normal file
|
|
@ -0,0 +1,83 @@
|
|||
% DOTNET-RESTORE(1)
|
||||
% Microsoft Corporation dotnetclifeedback@microsoft.com
|
||||
% April 2016
|
||||
|
||||
## NAME
|
||||
|
||||
dotnet-restore - restores the dependencies and tools of a project
|
||||
|
||||
## SYNOPSIS
|
||||
|
||||
dotnet-restore [--source]
|
||||
[--packages] [--disable-parallel]
|
||||
[--fallbacksource] [--configfile] [--verbosity]
|
||||
[< root >]
|
||||
|
||||
## DESCRIPTION
|
||||
|
||||
`dotnet-restore` will use NuGet to restore dependencies as well as project-specific tools that are specified in the
|
||||
project.json file. By default, the restoration of dependencies and tools will be done in parallel.
|
||||
|
||||
In order to restore the dependencies, NuGet needs feeds where the packages are located. Feeds are usually provided via the
|
||||
NuGet.config configuration file; a default one is present when CLI tools are installed. You can specify more feeds by
|
||||
creating your own NuGet.config file in the project directory. Feeds can also be specified per invocation on the command line.
|
||||
|
||||
For dependencies, you can specify where the restored packages will be placed during the restore operation using the
|
||||
`--packages` argument. If not specified, the default NuGet package cache will be used. It is found in the `.nuget/packages`
|
||||
directory in the user's home directory on all operating systems (for example `/home/user1` on Linux or `C:\Users\user1`
|
||||
on Windows).
|
||||
|
||||
For project-specific tooling, `dotnet-restore` will first restore the package in which the tool is packed, and will then
|
||||
proceed to restore the tool's dependencies as specified in its project.json.
|
||||
|
||||
## OPTIONS
|
||||
|
||||
`[root]`
|
||||
|
||||
A list of projects or project folders to restore. The list can contain either a path to a `project.json` file, path to `global.json` file or folder. The restore operation will run recursivelly for all subdirectories and restore for each given project.json file it finds.
|
||||
|
||||
`-s`, `--source` [SOURCE]
|
||||
|
||||
Specify a source to use during the restore operation. This will override all of the sources specified in the NuGet.config file(s).
|
||||
|
||||
`--packages` [DIR]
|
||||
|
||||
Specifies the directory to place the restored packages in.
|
||||
|
||||
`--disable-parallel`
|
||||
|
||||
Disable restoring multiple projects in parallel.
|
||||
|
||||
`-f`, `--fallbacksource` [FEED]
|
||||
|
||||
Specify a fallback source that will be used in the restore operation if all other sources fail. All valid feed formats are allowed.
|
||||
|
||||
`--configfile` [FILE]
|
||||
|
||||
Configuration file (NuGet.config) to use for this restore operation.
|
||||
|
||||
`--verbosity` [LEVEL]
|
||||
|
||||
The verbosity of logging to use. Allowed values: Debug, Verbose, Information, Minimal, Warning, Error.
|
||||
|
||||
## EXAMPLES
|
||||
|
||||
`dotnet-restore`
|
||||
|
||||
Restore dependencies and tools for the project in the current directory.
|
||||
|
||||
`dotnet-restore ~/projects/app1/project.json`
|
||||
|
||||
Restore dependencies and tools for the app1 project found in the given path.
|
||||
|
||||
`dotnet-restore --f c:\packages\mypackages`
|
||||
|
||||
Restore the dependencies and tools for the project in the current directory using the file path provided as the fallback source.
|
||||
|
||||
`dotnet-restore --verbosity Error`
|
||||
|
||||
Show only errors in the output.
|
||||
|
||||
## SEE ALSO
|
||||
|
||||
dotnet
|
||||
|
|
@ -1,26 +1,52 @@
|
|||
% DOTNET-RUN(1)
|
||||
% Zlatko Knezevic zlakne@microsoft.com
|
||||
% January 2016
|
||||
% Microsoft Corporation dotnetclifeedback@microsoft.com
|
||||
% April 2016
|
||||
|
||||
## NAME
|
||||
|
||||
# NAME
|
||||
dotnet-run -- Runs source code 'in-place' without any explicit compile or launch commands.
|
||||
|
||||
# SYNOPSIS
|
||||
`dotnet run [--verbose]`
|
||||
## SYNOPSIS
|
||||
|
||||
# DESCRIPTION
|
||||
The run command provides a convenient option to run source code with one command. It compiles source code, generates an output program and then runs that program. This command is useful for fast iterative development and can also be used to run a source-distributed program (e.g. website).
|
||||
dotnet-run [--framework] [--configuration]
|
||||
[--project] [--] [--help]
|
||||
|
||||
This command relies on `dotnet-compile(1)` to compile source inputs to a .NET assembly, before launching the program. The requirements for and handling of source inputs for this command are all inherited from the compile command. The documentation for the compile command provides more information on those requirements.
|
||||
## DESCRIPTION
|
||||
The run command provides a convenient option to run source code with one command. It compiles source code, generates an
|
||||
output program and then runs that program. This command is useful for fast iterative development and can also be used
|
||||
to run a source-distributed program (e.g. website).
|
||||
|
||||
Output files, are written to the child `bin` folder, which will be created if it doesn't exist. Files will be overwritten as needed. Temporary files are written to the child `obj` folder.
|
||||
This command relies on `dotnet-build(1)` to build source inputs to a .NET assembly, before launching the program.
|
||||
The requirements for and handling of source inputs for this command are all inherited from the build command.
|
||||
The documentation for the build command provides more information on those requirements.
|
||||
|
||||
# OPTIONS
|
||||
Output files are written to the child `bin` folder, which will be created if it doesn't exist.
|
||||
Files will be overwritten as needed. Temporary files are written to the child `obj` folder.
|
||||
|
||||
-v, --verbose
|
||||
In case of a project with multiple specified frameworks, `dotnet run` will first select the .NET Core frameworks. If
|
||||
those do not exist, it will error out. To specify other frameworks, use the `--framework` argument.
|
||||
|
||||
## OPTIONS
|
||||
|
||||
`--`
|
||||
|
||||
Delimit arguments to `dotnet run` from arguments for the application being run. All arguments after this one will be passed to
|
||||
the application being run.
|
||||
|
||||
`-f`, `--framework` [FID]
|
||||
|
||||
Run the application for a given framework identifier (FID).
|
||||
|
||||
`-c`, `--configuration [Debug|Release]`
|
||||
|
||||
Configuration to use when publishing. If not specified, will default to "Debug".
|
||||
|
||||
`-p`, `--project [PATH]`
|
||||
|
||||
Specifies which project to run. Can be a path to project.json or to a directory containing a project.json. Defaults to
|
||||
current directory if not specified.
|
||||
|
||||
Prints verbose logging information, to follow the flow of execution of the command.
|
||||
|
||||
# SEE ALSO
|
||||
|
||||
dotnet-compile(1), dotnet-publish(1)
|
||||
dotnet-build(1), dotnet-publish(1)
|
||||
|
|
|
|||
|
|
@ -1,5 +1,9 @@
|
|||
% DOTNET-TEST(1)
|
||||
% Microsoft Corporation dotnetclifeedback@microsoft.com
|
||||
% April 2016
|
||||
|
||||
Dotnet Test, Adapters and Test Runners
|
||||
===============
|
||||
======================================
|
||||
|
||||
This document covers the interactions between dotnet test, a potential adapter (like VS) and
|
||||
test runners (like [xunit](https://github.com/dotnet/coreclr.xunit)).
|
||||
|
|
|
|||
Loading…
Add table
Reference in a new issue