mirrors/dotnet-installer
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

Making this repo consume the dotnet-sdk-internal zip and produce a full core-sdk by using sdk-internal, runtime, lzma, templates and store. Also deleted a bunch of now, unecessary code. I am sure there is more to be deleted though.

Browse source
This commit is contained in:
Livar Cunha 2017-10-11 17:17:28 -07:00
parent 94eeedfc4c
commit 62ae014c37
1342 changed files with 229 additions and 99652 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
CONTRIBUTING.md
View file

@ -6,4 +6,4 @@ See [Contributing](https://github.com/dotnet/corefx/blob/master/Documentation/pr
Developers
==========
See the [Developer Guide](Documentation/project-docs/developer-guide.md) for details about developing in this repo.
If you are looking to contribute to the verbs that ship with the SDK, please go to the [CLI Repo](https://github.com/dotnet/cli).

7
Directory.Build.props
View file

@ -43,24 +43,23 @@ tools\TestAssetsDependencies\TestAssetsDependencies.csproj
<Import Project="build/DerivedHostMachineInfo.props" />
<Import Project="build/FileExtensions.props" />
<Import Project="build/InputDirectories.props" />
<Import Project="build/MSBuildExtensions.props" />
<Import Project="build/SetupPreviousStage.props" />
<Import Project="build/OutputDirectories.props" />
<ImportGroup Condition=" '$(BuildingSigningProject)' != 'true' ">
<!-- These imports aren't required for signing, and some of them have syntax which isn't supported in MSBuild 14,
which is what the signing build uses -->
<Import Project="build/BundledTools.props" />
<Import Project="build/BundledSdks.props" />
<Import Project="build/BundledTemplates.props" />
<Import Project="build/AzureInfo.props" />
<Import Project="build/BuildDefaults.props" />
<Import Project="build/VersionBadge.props" />
<Import Project="build/BundledRuntimes.props" />
<Import Project="build/BundledToolset.props" />
<Import Project="build/CrossGen.props" />
<Import Project="build/BackwardsCompatibilityRuntimes.props" />
<Import Project="build/AzureInfo.props" />
<Import Project="build/InstallerInfo.props" />
<Import Project="build/GenerateResxSource.targets" />
</ImportGroup>

63
Documentation/ProjectJsonToCSProj.md
View file

@ -1,63 +0,0 @@
.NET CLI preview 3 is here, and with it comes the .csproj project file format and msbuild engine. The team has put a lot of focus on making the transition as seamless as possible, but as with any change of this magnitude there are some gotcha's to keep in mind. This issue explains how to use the .NET CLI during this transitional period.
# Overview
Starting with @coolcsh's great post [Changes to Project.json](https://blogs.msdn.microsoft.com/dotnet/2016/05/23/changes-to-project-json/) the team has been hard at work moving the .NET command line story from project.json to msbuild. Our plan was fairly straightforward:
- Create a preview3 fork of the CLI
- Temporarily support both project.json and msbuild in the preview3 fork
- This allowed the team to use the CLI to build the new CLI
- msbuild support lit up through `3` verbs such as `build3`, `publish3`, `restore3`
- Once the msbuild support matures enough to build working applications, remove project.json support
In addition to lighting up the msbuild scenario, the team also provided a migration tool called `dotnet migrate` that converts project.json files to csproj files.
# Where are we now?
The team is feature complete to the plan above. The transition to msbuild is done and the migration tool is already part of the preview3 CLI. Of course there are still many issues to address before we can claim that we're ready to drop the `preview` suffix, but the core functionality is in place.
# How do I...
Until we are ready to call the `preview3+` CLI ready for prime-time we find ourselves in a world where it is interesting to work on csproj, project.json, or both. How can we make that work?
## How do I keep working with project.json?
Developers who are waiting for the new CLI to ship will continue using the `preview2` CLI. As long as they don't install any `preview3` or later bits on their machine they will be able to continue using Visual Studio 2015 preview tooling and maintain their existing developer experience.
The `preview3` CLI does not offer any benefits for developers that want to keep using `project.json` for the time being.
## How do I work with csproj only?
Developers who want to try out the new csproj / msbuild CLI and don't have project.json-based code to worry about can just install the `preview3` tooling. Any build starting at `1.0.0-preview3-004056` is sufficient to get started. Once installed, you can open a command prompt and:
- `dotnet new` to get a new csproj console application
- `dotnet restore` to get required nuget packages
- `dotnet build` to build the project
- `dotnet run` to run the project
## How do I work with project.json while trying out csproj?
This scenario presents a few options. First, you can use the `dotnet migrate` tool to migrate your existing `project.json` assets to csproj. Alternatively, you can maintain both workflows side-by-side with some care, described below.
### How do I migrate project.json to csproj?
I'll start with a warning. Migration is fairly complex and `preview3` is the first preview of this capability. The tool will be better in future releases, and it will need your project.json files in order to redo the migration in the future. `dotnet migrate` moves your `project.json` assets into a `backup` folder whose structure matches the layout of your solution. If you intend to migrate with newer tooling in the future then keep this folder in source control so you can put the files back when needed.
To migrate a project open a command prompt and go to the project's root directory. From here, type `dotnet migrate` and let the tool do its work. For most projects, that's it! There are some special cases where the tool will complain and ask for some help, however:
- Projects are expected to have been updated to the `preview2` format for `project.json`. If you had noticed the previous CLI complaining about `deprecated` properties, these warnings will need to be cleaned up prior to migration.
- Some advanced capabilities, particularly some script variables, do not have an equivalent in the csproj world. The migration tool will ask you to remove these before migration can complete.
Once migration is done you can use the same verbs as before to build, run, publish, etc. your project.
### How do I work with project.json and csproj on the same machine?
This is an important scenario, as many folks will keep working with the existing tooling while experimenting with the preview3 implementations.
To work with both project.json and csproj a developer will install two CLIs: one `preview2` for project.json and one `preview3` for csproj. There will only be one `dotnet` on the PATH, of course, so the CLI will need some help knowing which version to choose. This is accomplished with the help of the `global.json` file.
When `preview2` shipped the Visual Studio new project templates included both a `project.json` file and a `global.json` file. The latter was fairly empty, including project locations and a `version` property. That `version` specified the `preview2` CLI that shipped with the tools.
```
{
"projects": [ "src", "test" ],
"sdk": {
"version": "1.0.0-preview2-003121"
}
}
```
We included this file by default as a future-proofing tactic. When the CLI launches it looks for this file in the current directory, or the nearest parent directory, and tries to find a matching version of itself. If an exact match is found then it is used. Otherwise, `dotnet.exe` picks the latest installed CLI. When there is no exact match AND preview3 is installed then we get into trouble because preview3 cannot reason about project.json files.
When working with `preview2` and `preview3` on the same machine we need to be sure that `preview2` projects have a global.json present and that the `version` property is set to an installed preview2 version. This will typically be `1.0.0-preview2-003121` or `1.0.0-preview2-003131`. You can check what is installed by looking in `%PROGRAM FILES%\dotnet\sdk` and checking the folder names.

27
Documentation/README.md
View file

@ -1,27 +0,0 @@
Documents Index
===============
## Overview and general information
- [Intro to .NET Core CLI](general/intro-to-cli.md)
- [CLI UX Guidelines](general/cli-ux-guidelines.md)
- [.NET Core native pre-requisities document](https://github.com/dotnet/core/blob/master/Documentation/prereqs.md)
- [Roadmap and OS support](https://github.com/dotnet/core/blob/master/roadmap.md)
- [Comprehensive CLI documentation](https://docs.microsoft.com/en-us/dotnet/articles/core/preview3/tools/)
## Working with the CLI repo
- [Developer Guide](project-docs/developer-guide.md)
- [How to file issues](project-docs/issue-filing-guide.md)
## Troubleshooting and issues reporting
- [CLI Known Issues](https://github.com/dotnet/core/blob/master/cli/known-issues.md)
- [Filing migration issues](migration-issues.md)
## Specifications
- [CLI installation scenarios](specs/cli-installation-scenarios.md)
- [Corehost specification](specs/corehost.md)
- [Runtime configuration file specification](specs/runtime-configuration-file.md)

157
Documentation/general/cli-ux-guidelines.md
View file

@ -1,157 +0,0 @@
.NET Core Command-Line Tools UX Guidelines
-------------------------------------------
This document outlines the User Experience (UX) of the .NET Core command lline tools (CLI).These guideliens are intended for anyone that wants to add a new command to the CLI.
The guidelines presented in this document have been adopted to provide a clear and concise
command line syntax that is easy to learn, remember and work with, and that has an added benefit
of being familiar to people who have used other command-line interfaces as well as existing
Visual Studio users.
## Naming the commands
In the .NET Core CLI, commands should be **verbs**. This rule was adopted
because most of the commands do *something*.
Sub-commands are supported in the CLI, and they are usually nouns. A good
example of this is the “dotnet add reference” command. If there is a need to add
a subcommand, that subcommand should usually specialize what the parent command
does.
## Create/Read/Update/Delete (CRUD) commands
New CRUD commands should be named according to the following logic:
- Does the command work on data in the project (either properties or
items)? If yes, then it should be added as a noun to the “dotnet
add/list/remove/update”, e.g. “dotnet add foo”.
- Does the command work on the solution (SLN) file? If yes, then it should be
added as a verb to the “dotnet sln” command.
- Does the command work on a completely new artifact (e.g. a new metadata file
that is added in the future)? If yes, it should be created as a top level
noun with all of the underlying operations defined as sub-commands.
- If the command adds a new artifact to the project, it should become an item
template that is dropped with “dotnet new” command.
If none of the above applies, the proposal should clearly outline why none of
the above applies and suggest an alternative naming that will be decided on
during the process described above.
If the command works on the project or solution, it must also accept an optional
argument that specifies which project or solution to work on. The current
convention is for that argument to follow the verb in the CRUD command. For
example:
> dotnet add \<PROJECT\> reference \<REFERENCE\>
All the existing CRUD commands have this argument defined and it will be passed
to the sub-command as part of the overall options. The sub-command is expected
to consider this optional argument.
## Options
CLI follows the [GNU convention](https://www.gnu.org/prep/standards/html_node/Command_002dLine-Interfaces.html) for options’ format, which is based on the POSIX
standard. The summary is:
- Command can have both short and long options.
- The short format starts with a single dash (“-“), and has **exactly** one
letter. The letter is usually the start letter of the longer form of the
option, e.g. “-o” for “--output” or any of its words. This provides a good
mnemonic.
- **Example:** “dotnet build -o path/to/where/to/put/output”
- The long format starts with double dashes (“--“) and can have one or more
words. Multiple words are separated by a single dash (“-“).
- **Example:** “dotnet test --test-case-filter”
- The double dashes (“--“) on their own mark the **argument separator**.
Anything after this option is passed verbatim to whatever the command starts
as a sub-process.
- **Example:** “dotnet run -- --app-arg-1”
- Windows-style forward slash options (e.g. “/p”) are supported **only for
MSBuild parameters.**
- PowerShell-style single dashes with a word (e.g. “-Filter”) are **not
supported**.
- Help options are predefined as “-h \| --help” and those should be used.
There are common options in the CLI that are reserved for certain concepts. The
table below outlines those common options. If a command needs to accept the same
options, it should use these and it must not replace their semantics (e.g. use
“--output” to mean something different or redefine what “-f” means for just that
command).
| Long option | Short option | Description |
|------------------|--------------|--------------------------------------------------------------|
| \--framework | \-f | Specifies which framework (target) to use in the invocation. |
| \--output | \-o | Specifies where the output of the command should be placed. |
| \--runtime | \-r | Specifies the runtime ID (RID) to use in the invocation. |
| \--configuration | \-c | Specifies the configuration to use in the invocation. |
| \--verbosity | \-v | Specifies the verbosity level of the command. |
| \--help | \-h | Shows the help for the command. |
One special area is interacting with MSBuild. If a command has the need to do
that, there are two additional requirements with regards to options:
1. The commands need to be able to take “/p” parameters in addition to whatever
other properties they require.
2. If the command invokes a predefined MSBuild target, it needs to block
“/t:\<target\>” and “/target:\<target\>” options and throw an error that is
pre-defined in the CLI.
It is important to note that commands that invoke user-specified targets
should not be submitted to the CLI, since the CLI comes with “dotnet msbuild”
command that does precisely that.
## Arguments
Arguments can have any name that authors of the commands being added need. We do have predefined
argument names for the SLN file and project file. They are defined in the CLI
source code and should be used if the command has the need to use those two
arguments.
## Help messages
Help messages are automatically generated based on the arguments, options and
command name. No other work should be required here apart from setting up the
above mentioned and their descriptions.
## Output
For commands that are invoking MSBuild, the output will be controlled by MSBuild
itself.
In case of a long running operation, the command needs to provide a feedback
mechanism to the user to help the user reason about whether the command has
crashed or is just waiting for I/O. The feedback mechanism guidelines are below:
1. Feedback should not require fonts with special glyphs for display.
2. Pure text is acceptable (e.g. `Running background process...`) as a feedback mechanism.
3. Spinners that conform to rule \#1 above are also acceptable.
### Verbosity
If the command interacts with MSBuild, it is required that it can accept a
“--verbosity \| -v” argument and pass it to MSBuild verbatim.
If the command’s verbosity levels cannot fit naturally in [MSBuild’s verbosity levels](https://docs.microsoft.com/en-us/visualstudio/msbuild/msbuild-command-line-reference) or the command does not interact with MSBuild but still has an option to set the verbosity, it
is the job of the command to map them in the most appropriate way. This way, the
verbosity levels will be uniform across all commands which brings consistency to
the toolset.
#### Example
As an example, let us consider a “dotnet configure” command. It doesn’t interact
with MSBuild. I wish to have verbosity on it, but it really has only two levels:
quiet (just successes or errors) and verbose (every operation) that I've defined for the command. To satisfy the
above-mentioned requirement, in my command I would define the “--verbosity \|
-v” option and would map the arguments in the following way:
- “Quiet” gets mapped naturally to “quiet”
- “Minimal”, “Normal” and “Diagnostic” get mapped into “verbose”

62
Documentation/general/intro-to-cli.md
View file

@ -1,62 +0,0 @@
Introduction to .NET Core CLI
=============================
The .NET Core CLI is a simple, extensible and standalone set of tools for building, managing and otherwise operating on .NET projects. It will or already includes commands such as compilation, NuGet package management and launching a debugger session. It is intended to be fully featured, enabling extensive library and app development functionality appropriate at the command-line. It should provide everything you'd need to develop an app in an SSH session! It is also intended to be a fundamental building block for building finished experiences in tools such as Visual Studio.
Goals:
- Language agnostic - embrace "common language runtime".
- Target agnostic - multi-targets.
- Simple extensibility and layering - "you had one job!"
- Cross-platform - support and personality.
- Semantic user interface over [MSBuild](https://github.com/Microsoft/msbuild).
Experience
==========
The [.NET Core command-line tools](https://github.com/dotnet/cli) present the "dotnet" tool as the entry-point tool. It provides higher-level commands, often using multiple tools together to complete a task. It's a convenience wrapper over the other tools, which can also be used directly. "dotnet" isn't magical at all, but a very simple aggregator of other tools.
You can get a sense of using the tools from the examples below.
**dotnet restore**
`dotnet restore` restores dependent package from a given NuGet feed (e.g. NuGet.org) for the project in scope.
**dotnet run**
`dotnet run` compiles and runs your app with one step.
**dotnet build**
`dotnet build` compiles your app or library as an IL binary.
Design
======
There are a couple of moving pieces that you make up the general design of the .NET Core CLI:
* The `dotnet` driver
* Specific commands that are part of the package
The `dotnet` driver is very simple and its primary role is to run commands and give users basic information about usage.
The way the `dotnet` driver finds the command it is instructed to run using `dotnet {command}` is via a convention; any executable that is placed in the PATH and is named `dotnet-{command}` will be available to the driver. For example, when you install the CLI toolchain there will be an executable called `dotnet-build` in your PATH; when you run `dotnet build`, the driver will run the `dotnet-build` executable. All of the arguments following the command are passed to the command being invoked. So, in the invocation of `dotnet build --native`, the `--native` switch will be passed to `dotnet-build` executable that will do some action based on it (in this case, produce a single native binary).
Adding a new command to the .NET Core CLI
=========================================
If you want to contribute to the actual .NET Core CLI by adding a new command that you think would be useful, please refer to the [developer guide](developer-guide.md) in this directory. It contains all of the guidance on both the process as well as the infrastructure that you need to adhere to when adding a new command to the CLI toolchain.
After you familiarize yourself with the process of working with the source code in the repo, please consult the [CLI UX guidelines](cli-ux-guidelines.md) to get to know the user experience tenants the CLI has.
Adding a new command locally
============================
If you wish to extend the CLI, you can read more about supported extensibility models in the [official extensibility document](https://docs.microsoft.com/en-us/dotnet/articles/core/tools/extensibility)/.
Guidance on how to write a command
==================================
How you write a given command depends largely on whether you are trying to add it to the CLI project or want to add the command locally, that is on your machine or server.
For the former case, the [developer guide](developer-guide.md) has all of the details that you will need to get going.
If you are adding a command on your own machine(s), then there is really no special model to keep in mind. However, since your users will be using the local commands through the `dotnet` driver, we strongly suggest to keep to the principles outlined in the [CLI UX guidelines](cli-ux-guidelines.md) to have an unified user experience for your users.

71
Documentation/general/tab-completion.md
View file

@ -1,71 +0,0 @@
# .NET CLI Tab Completion
In version 2.0 of the .NET Core CLI, we have added support for providing suggestions when you press `tab`. While it's not yet enabled by default, you can try it out today by installing a [preview build](https://github.com/dotnet/cli#installers-and-binaries) from the master branch or by building from source.
Here are some examples of what it provides:
Input | becomes | because
:------------------------------------|:----------------------------------------------------------------------------|:--------------------------------
`dotnet a⇥` | `dotnet add` | `add` is the first subcommand, alphabetically.
`dotnet add p⇥` | `dotnet add --help` | it matches substrings and `--help` comes first alphabetically.
`dotnet add p⇥⇥` | `dotnet add package` | pressing tab a second time brings up the next suggestion.
`dotnet add package Microsoft⇥` | `dotnet add package Microsoft.ApplicationInsights.Web` | results are returned alphabetically.
`dotnet remove reference ⇥` | `dotnet remove reference ..\..\src\OmniSharp.DotNet\OmniSharp.DotNet.csproj` | it is project file aware.
## How to enable it
Tab completion is currently supported in three shells: PowerShell, bash, and zsh. These scripts assume that `dotnet` v2.0 is on your path. You can verify that you have the correct version of `dotnet` on your path by trying out the new `complete` command directly:
```
[04/26/2017 11:38:20] C:\
> dotnet complete "dotnet add p"
```
If you just installed `dotnet` you may see the first-run output:
```
Welcome to .NET Core!
---------------------
Learn more about .NET Core @ https://aka.ms/dotnet-docs. Use dotnet --help to see available commands or go to https://aka.ms/dotnet-cli-docs.
Telemetry
--------------
The .NET Core tools collect usage data in order to improve your experience. The data is anonymous and does not include command-line arguments. The data is collected by Microsoft and shared with the community.
You can opt out of telemetry by setting a DOTNET_CLI_TELEMETRY_OPTOUT environment variable to 1 using your favorite shell.
You can read more about .NET Core tools telemetry @ https://aka.ms/dotnet-cli-telemetry.
Configuring...
-------------------
A command is running to initially populate your local package cache, to improve restore speed and enable offline access. This command will take up to a minute to complete and will only happen once.
Decompressing 100% 4936 ms
Expanding 100% 17195 ms
```
You should see the following ouput (perhaps coming at the end of the first-run output). This indicates that `dotnet` is resolving to a v2.0 installation that supports completion.
```
--help
package
```
### PowerShell
To enable tab completion in PowerShell, edit your PowerShell profile:
```
notepad $PROFILE
```
Add the contents of [register-completions.ps1](https://github.com/dotnet/cli/blob/master/scripts/register-completions.ps1) to this file and save.
### bash
To enable tab completion in bash, edit your `.bashrc` file to add the contents of [register-completions.bash](https://github.com/dotnet/cli/blob/master/scripts/register-completions.bash).
### zsh
To enable tab completion in zsh, edit your `.zshrc` file to add the contents of [register-completions.zsh](https://github.com/dotnet/cli/blob/master/scripts/register-completions.zsh).
## How it works
Each of these scripts provides a hook for completions for its respective shell. The logic that determines which suggestions to provide is in the CLI itself, configured using [our new parser](https://github.com/dotnet/CliCommandLineParser). You can see a code example [here](https://github.com/dotnet/cli/blob/master/src/dotnet/commands/dotnet-add/dotnet-add-package/AddPackageParser.cs#L23).

96
Documentation/manpages/sdk/dotnet-build.1
View file

@ -1,96 +0,0 @@
.\" Automatically generated by Pandoc 1.15.1
.\"
.hy
.TH "DOTNET\-BUILD" "1" "April 2016" "" ""
.SS NAME
.PP
dotnet\-build \-\- Builds a project and all of its dependencies
.SS SYNOPSIS
.PP
\f[C]dotnet\ build\ [\-\-output]\ \ \ \ \ \ \ [\-\-build\-base\-path]\ [\-\-framework]\ \ \ \ \ \ \ [\-\-configuration]\ \ [\-\-runtime]\ [\-\-version\-suffix]\ \ \ \ \ [\-\-build\-profile]\ \ [\-\-no\-incremental]\ [\-\-no\-dependencies]\ \ \ \ \ [<project>]\f[]
.SS DESCRIPTION
.PP
The \f[C]dotnet\ build\f[] command builds multiple source file from a
source project and its dependencies into a binary.
The binary will be in Intermediate Language (IL) by default and will
have a DLL extension.
\f[C]dotnet\ build\f[] will also drop a \f[C]\\*.deps\f[] file which
outlines what the host needs to run the application.
.PP
Building requires the existence of a lock file, which means that you
have to run \f[C]dotnet\ restore\f[] (dotnet-restore.md) prior to
building your code.
.PP
Before any compilation begins, the build verb analyzes the project and
its dependencies for incremental safety checks.
If all checks pass, 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.
.PP
All 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 (for example, resgen, compilers) \- use only known
compilers (csc, vbc, fsc)
.PP
In order to build an executable application, you need a special
configuration section in your project.json file:
.IP
.nf
\f[C]
{\
\ \ \ \ "compilerOptions":\ {
\ \ \ \ \ \ "emitEntryPoint":\ true
\ \ \ \ }
}
\f[]
.fi
.SS OPTIONS
.PP
\f[C]\-o\f[], \f[C]\-\-output\f[] [DIR]
.PP
Directory in which to place the built binaries.
.PP
\f[C]\-b\f[], \f[C]\-\-build\-base\-path\f[] [DIR]
.PP
Directory in which to place temporary outputs.
.PP
\f[C]\-f\f[], \f[C]\-\-framework\f[] [FRAMEWORK]
.PP
Compiles for a specific framework.
The framework needs to be defined in the project.json file.
.PP
\f[C]\-c\f[], \f[C]\-\-configuration\f[] [Debug|Release]
.PP
Defines a configuration under which to build.
If omitted, it defaults to Debug.
.PP
\f[C]\-r\f[], \f[C]\-\-runtime\f[] [RUNTIME_IDENTIFIER]
.PP
Target runtime to build for.
.PP
\-\-version\-suffix [VERSION_SUFFIX]
.PP
Defines what \f[C]*\f[] should be replaced with in the version field in
the project.json file.
The format follows NuGet\[aq]s version guidelines.
.PP
\f[C]\-\-build\-profile\f[]
.PP
Prints out the incremental safety checks that users need to address in
order for incremental compilation to be automatically turned on.
.PP
\f[C]\-\-no\-incremental\f[]
.PP
Marks the build as unsafe for incremental build.
This turns off incremental compilation and forces a clean rebuild of the
project dependency graph.
.PP
\f[C]\-\-no\-dependencies\f[]
.PP
Ignores project\-to\-project references and only builds the root project
specified to build.
.SH AUTHORS
Microsoft Corporation dotnetclifeedback\@microsoft.com.

125
Documentation/manpages/sdk/dotnet-compile-native.1
View file

@ -1,125 +0,0 @@
.\" Automatically generated by Pandoc 1.15.1
.\"
.hy
.TH "dotnet-native" "1" "January 2016" "" ""
.SH NAME
.PP
dotnet\-compile\-native \-\- Compiles IL binaries to native binaries.
.SH SYNOPSIS
.PP
dotnet compile [\-\-appdepsdk] [\-\-configuration] [\-\-ilcargs]
[\-\-linklib] [\-\-logpath] [\-\-mode] [\-\-out] [\-\-reference]
[\-\-temp\-out] [\-\-verbose]
.SH DESCRIPTION
.PP
The \f[C]compile\-native\f[] command compiles IL assemblies to native
machine code.
It is used by \f[C]dotnet\-compile\ \-\-native\f[].
.PP
The output is a native exe that conforms to the architecture of the
underlying operating system (i.e.
running on 64\-bit OS will produce a native 64\-bit exe).
This can be overriden via the \-\-arch switch and specifying the wanted
architecture.
The executable has a default extension of "" on Linux and OS X and
".exe" on Windows.
The source must include a `static void Main(string[] args) entry point
and specify compilationOptions.emitEntryPoint in the project.json.
.PP
Output files are written to the child \f[C]bin\f[] folder, which will be
created if it doesn\[aq]t exist.
Files will be overwritten as needed.
.SH OPTIONS
.PP
\f[C]\-\-appdepsdk\ <SDK_PATH>\f[]
.IP
.nf
\f[C]
Path\ to\ custom\ AppDepSDK
\f[]
.fi
.PP
\f[C]\-c,\ \-\-configuration\ [debug|release]\f[]
.IP
.nf
\f[C]
Build\ configuration.\ Defaults\ to\ `debug`.
\f[]
.fi
.PP
\f[C]\-\-ilcargs\ <args>\f[]
.IP
.nf
\f[C]
Custom\ arguments\ for\ the\ IL\ Compiler.
\f[]
.fi
.PP
\f[C]\-\-ilcpath\ <ILC_PATH>\f[]
.IP
.nf
\f[C]
Path\ to\ a\ custom\ ilc.exe
\f[]
.fi
.PP
\f[C]\-\-linklib\ <LIB_PATH>\f[]
.IP
.nf
\f[C]
Path\ to\ static\ lib\ to\ link
\f[]
.fi
.PP
\f[C]\-\-logpath\ <LOG_PATH>\f[]
.IP
.nf
\f[C]
Enables\ logging\ and\ writes\ native\ compilation\ logs\ to\ the\ given\ path.
\f[]
.fi
.PP
\f[C]\-m,\ \-\-mode\ [cpp|ryujit|custom]\f[]
.IP
.nf
\f[C]
Code\ generation\ mode.\ Defaults\ to\ ryujit.
\f[]
.fi
.PP
\f[C]\-o,\ \-\-out\ directoryname\f[]
.IP
.nf
\f[C]
Output\ directory\ for\ the\ native\ executable.
\f[]
.fi
.PP
\f[C]\-r,\ \-\-reference\f[]
.IP
.nf
\f[C]
Path\ to\ a\ managed\ dll\ reference\ for\ the\ app.
\f[]
.fi
.PP
\f[C]\-t,\ \-\-temp\-out\f[]
.IP
.nf
\f[C]
Specifies\ temporary\ directory\ for\ intermediate\ files.
\f[]
.fi
.PP
\f[C]\-v,\ \-\-verbose\f[]
.IP
.nf
\f[C]
Prints\ verbose\ logging\ information,\ to\ follow\ the\ flow\ of\ execution\ of\ the\ command.
\f[]
.fi
.SH SEE ALSO
.PP
dotnet\-compile(1), dotnet(1), dotnet\-restore(1)
.SH AUTHORS
Zlatko Knezevic zlakne\@microsoft.com.

157
Documentation/manpages/sdk/dotnet-compile.1
View file

@ -1,157 +0,0 @@
.\" Automatically generated by Pandoc 1.15.1
.\"
.hy
.TH "dotnet-compiler" "1" "January 2016" "" ""
.SH NAME
.PP
dotnet\-compile \-\- Compiles source files for a single project to a
binary format and saves to a target file.
.SH SYNOPSIS
.PP
dotnet compile [\-\-native] [\-\-output] [\-\-temp\-output]
[\-\-framework] [\-\-configuration] [\-\-output] [\-\-arch] [\-\-cpp]
[\-ilc\-args] [\-\-verbose]
.SH DESCRIPTION
.PP
The compile command compiles source files from a single project to a
binary file, either intermediate language (IL) byte code or native
machine code, depending on the options provided.
The default option is compilation to IL byte code, but may change in the
future.
Users who want to benefit from incremental builds and who want to
compile both the project and its dependencies should use the
dotnet\-build(1) command.
.PP
The result of compilation is by default an executable file that can be
ran.
Output files, are written to the child \f[C]bin\f[] folder, which will
be created if it doesn\[aq]t exist.
Files will be overwritten as needed.
The temporary files that are created during compilation are placed in
the child \f[C]obj\f[] folder.
.PP
The executables also require a special configuration section in
project.json:
.IP
.nf
\f[C]
{\
\ \ \ \ "compilationOptions":\ {
\ \ \ \ \ \ "emitEntryPoint":\ true
\ \ \ \ }
}
\f[]
.fi
.PP
The default native [\-\-native] output is a native exe that conforms to
the architecture of the underlying operating system (i.e.
running on 64\-bit OS will produce a native 64\-bit exe).
This can be overriden via the \-\-arch switch and specifying the wanted
architecture.
The executable has a default extension of "" on Linux and OS X and
".exe" on Windows.
The source must include a static void main entry point, or it is an
error, unless otherwise specified in the project.json.
The dynamic library [dylib] output option has the default extension of
".so" on Linux/UNIX, ".dynlib" on OS X and ".dll" on Windows.
The static library [staticlib] option has the default extension of ".a"
on Linux, UNIX and OS X and ".lib" on Windows.
.PP
This command relies on the following artifacts: source files,
project.json project file and the "lock" file (project.lock.json).
Prior to invoking dotnet\-compile, dotnet\-restore(1) should be run to
restore any dependencies that are needed for the application.
.SH OPTIONS
.PP
\f[C]\-n,\ \-\-native\f[]
.IP
.nf
\f[C]
Compiles\ source\ to\ native\ machine\ code,\ for\ the\ local\ machine.\ The\ default\ is\ a\ native\ executable.\ The\ default\ executable\ extension\ is\ no\ extension\ and\ ".exe"\ on\ Windows.
\f[]
.fi
.PP
\f[C]\-t,\ \-\-temp\-output\ <PATH>\f[]
.IP
.nf
\f[C]
Path\ where\ to\ drop\ the\ temporary\ binaries\ that\ are\ produced\ during\ compile.\ By\ default,\ the\ temporary\ binaries\ are\ dropped\ in\ the\ `obj`\ directory\ in\ the\ directory\ where\ `project.json`\ files\ lives,\ that\ is,\ where\ the\ application\ lives.\ \
\f[]
.fi
.PP
\f[C]\-f,\ \-\-framework\ <FID>\f[]
.IP
.nf
\f[C]
Compile\ the\ application\ for\ the\ specified\ framework.\ If\ the\ framework\ is\ not\ specified,\ one\ specified\ in\ `project.json`\ will\ be\ used.\
\f[]
.fi
.PP
\f[C]\-c,\ \-\-configuration\ <CONFIGURATION>\f[]
.IP
.nf
\f[C]
Compile\ the\ application\ under\ the\ specified\ configuration.\ If\ not\ specified,\ the\ configuration\ will\ default\ to\ "Debug".\ \
\f[]
.fi
.PP
\f[C]\-o,\ \-\-output\ filename\f[]
.IP
.nf
\f[C]
Specifies\ the\ filename\ to\ be\ used.\ By\ default,\ the\ resulting\ filename\ will\ be\ the\ same\ as\ the\ project\ name\ specified\ in\ `project.json`,\ if\ one\ exists,\ or\ the\ directory\ in\ which\ the\ source\ files\ reside.\
\f[]
.fi
.PP
\f[C]\-\-no\-project\-dependencies\f[]
.IP
.nf
\f[C]
Skips\ building\ cross\-project\ references.\ The\ effect\ of\ this\ is\ that\ only\ the\ current\ project\ will\ be\ built.\
\f[]
.fi
.PP
\f[C]\-a,\ \-\-arch\f[]
.IP
.nf
\f[C]
The\ architecture\ for\ which\ to\ compile.\ x64\ only\ currently\ supported.
\f[]
.fi
.PP
\f[C]\-\-ilc\-args\ <ARGS>\f[]
.IP
.nf
\f[C]
Specified\ parameters\ are\ passed\ through\ to\ ILC\ and\ are\ used\ by\ the\ engine\ when\ doing\ native\ compilation.\
\f[]
.fi
.PP
\f[C]\-\-cpp\f[]
.IP
.nf
\f[C]
Specify\ the\ C++\ code\ generator\ to\ do\ native\ compilation\ of\ code\ instead\ of\ the\ default\ RyuJIT.\ \ \ \ \ \ \
\f[]
.fi
.PP
\f[C]\-v,\ \-\-verbose\f[]
.IP
.nf
\f[C]
Prints\ verbose\ logging\ information,\ to\ follow\ the\ flow\ of\ execution\ of\ the\ command.
\f[]
.fi
.PP
\f[C]\-h,\ \-\-help\f[]
.IP
.nf
\f[C]
Show\ short\ help.\
\f[]
.fi
.SH SEE ALSO
.PP
dotnet\-restore(1), dotnet\-publish(1), dotnet(1)
.SH AUTHORS
Zlatko Knezevic zlakne\@microsoft.com.

81
Documentation/manpages/sdk/dotnet-new.1
View file

@ -1,81 +0,0 @@
.\" Automatically generated by Pandoc 1.15.1
.\"
.hy
.TH "DOTNET\-NEW" "1" "June 2016" "" ""
.SS NAME
.PP
dotnet\-new \-\- Create a new sample .NET Core project
.SS SYNOPSIS
.PP
dotnet new [\-\-type] [\-\-lang]
.SS DESCRIPTION
.PP
The \f[C]dotnet\ new\f[] command provides a convenient way to initialize
a valid .NET Core project and sample source code to try out the Command
Line Interface (CLI) toolset.
.PP
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:
.IP "1." 3
A \f[C]Program.cs\f[] (or \f[C]Program.fs\f[]) file that contains a
sample "Hello World" program.
.IP "2." 3
A valid \f[C]project.json\f[] file.
.PP
After this, the project is ready to be compiled and/or edited further.
.SS Options
.PP
\f[C]\-l\f[], \f[C]\-\-lang\ [C#|F#]\f[]
.PP
Language of the project.
Defaults to \f[C]C#\f[].
\f[C]csharp\f[] (\f[C]fsharp\f[]) or \f[C]cs\f[] (\f[C]fs\f[]) are also
valid options.
.PP
\f[C]\-t\f[], \f[C]\-\-type\f[]
.PP
Type of the project.
Valid values for C# are:
.IP \[bu] 2
\f[C]console\f[]
.IP \[bu] 2
\f[C]web\f[]
.IP \[bu] 2
\f[C]lib\f[]
.IP \[bu] 2
\f[C]xunittest\f[]
.PP
Valid values for F# are:
.IP \[bu] 2
\f[C]console\f[]
.SS EXAMPLES
.PP
\f[C]dotnet\ new\f[]
.IP
.nf
\f[C]
Drops\ a\ sample\ C##\ project\ in\ the\ current\ directory.
\f[]
.fi
.PP
\f[C]dotnet\ new\ \-\-lang\ f##\f[]
.IP
.nf
\f[C]
Drops\ a\ sample\ F##\ project\ in\ the\ current\ directory.
\f[]
.fi
.PP
\f[C]dotnet\ new\ \-\-lang\ c##\f[]
.IP
.nf
\f[C]
Drops\ a\ sample\ C##\ project\ in\ the\ current\ directory.
\f[]
.fi
.SH SEE ALSO
.PP
dotnet\-run(1)
.SH AUTHORS
Microsoft Corporation dotnetclifeedback\@microsoft.com.

91
Documentation/manpages/sdk/dotnet-pack.1
View file

@ -1,91 +0,0 @@
.\" Automatically generated by Pandoc 1.15.1
.\"
.hy
.TH "DOTNET\-PACK" "1" "June 2016" "" ""
.SS NAME
.PP
\f[C]dotnet\-pack\f[] \- Packs the code into a NuGet package
.SS SYNOPSIS
.PP
\f[C]dotnet\ pack\ [\-\-output]\ \ \ \ \ \ \ [\-\-no\-build]\ [\-\-build\-base\-path]\ \ \ \ \ \ \ [\-\-configuration]\ \ [\-\-version\-suffix]\ \ \ \ \ [<project>]\f[]
.SS DESCRIPTION
.PP
The \f[C]dotnet\ pack\f[] command builds the project and creates NuGet
packages.
The result of this operation is two packages with the \f[C]nupkg\f[]
extension.
One package contains the code and the other contains the debug symbols.
.PP
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 \f[C]type\f[] set to "build" like in the
following example:
.IP
.nf
\f[C]
{
\ \ \ \ "version":\ "1.0.0\-*",
\ \ \ \ "dependencies":\ {
\ \ \ \ \ \ \ \ "ProjectA":\ {
\ \ \ \ \ \ \ \ \ \ \ \ "target":\ "project",
\ \ \ \ \ \ \ \ \ \ \ \ "type":\ "build"
\ \ \ \ \ \ \ \ }
\ \ \ \ }
}
\f[]
.fi
.PP
\f[C]dotnet\ pack\f[] by default first builds the project.
If you wish to avoid this, pass the \f[C]\-\-no\-build\f[] option.
This can be useful in Continuous Integration (CI) build scenarios in
which you know the code was just previously built, for example.
.SS OPTIONS
.PP
\f[C][project]\f[]
.PP
The project to pack.
It can be either a path to a \f[C]project.json\f[] file or to a
directory.
If omitted, it will default to the current directory.
.PP
\f[C]\-o\f[], \f[C]\-\-output\f[] [DIR]
.PP
Places the built packages in the directory specified.
.PP
\f[C]\-\-no\-build\f[]
.PP
Skips the building phase of the packing process.
.PP
\f[C]\-\-build\-base\-path\f[]
.PP
Places the temporary build artifacts in the specified directory.
By default, they go to the obj directory in the current directory.
.PP
\f[C]\-c\f[], \f[C]\-\-configuration\ [Debug|Release]\f[]
.PP
Configuration to use when building the project.
If not specified, will default to "Debug".
.SS EXAMPLES
.PP
\f[C]dotnet\ pack\f[]
.PP
Packs the current project.
.PP
\f[C]dotnet\ pack\ ~/projects/app1/project.json\f[]
.PP
Packs the app1 project.
.PP
\f[C]dotnet\ pack\ \-\-output\ nupkgs\f[]
.PP
Packs the current application and place the resulting packages into the
specified folder.
.PP
\f[C]dotnet\ pack\ \-\-no\-build\ \-\-output\ nupkgs\f[]
.PP
Packs the current project into the specified folder and skips the build
step.
.SH AUTHORS
Microsoft Corporation dotnetclifeedback\@microsoft.com.

107
Documentation/manpages/sdk/dotnet-publish.1
View file

@ -1,107 +0,0 @@
.\" Automatically generated by Pandoc 1.15.1
.\"
.hy
.TH "DOTNET\-PUBLISH" "1" "June 2016" "" ""
.SS NAME
.PP
\f[C]dotnet\-publish\f[] \- Packs the application and all of its
dependencies into a folder getting it ready for publishing
.SS SYNOPSIS
.PP
\f[C]dotnet\ publish\ [\-\-framework]\ \ \ \ \ \ \ [\-\-runtime]\ [\-\-build\-base\-path]\ [\-\-output]\ \ \ \ \ \ \ [\-\-version\-suffix]\ [\-\-configuration]\ \ \ \ \ \ \ [<project>]\f[]
.SS DESCRIPTION
.PP
\f[C]dotnet\ publish\f[] compiles the application, reads through its
dependencies specified in the \f[C]project.json\f[] file and publishes
the resulting set of files to a directory.
.PP
Depending on the type of portable app, the resulting directory will
contain the following:
.IP "1." 3
\f[B]Portable application\f[] \- application\[aq]s intermediate language
(IL) code and all of application\[aq]s managed dependencies.
.RS 4
.IP \[bu] 2
\f[B]Portable application with native dependencies\f[] \- same as above
with a sub\-directory for the supported platform of each native
dependency.
.RE
.IP "2." 3
\f[B]Self\-contained application\f[] \- same as above plus the entire
runtime for the targeted platform.
.PP
The above types are covered in more details in the types of portable
applications (../../app-types.md) topic.
.SS OPTIONS
.PP
\f[C][project]\f[]
.PP
\f[C]dotnet\ publish\f[] needs access to the \f[C]project.json\f[] file
to work.
If it is not specified on invocation via [project],
\f[C]project.json\f[] in the current directory will be the default.
.PD 0
.P
.PD
If no \f[C]project.json\f[] can be found, \f[C]dotnet\ publish\f[] will
throw an error.
.PP
\f[C]\-f\f[], \f[C]\-\-framework\f[] [FID]
.PP
Publishes the application for a given framework identifier (FID).
If not specified, FID is read from \f[C]project.json\f[].
In no valid framework is found, the command will throw an error.
If multiple valid frameworks are found, the command will publish for all
valid frameworks.
.PP
\f[C]\-r\f[], \f[C]\-\-runtime\f[] [RID]
.PP
Publishes the application for a given runtime.
.PP
\f[C]\-b\f[], \f[C]\-\-build\-base\-path\f[] [DIR]
.PP
Directory in which to place temporary outputs.
.PP
\f[C]\-o\f[], \f[C]\-\-output\f[]
.PP
Specify the path where to place the directory.
If not specified, it will default to
\f[I]\&./bin/[configuration]/[framework]/\f[] for portable applications
or \f[I]\&./bin/[configuration]/[framework]/[runtime]\f[] for
self\-contained applications.
.PP
\-\-version\-suffix [VERSION_SUFFIX]
.PP
Defines what \f[C]*\f[] should be replaced with in the version field in
the project.json file.
.PP
\f[C]\-c\f[], \f[C]\-\-configuration\ [Debug|Release]\f[]
.PP
Configuration to use when publishing.
The default value is Debug.
.SS EXAMPLES
.PP
\f[C]dotnet\ publish\f[]
.PP
Publishes an application using the framework found in
\f[C]project.json\f[].
If \f[C]project.json\f[] contains \f[C]runtimes\f[] node, publish for
the RID of the current platform.
.PP
\f[C]dotnet\ publish\ ~/projects/app1/project.json\f[]
.PP
Publishes the application using the specified \f[C]project.json\f[].
.PP
\f[C]dotnet\ publish\ \-\-framework\ netcoreapp1.0\f[]
.PP
Publishes the current application using the \f[C]netcoreapp1.0\f[]
framework.
.PP
\f[C]dotnet\ publish\ \-\-framework\ netcoreapp1.0\ \-\-runtime\ osx.10.11\-x64\f[]
.PP
Publishes the current application using the \f[C]netcoreapp1.0\f[]
framework and runtime for \f[C]OS\ X\ 10.10\f[].
This RID has to exist in the \f[C]project.json\f[] \f[C]runtimes\f[]
node.
.SH AUTHORS
Microsoft Corporation dotnetclifeedback\@microsoft.com.

97
Documentation/manpages/sdk/dotnet-restore.1
View file

@ -1,97 +0,0 @@
.\" Automatically generated by Pandoc 1.15.1
.\"
.hy
.TH "DOTNET\-RESTORE" "1" "June 2016" "" ""
.SS NAME
.PP
\f[C]dotnet\-restore\f[] \- Restores the dependencies and tools of a
project
.SS SYNOPSIS
.PP
\f[C]dotnet\ restore\ [\-\-source]\ \ \ \ \ \ \ [\-\-packages]\ [\-\-disable\-parallel]\ \ \ \ \ \ \ [\-\-fallbacksource]\ [\-\-configfile]\ [\-\-verbosity]\ \ \ \ \ [<root>]\f[]
.SS DESCRIPTION
.PP
The \f[C]dotnet\ restore\f[] command uses 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 are done in
parallel.
.PP
In order to restore the dependencies, NuGet needs the feeds where the
packages are located.
Feeds are usually provided via the NuGet.config configuration file; a
default one is present when the 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.
.PP
For dependencies, you can specify where the restored packages are placed
during the restore operation using the \f[C]\-\-packages\f[] argument.
If not specified, the default NuGet package cache is used.
It is found in the \f[C]\&.nuget/packages\f[] directory in the
user\[aq]s home directory on all operating systems (for example,
\f[C]/home/user1\f[] on Linux or \f[C]C:\\Users\\user1\f[] on Windows).
.PP
For project\-specific tooling, \f[C]dotnet\ restore\f[] first restores
the package in which the tool is packed, and then proceeds to restore
the tool\[aq]s dependencies as specified in its project.json.
.SS OPTIONS
.PP
\f[C][root]\f[]
.PP
A list of projects or project folders to restore.
The list can contain either a path to a \f[C]project.json\f[] file, or a
path to \f[C]global.json\f[] file or folder.
The restore operation runs recursively for all subdirectories and
restores for each given project.json file it finds.
.PP
\f[C]\-s\f[], \f[C]\-\-source\f[] [SOURCE]
.PP
Specifies a source to use during the restore operation.
This overrides all of the sources specified in the NuGet.config file(s).
.PP
\f[C]\-\-packages\f[] [DIR]
.PP
Specifies the directory to place the restored packages in.
.PP
\f[C]\-\-disable\-parallel\f[]
.PP
Disables restoring multiple projects in parallel.
.PP
\f[C]\-f\f[], \f[C]\-\-fallbacksource\f[] [FEED]
.PP
Specifies a fallback source that will be used in the restore operation
if all other sources fail.
All valid feed formats are allowed.
.PP
\f[C]\-\-configfile\f[] [FILE]
.PP
Configuration file (NuGet.config) to use for the restore operation.
.PP
\f[C]\-\-verbosity\f[] [LEVEL]
.PP
The verbosity of logging to use.
Allowed values: Debug, Verbose, Information, Minimal, Warning, or Error.
.SS EXAMPLES
.PP
\f[C]dotnet\ restore\f[]
.PP
Restores dependencies and tools for the project in the current
directory.
.PP
\f[C]dotnet\ restore\ ~/projects/app1/project.json\f[]
.PP
Restores dependencies and tools for the \f[C]app1\f[] project found in
the given path.
.PP
\f[C]dotnet\ restore\ \-\-f\ c:\\packages\\mypackages\f[]
.PP
Restores the dependencies and tools for the project in the current
directory using the file path provided as the fallback source.
.PP
\f[C]dotnet\ restore\ \-\-verbosity\ Error\f[]
.PP
Restores dependencies and tools for the project in the current directory
and shows only errors in the output.
.SH AUTHORS
Microsoft Corporation dotnetclifeedback\@microsoft.com.

88
Documentation/manpages/sdk/dotnet-run.1
View file

@ -1,88 +0,0 @@
.\" Automatically generated by Pandoc 1.15.1
.\"
.hy
.TH "DOTNET\-RUN" "1" "June 2016" "" ""
.SS NAME
.PP
dotnet\-run \-\- Runs source code \[aq]in\-place\[aq] without any
explicit compile or launch commands.
.SS SYNOPSIS
.PP
\f[C]dotnet\ run\ [\-\-framework]\ [\-\-configuration]\ \ \ \ \ [\-\-project]\ [\-\-help]\ [\-\-]\f[]
.SS DESCRIPTION
.PP
The \f[C]dotnet\ run\f[] command provides a convenient option to run
your application from the 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 (for example, a website).
.PP
This command relies on \f[C]dotnet\ build\f[] (dotnet-build.md) to build
source inputs to a .NET assembly, before launching the program.
The requirements for this command and the handling of source inputs are
all inherited from the build command.
The documentation for the build command provides more information on
those requirements.
.PP
Output files are written to the child \f[C]bin\f[] folder, which will be
created if it doesn\[aq]t exist.
Files will be overwritten as needed.
Temporary files are written to the child \f[C]obj\f[] folder.
.PP
In case of a project with multiple specified frameworks,
\f[C]dotnet\ run\f[] will first select the .NET Core frameworks.
If those do not exist, it will error out.
To specify other frameworks, use the \f[C]\-\-framework\f[] argument.
.PP
The \f[C]dotnet\ run\f[] command must be used in the context of
projects, not built assemblies.
If you\[aq]re trying to execute a DLL instead, you should use
\f[C]dotnet\f[] (dotnet.md) without any command like in the following
example:
.PP
\f[C]dotnet\ myapp.dll\f[]
.PP
For more information about the \f[C]dotnet\f[] driver, see the \&.NET
Core Command Line Tools (CLI) (overview.md) topic.
.SS OPTIONS
.PP
\f[C]\-\-\f[]
.PP
Delimits arguments to \f[C]dotnet\ run\f[] from arguments for the
application being run.
All arguments after this one will be passed to the application being
run.
.PP
\f[C]\-f\f[], \f[C]\-\-framework\f[] [FID]
.PP
Runs the application for a given framework identifier (FID).
.PP
\f[C]\-c\f[], \f[C]\-\-configuration\ [Debug|Release]\f[]
.PP
Configuration to use when publishing.
The default value is "Debug".
.PP
\f[C]\-p\f[], \f[C]\-\-project\ [PATH]\f[]
.PP
Specifies which project to run.
It can be a path to a project.json file or to a directory containing a
project.json file.
It defaults to current directory if not specified.
.SS EXAMPLES
.PP
\f[C]dotnet\ run\f[]
.PP
Runs the project in the current directory.
.PP
\f[C]dotnet\ run\ \-\-project\ /projects/proj1/project.json\f[]
.PP
Runs the project specified.
.PP
\f[C]dotnet\ run\ \-\-configuration\ Release\ \-\-\ \-\-help\f[]
.PP
Runs the project in the current directory.
The \f[C]\-\-help\f[] argument above is passed to the application being
run, since the \f[C]\-\-\f[] argument was used.
.SH AUTHORS
Microsoft Corporation dotnetclifeedback\@microsoft.com.

170
Documentation/manpages/sdk/dotnet-test.1
View file

@ -1,170 +0,0 @@
.\" Automatically generated by Pandoc 1.15.1
.\"
.hy
.TH "DOTNET\-TEST" "1" "April 2016" "" ""
.SH Dotnet Test, Adapters and Test Runners
.PP
This document covers the interactions between dotnet test, a potential
adapter (like VS) and test runners (like
xunit (https://github.com/dotnet/coreclr.xunit)).
.PP
It describes the communication protocol for these agents, the parameters
that the runner needs to support and the modes on which dotnet test and
the runner work.
.SS Running modes
.PP
Dotnet test supports two running modes:
.IP "1." 3
Console: In console mode, dotnet test simply executes fully whatever
command gets passed to it and outputs the results.
Anytime you invoke dotnet test without passing \-\-port, it will run in
console mode, which in turn will cause the runner to run in console
mode.
.IP "2." 3
Design time: Anytime you pass a port to dotnet test, we will run in
design time.
That means that dotnet test will connect to that port using TCP and will
then exchange a established set of messages with whatever else is
connected to that port.
When this happens, the runner also receives a port (a new one, mind you)
that dotnet test will use to communicate with it.
The reason why the runner also uses TCP to communicate with dotnet test
is because in design mode, it is not sufficient to just output results
to the console.
We need to send the adapter structure messages containing the results of
the test execution.
.SS Communication protocol in design time.
.IP "1." 3
Because during design time, dotnet test connects to a port when it
starts up, the adapter needs to be listening on that port otherwise
dotnet test will fail.
We did it like this so that the adapter could reserve all the ports it
needs by binding and listening to them before dotnet test ran and tried
to get ports for the runner.
.IP "2." 3
Once dotnet test starts, it sends a TestSession.Connected message to the
adapter indicating that it is ready to receive messages.
.IP "3." 3
It is possible to send an optional version
check (https://github.com/dotnet/cli/blob/rel/1.0.0/src/Microsoft.Extensions.Testing.Abstractions/Messages/ProtocolVersionMessage.cs)
message with the adapter version of the protocol in it.
Dotnet test will send back the version of the protocol that it supports.
.PP
All messages have the format described here:
Message.cs (https://github.com/dotnet/cli/blob/rel/1.0.0/src/Microsoft.Extensions.Testing.Abstractions/Messages/Message.cs).
The payload formats for each message is described in links to the
classes used to de/serialize the information in the description of the
protocol.
.SS Test Execution
.PP
[IMAGE: alt
tag (../../../../Documentation/images/DotnetTestExecuteTests.png)]
.IP "1." 3
After the optional version check, the adapter sends a
TestExecution.GetTestRunnerProcessStartInfo, with the
tests (https://github.com/dotnet/cli/blob/rel/1.0.0/src/Microsoft.Extensions.Testing.Abstractions/Messages/RunTestsMessage.cs)
it wants to execute inside of it.
Dotnet test sends back a FileName and Arguments inside a
TestStartInfo (https://github.com/dotnet/cli/blob/rel/1.0.0/src/dotnet/commands/dotnet-test/TestStartInfo.cs)
payload that the adapter can use to start the runner.
In the past, we would send the list of tests to run as part of that
argument, but we were actually going over the command line size limit
for some test projects.
.IP "2." 3
As part of the arguments, we send a port that the runner should connect
to and for executing tests, a \-\-wait\-command flag, that indicates
that the runner should connect to the port and wait for commands,
instead of going ahead and executing the tests.
.IP "3." 3
At this point, the adapter can launch the runner (and attach to it for
debugging if it chooses to).
.IP "4." 3
Once the runner starts, it sends dotnet test a TestRunner.WaitCommand
message that indicates it is ready to receive commands, at which point
dotnet test sends a TestRunner.Execute with the list of
tests (https://github.com/dotnet/cli/blob/rel/1.0.0/src/Microsoft.Extensions.Testing.Abstractions/Messages/RunTestsMessage.cs)
to run.
This bypasses the command line size limit described above.
.IP "5." 3
The runner then sends dotnet test (and it passes forward to the adapter)
a TestExecution.TestStarted for each tests as they start with the
test (https://github.com/dotnet/cli/blob/rel/1.0.0/src/Microsoft.Extensions.Testing.Abstractions/Test.cs)
information inside of it.
.IP "6." 3
The runner also sends dotnet test (and it forwards to the adapter) a
TestExecution.TestResult for each test with the individual
result (https://github.com/dotnet/cli/blob/rel/1.0.0/src/Microsoft.Extensions.Testing.Abstractions/TestResult.cs)
of the test.
.IP "7." 3
After all tests finish, the runner sends a TestRunner.Completed message
to dotnet test, which dotnet test sends as TestExecution.Completed to
the adapter.
.IP "8." 3
Once the adapter is done, it sends dotnet test a TestSession.Terminate
which will cause dotnet test to shutdown.
.SS Test discovery
.PP
[IMAGE: alt
tag (../../../..//Documentation/images/DotnetTestDiscoverTests.png)]
.IP "1." 3
After the optional version check, the adapter sends a
TestDiscovery.Start message.
Because in this case, the adapter does not need to attach to the
process, dotnet test will start the runner itself.
Also, since there is no long list of arguments to be passed to the
runner, no \-\-wait\-command flag is needed to be passed to the runner.
dotnet test only passes a \-\-list argument to the runner, which means
the runner should not run the tests, just list them.
.IP "2." 3
The runner then sends dotnet test (and it passes forward to the adapter)
a TestDiscovery.TestFound for each
test (https://github.com/dotnet/cli/blob/rel/1.0.0/src/Microsoft.Extensions.Testing.Abstractions/Test.cs)
found.
.IP "3." 3
After all tests are discovered, the runner sends a TestRunner.Completed
message to dotnet test, which dotnet test sends as
TestDiscovery.Completed to the adapter.
.IP "4." 3
Once the adapter is done, it sends dotnet test a TestSession.Terminate
which will cause dotnet test to shutdown.
.SS Dotnet test parameters
.PP
Any parameters not accepted by dotnet test will be forwarded to the
runner.
This is the list of parameters supported by dotnet test from its own
help print out:
.PP
Usage: dotnet test [arguments] [options]
.PP
Arguments: The project to test, defaults to the current directory.
Can be a path to a project.json or a project directory.
.PP
Options: \-?|\-h|\-\-help Show help information \-\-parentProcessId Used
by IDEs to specify their process ID.
Test will exit if the parent process does.
\-\-port Used by IDEs to specify a port number to listen for a
connection.
\-c|\-\-configuration Configuration under which to build \-o|\-\-output
Directory in which to find the binaries to be run
\-b|\-\-build\-base\-path Directory in which to find temporary outputs
\-f|\-\-framework Looks for test binaries for a specific framework
\-r|\-\-runtime Look for test binaries for a for the specified runtime
\-\-no\-build Do not build project before testing
.SS Minimum parameters that the runner needs to support
.IP \[bu] 2
AssemblyUnderTest: Path to the dll that contains the tests to be run.
.IP \[bu] 2
\-\-port: Used by dotnet test to specify a port number that the runner
should connect to.
.IP \[bu] 2
\-\-list: Indicates that the tests should only be listed and not
executed.
.IP \[bu] 2
\-\-designtime: Indicates that the runner is running in design time, for
instance, inside an adapter.
.IP \[bu] 2
\-\-wait\-command: Indicates that the runner should wait to receive
commands through the TCP channel instead of running tests right away.
We use this to get around the command line size limit.
.SH AUTHORS
Microsoft Corporation dotnetclifeedback\@microsoft.com.

17
Documentation/migration-issues.md
View file

@ -1,17 +0,0 @@
## Getting help on migration issues
You're using the new .NET Core tools that are MSBuild-based. You took your project.json project and ran `dotnet migrate` or migrated from Visual Studio 2017...and you maybe ran into problems.
The best way to get help is to [file an issue](https://github.com/dotnet/cli/issues/new) on this repo and we will investigate and provide help and/or fixes as part of new CLI builds. Please make sure to read the instructions below and to **add the [MIGRATION] prefix to the issue title**.
### Filing an migration issue
CLI is a very high-traffic repository in terms of issues. In order to be able to respond fast to migration issues, we need the issue to be formatted in a certain way:
* Add `[MIGRATION]:` prefix to the title of the issue.
* Make sure that we can see your project.json
* If you have a GH repo or this is an OSS project, share the URL to the repo.
* Otherwise attach or paste the project.json contents into the issue.
* Add all of the errors that any operation like `dotnet restore`, `dotnet build` or others reported. This will help us speedily triage where the potential problem will be.
* Add output of `dotnet --info` to the issue so we know what build you are running.
* Mention @blackdwarf and @livarcocc in the issue body.
From there on, we will start investigating the issue and respond.

74
Documentation/project-docs/developer-guide.md
View file

@ -1,74 +0,0 @@
Developer Guide
===============
## Prerequisites
In order to build .NET Command Line Interface, you need the following installed on you machine.
### For Windows
1. git (available from http://www.git-scm.com/) on the PATH.
### For Linux
1. git (available from http://www.git-scm.com/) on the PATH.
### For OS X
1. Xcode
2. git (available from http://www.git-scm.com/) on the PATH.
3. Install OpenSSL (a .NET Core requirement)
- brew update
- brew install openssl
- mkdir -p /usr/local/lib
- ln -s /usr/local/opt/openssl/lib/libcrypto.1.0.0.dylib /usr/local/lib/
- ln -s /usr/local/opt/openssl/lib/libssl.1.0.0.dylib /usr/local/lib/
## Building/Running
1. Run `build.cmd` or `build.sh` from the root depending on your OS. If you don't want to execute tests, run `build.cmd /t:Compile` or `./build.sh /t:Compile`.
- To build the CLI in macOS Sierra, you need to set the DOTNET_RUNTIME_ID environment variable by running `export DOTNET_RUNTIME_ID=osx.10.11-x64`.
2. Use `artifacts/{RID}/stage2/dotnet` to try out the `dotnet` command. You can also add `artifacts/{os}-{arch}/stage2` to the PATH if you want to use the build output when invoking `dotnet` from the current console.
## A simple test
Using the `dotnet` built in the previous step:
1. `cd {new directory}`
2. `dotnet new`
3. `dotnet restore`
4. `dotnet run`
## Running tests
1. To run all tests invoke `build.cmd` or `build.sh` which will build the product and run the tests.
2. To run a specific test, cd into that test's directory and execute `dotnet test`. If using this approach, make sure to add `artifacts/{RID}/stage2` to your `PATH` and set the `NUGET_PACKAGES` environment variable to point to the repo's `.nuget/packages` directory.
## Adding a Command
The dotnet CLI supports several models for adding new commands:
1. In the CLI itself via `dotnet.dll`
2. Through a `tool` NuGet package
3. Through MSBuild tasks & targets in a NuGet package
4. Via the user's `PATH`
### Commands in dotnet.dll
Developers are generally encouraged to avoid adding commands to `dotnet.dll` or the CLI installer directly. This is appropriate for very general commands such as restore, build, publish, test, and clean, but is generally too broad of a distribution mechanism for new commands. Please create an issue and engage the team if you feel there is a missing core command that you would like to add.
### Tools NuGet packages
Many existing extensions, including those for ASP.NET Web applications, extend the CLI using Tools NuGet packages. For an example of a working packaged command look at `TestAssets/TestPackages/dotnet-hello/v1/`.
### MSBuild tasks & targets
NuGet allows adding tasks and targets to a project through a NuGet package. This mechanism, in fact, is how all .NET Core projects pull in the .NET SDK. Extending the CLI through this model has several advantages:
1. Targets have access to the MSBuild Project Context, allowing them to reason about the files and properties being used to build a particular project.
2. Targets are not CLI-specific, making them easy to share across command-line and IDE environments
Commands added as targets can be invoked once the target project adds a reference to the containing NuGet package and restores.
Targets are invoked by calling `dotnet msbuild /t:{TargetName}`
### Commands on the PATH
The dotnet CLI considers any executable on the path named `dotnet-{commandName}` to be a command it can call out to.
## Things to Know
- Any added commands are usually invoked through `dotnet {command}`. As a result of this, stdout and stderr are redirected through the driver (`dotnet`) and buffered by line. As a result of this, child commands should use Console.WriteLine in any cases where they expect output to be written immediately. Any uses of Console.Write should be followed by Console.WriteLine to ensure the output is written.

45
Documentation/project-docs/issue-filing-guide.md
View file

@ -1,45 +0,0 @@
Filing issues for .NET Core CLI
===============================
As you may notice based on our issues page, the CLI repo is what is known as a
"high-profile" and "high-volume" repo; we
get a lot of issues. This, in turn, may mean that some issues get
lost in the noise and/or are not reacted on with the needed speed.
In order to help with the above situation, we need to have a certain way to file
issues so that the core team of maintainers can react as fast as
possible and can triage effectively.
The below steps are something that we believe is not a huge increase in process,
but would help us react much faster to any issues that are filed.
1. Check if the [known issues](https://github.com/dotnet/core/blob/master/cli/known-issues.md) cover the issue you are running
into. We are collecting issues that are known and that have workarounds, so it
could be that you can get unblocked pretty easily.
4. /cc the person that the issue should be assigned to (or @blackdwarf) so that person
would get notified. In this way the correct person can immediately jump on the
issue and triage it.
5. For bugs, please be as concrete as possible on what is working, what
is not working. Things like operating system, the version of the tools, the
version of the installer and when you installed all help us determine the
potential problem and allows us to easily reproduce the problem at hand.
6. For enhancements please be as concrete as possible on what is the addition
you would like to see, what scenario it covers and especially why the current
tools cannot satisfy that scenario.
Thanks and happy filing! :)
## Providing the repro for bugs
For bugs, what we need more than anything is a good repro of the defective
behavior. We would like to go towards the "clone, run, repro" model. In short:
1. If you find a bug, package up a repro in a git repo somewhere (GitHub is
usually a good place :)).
2. Inside the issue, specify what needs to be done (steps) to get an accurate
repro of the bug. Ideally, this should be "here is how to build, these are the
commands you run from the dotnet tools".
3. We use the above to get the repro, investigate and fix!

445
Documentation/specs/canonical.md
View file

@ -1,445 +0,0 @@
Canonical scenarios
===================
# Contents
* [Overview](#overview)
* [Acquisition](#acquisition)
* Scenarios
* [Starting a new console application](#starting-a-new-console-application)
* [Starting a new class library](#starting-a-new-class-library)
* [Adding 3rd party dependencies to the projects](#adding-3rd-party-dependencies-to-the-projects)
* [Running unit tests](#running-unit-tests)
* [Publishing a shared runtime console application](#publishing-a-shared-runtime-console-application)
* [Publishing a self-contained console application for all platforms](#publishing-a-self-contained-console-application-for-all-platforms)
* [Packaging a class library](#packaging-a-class-library)
* [Installing `dotnet` extensions as tools](#installing-dotnet-extensions-as-tools)
# Overview
This document outlines the End-to-End canonical scenarios for the CLI tooling. The scenarios outline the planned steps that the developer needs to do to work with her applications.
Each scenario is organized around a narrative, which provides an explanation on what the developers are trying to do, steps that are needed for the user to achieve the needed narrative. Steps are organized as commands that the developer would need to execute on the command line to achieve the result.
These scenarios are focused on console applications and libraries.
# Acquisition
All of the scenarios below assume that the CLI tools have been acquired in some way. The acquisition of the CLI tools is explained in detail in a [separate specification](cli-install-experience.md). This document only contains a very short summary of that document.
There are two main ways to acquire the CLI toolset:
1. Using targeted platform's native installers - this approach is used by developers who want to get stable bits on their development machines and don't mind the system-wide installation and need for elevated privileges.
2. Using a local install (a zip/tarball) - this approach is used by developers who want to enable their build servers to use CLI toolset or who want to have multiple, side-by-side installs.
The bits that are gotten are same modulo potential differences in stability of the bits, however, the smoothness of the experience is not. With native installers the installers themselves do as much as possible to set up a working environment (installing dependencies where possible, setting needed environment variables etc.). Local installs require all of the work to be done by developers after dropping bits on the machine.
The below scenarios must work regardless of the way used to acquire the tools.
# Starting a new console application
## Narrative
The developer would like to kick the tires on .NET Core by writing a console application. She would like to use the new .NET Core CLI tooling to help her get started, manage dependencies and quickly test out the console application by running it from source. She would then like to try building the code and running it using the shared host that is installed with the CLI toolset.
## Steps
1. Create a C# console application via `dotnet new` command
```
/myapp> dotnet new myapp
```
2. Edit the C# code
```
namespace myapp
{
public static class Program
{
public static void Main(string[] args)
{
Console.WriteLine("Hello, World!");
}
}
}
```
3. Restore packages
```
/myapp> dotnet restore
[messages about restore progress]
Writing lock file /myapp/project.lock.json
/myapp>
```
4. Run from source for a quick test
```
/myapp> dotnet run
Hello World!
/myapp>
```
5. Build a binary that can be executed by the shared host
```
/myapp> dotnet build
[information about the build]
Creating build output:
/myapp/bin/Debug/netstandardapp1.5/myapp.dll
/myapp/bin/Debug/netstandardapp1.5/myapp.deps
/myapp/bin/Debug/netstandardapp1.5/[All dependencies' IL assemblies].dll
/myapp>
```
6. Run the built version using the shared host in the installed toolset
```
/myapp> dotnet run /myapp/bin/Debug/netstandardapp1.5/myapp.dll
Hello World!
```
# Starting a new class library
## Narrative
Once started, the developer wants to also include a class library in order to have a place to share common code. She wants to use the CLI toolset to bootstrap this effort as well.
## Steps
1. Create a new class library using `dotnet new`
```
/> dotnet new mylib --type lib
Creating a "mylib" class library in "mylib"
/mylib>
```
2. Restore the dependencies
```
/mylib> dotnet restore
[messages about restore progress]
Writing lock file /mylib/project.lock.json
/mylib>
```
3. Edit the `MyLib.cs` file
```
namespace mylib
{
public class mylib
{
public void Method1()
{
}
}
}
```
4. Build the code
```
/mylib> dotnet build
[information about the build]
Creating build output:
/mylib/bin/Debug/netstandardapp1.5/mylib.dll
/mylib/bin/Debug/netstandardapp1.5/mylib.deps
/mylib/bin/Debug/netstandardapp1.5/[All dependencies' IL assemblies].dll
/mylib>
```
# Adding 3rd party dependencies to the projects
## Narrative
Working towards a complete application, the developer realizes she needs to add good JSON parsing support. Searching across the internet, she finds JSON.NET to be the most recommended choice. She now uses the CLI tooling to install a dependency off of NuGet.
>**NOTE:** the shape of the commands used in this scenario is still being discussed.
## Steps
1. Install the package
```
/myapp> dotnet pkg install Newtonsoft.Json --version 8.0.2
[lots of messages about getting JSON.NET]
Writing lock file /tests/project.lock.json
/myapp>
```
2. Change the code to use the new dependency
```
using Newtonsoft.Json;
namespace myapp
{
public static class Program
{
public static void Main(string[] args)
{
var thing = JsonConvert.DeserializeObject("{ 'item': 1 }");
Console.WriteLine("Hello, World!");
Console.WriteLine(thing.item);
}
}
}
```
3. Run code from source
```
/myapp> dotnet run
Hello, World!
1
/myapp>
```
# Running unit tests
## Narrative
Writing tests is important, and our developer knows that. She is now writing out the shared logic in her class library and she wants to make sure that she has test coverage. Investigating the manuals, she realizes that the CLI toolset comes with support for xUnit tests including the test runner.
## Steps
1. Create a new xunit test project using `dotnet new`
```
/> dotnet new tests --type xunit
Created "tests" xunit test project in "tests".
/tests>
```
2. Restore the runner and dependencies
```
/tests> dotnet restore
[messages about restore progress]
Writing lock file /tests/project.lock.json
[messages about tool dependencies restore]
/tests>
```
3. Add a test to the test class
```
using System;
using Xunit;
namespace tests
{
public class Tests
{
[Fact]
public void AssertTrue() {
Assert.True(true);
}
}
}
```
3. Run tests using `dotnet test`
```
/tests> dotnet test
[information about discovery of tests]
=== TEST EXECUTION SUMMARY ===
test Total: 1, Errors: 0, Failed: 0, Skipped: 0, Time: 0.323s
/tests>
```
# Publishing a shared runtime console application
## Narrative
Coding away on the application has proven worthwhile and our developer wants to share her progress with another developer on her team. She wants to give just the application and its dependencies. Luckily, another developer can easily install the .NET Core SDK and get a shared host, which would be enough to run the application. The CLI toolset allows our developer to publish just the application's code (in IL) and dependencies.
## Steps
1. Publish the application
```
/myapp> dotnet publish --output /pubapp
[Lots of messages about publishing stuff]
Creating publish output:
/pubapp/myapp/myapp.dll
/pubapp/myapp/myapp.deps
/pubapp/myapp/[All dependencies' IL assemblies].dll
/myapp>
```
2. Run the project publish output:
```
/myapp> cd /pubapp/myapp
/pubapp/myapp> dotnet ./myapp.dll
Hello, World!
/published/myapp>
```
3. The published application can be transferred over to a machine that has the .NET Core shared host installed and it is possible for it to be ran.
# Publishing a self-contained console application for all platforms
## Narrative
After getting feedback from her colleague developer, our developer decides to test on another machine. However, this machine doesn't have the shared host installed and she cannot get it installed. Luckily, she realizes that .NET Core has support for self-contained applications
**NOTE**: some of the behaviours in this scenario are still being discussed with the relevant stakeholders.
## Steps
1. Modify the project file to enable it to be published as a standalone, platform-specific application (one that doesn't require `dotnet` on the target machine to run) for the desired platforms by adding the `"runtimes"` section:
```
{
"imports": {
"Microsoft.ProjectType.ConsoleApplication": "1.0.0"
},
"runtimes": {
"linux-x64": { },
"win7-x64": { }
}
}
```
2. Restore the project's dependencies again to ensure the platform-specific dependencies for the specified runtimes are acquired:
```
/myapp> dotnet restore
[lots of messages about restoring stuff]
Writing lock file /myapp/project.lock.json
/myapp>
```
3. Publish the project again. In this case, the publish will publish for each runtime in the `project.json` file
```
/myapp> dotnet publish --output /published/myapp
[Lots of messages about publishing stuff]
Creating publish output for (linux-x64):
/published/myapp-linux-x64/myapp
/published/myapp-linux-x64/myapp.dll
/published/myapp-linux-x64/myapp.deps
/published/myapp-linux-x64/[All dependencies' IL & platform-specific assemblies, inc. stdlib]
Creating publish output for (win7-x64):
/published/myapp-win7-x64/myapp
/published/myapp-win7-x64/myapp.dll
/published/myapp-win7-x64/myapp.deps
/published/myapp-win7-x64/[All dependencies' IL & platform-specific assemblies, inc. stdlib]
/myapp>
```
4. Any of the outputs above can be xcopied to the platform in question and it will work without having to have the shared host installed.
5. Publish the project for a specific platform (win7-x64):
```
/myapp> dotnet publish --output /win7/myapp --runtime win7-x64
[Lots of messages about publishing stuff]
Creating publish output for (win7-x64):
/published/myapp-win7-x64/myapp
/published/myapp-win7-x64/myapp.dll
/published/myapp-win7-x64/myapp.deps
/published/myapp-win7-x64/[All dependencies' IL & platform-specific assemblies, inc. stdlib]
/myapp>
```
# Packaging a class library
## Narrative
The developer wants to take the library she built and package it up as a NuGet package in order to share it with the rest of the ecosystem. Again, she would like to use the CLI toolset to achieve this. Since she wants to be sure that all her code is in a pristine condition, she will also build it one more time, run tests and then package it.
## Steps
1. Build the code to make sure no build errors have crept in
```
/mylib> dotnet build
[information about the build]
Creating build output:
/myapp/bin/Debug/netstandardapp1.5/myapp.dll
/myapp/bin/Debug/netstandardapp1.5/myapp.deps
/myapp/bin/Debug/netstandardapp1.5/[All dependencies' IL assemblies].dll
/mylib>
```
2. Switch to the test project and run unit tests
```console
[switch to the directory containing unit tests]
/mytests> dotnet test
[info about tests flies around]
=== TEST EXECUTION SUMMARY ===
test Total: 50, Errors: 0, Failed: 0, Skipped: 0, Time: 5.323s
/mytests>
```
3. Package the library
```console
[switch to the library directory]
/mylib> dotnet pack
[information about build is shown]
Producing nuget package "mylib.1.0.0" for mylib
mylib -> /mylib/bin/Debug/mylib.1.0.0.nupkg
Producing nuget package "mylib.1.0.0.symbols" for mylib
mylib -> /mylib/bin/Debug/mylib.1.0.0.symbols.nupkg
/mylib>
```
# Installing `dotnet` extensions as tools
## Narrative
As our developer is going further with her usage of the CLI tools, she figures out that there is an easy way to extend the CLI tools on her machine by adding project-level tools to her `project.json`. She uses the CLI to work with the tools and she is able to extend the default toolset to further fit her needs.
## Steps
>**TODO:** at this point, this needs more work to figure out how it will surface; it is listed here so it is not forgotten.

468
Documentation/specs/cli-installation-scenarios.md
View file

@ -1,468 +0,0 @@
Obtaining .NET CLI
==================
## Contents
* [Overview](#overview)
* [General principles](#general-principles)
* [Components that can be installed](#components-that-can-be-installed)
* [Installation process](#installation-process)
* [Removal process](#removal-process)
* [Upgrading the CLI](#upgrading-the-cli)
* [Layout on disk](#layout-on-disk)
* [Native dependencies](#native-dependencies)
* [Channels](#channels)
* [Funnels and discovery mechanisms for CLI bits](#funnels-and-discovery-mechanisms-for-cli-bits)
* [Getting Started page](#getting-started-page)
* [Repo landing page](#repo-landing-page)
* [Acquisition modes](#acquisition-modes)
* [Native installers](#native-installers)
* [Installation script](#installation-script)
* [Complete manual installation](#complete-manual-installation)
* [Docker](#docker)
* [NuGet Packages](#nuget-packages)
* [Acquiring through other products](#acquiring-through-other-products)
* [IDEs and editors](#ides-and-editors)
## Overview
This document/spec outlines the CLI install experience. This covers the technologies being used for install, the principles that are driving the installation experience, the ways users are coming to the installs and what each of the installs contains, in terms of stability and similar.
## General principles
- Upgrades using the native installers Just Work(tm)
- All user facing materials point to the getting started page
- Defaults are stable bits; users need extra effort to install Future builds
- Only HTTPS links are allowed in any online property
- Provide native installers for each supported platform
- Provide automation-ready installers for each target platform
## Components that can be installed
Overall, there are two significant installable components:
1. The .NET Core SDK
2. Shared runtime redistributable
The .NET Core SDK contains the following items:
1. A given version of the CLI toolset - "SDK"
2. A given version of the shared runtime - "redist" - this will be consumed by both end-customers and CLI toolset
3. A given version of the shared host - "muxer" - shared component that is in charge of running the applications and the CLI commands - it should be treated as an implementation detail
## Installation process
Each of the components listed in the previous section will have an installer/package. The dependencies of the installers between themseslves are given in the table below.
| Installer | Depends on |
|----------- |------------ |
| SDK | redist |
| redist | muxer |
| muxer | - |
The installation process will depend on the platform and the way of the install. For those installers that don't have automatic dependency resolution (Windows installer, OS X PKG) the installers will chain the installers of the components they depend on. DEB, RPM and similar will declare proper dependencies and the package manager will do the Right Thing(tm) by default.
From the table, we can see that if you install the SDK using `apt-get` for instance, you will get also a redist and a muxer. They will be separate packages, but will be declared as dependencies (similar for `yum`). Similar for the redist package.
The muxer is slightly a special case. Though there will be an installer, as mentioned in the previous section, it is an implementation detail. That means that acquiring the muxer should be done through either the SDK or the shared runtime installers. The only situation where this rule would not be true is if there was a major servicing event (e.g. a security update); in that case, the users would use the installer for the muxer directly, as we would rev its version accordingly.
The script installers are slightly different as they operate on zips/tarballs. The zip/tarball for the SDK will contain the entire set of things needed to be put on the disk.
## Removal process
Removing the bits from the machine **must** follow the order outlined above in installation. If the SDK is installed, it needs to be removed first and then the Redist and only then the muxer. Similar for the Redist.
## Upgrading the CLI
The semantics of installing the CLI will be side-by-side by default. This means that each new version will get installed besides any existing versions on disk. The [layout section](#layout-on-disk) covers how that will look like on disk.
Since this is the case, there is no special "upgrade". When the user needs a new version, the user just installs the new version using any of the installers specified in this document. The installer will just drop a new version at the predefined location.
This, however, does have one specific constraint: **newer versions must be installed in the same location the previous version was in**. This constraint is due to the fact that the "muxer" uses convention to figure out how to find the actual driver that the user reuqested.
## Layout on disk
```
<INSTALL_DIR>/ (%PATH%)
dotnet ("muxer", has platform dependant file extension)
hostfxr (implementation detail for "muxer", platform dependant file extension)
sdk/
<sdk-version-0>/ (i.e. "1.0.0-rc2-002543")
... (binaries like: dotnet.dll, csc.dll)
<sdk-version-1>/
... (binaries)
...
shared/ ("redist" or "shared framework")
<target-framework-name>/ (currently only "Microsoft.NETCore.App")
<redist-version-0>/ (i.e. "1.0.0-rc2-3002543")
... (binaries like: coreclr.dll, mscorlib.ni.dll, System.*.dll, dotnet-hostimpl.dll, dotnet, netcoreapp.deps.json)
<redist-version-1>/
... (binaries)
```
## Native dependencies
.NET Core CLI is built on top of CoreFX and CoreCLR and as such its' dependencies set is defined by the platform that those two combine. Whether or not those dependencies will be installed depends on the installer being used. The table below lists out the installers and whether or not they bring in dependencies.
| Installer | Dependencies Y/N |
|------------ |----------------------------------- |
| EXE | Y (chains them in) |
| PKG | N (need to be manually installed*) |
| apt-get | Y |
| rpm | Y |
`*` PKG cannot specify and automatically install native dependencies
A list of dependencies can be found on [dependency list](TBD).
## Channels
Channels represent a way for users who are getting the CLI to reason about the stability and quality of the bits they are getting. This is one more way for the user to be fully aware of the state the bits that are being installed are in and to set proper expectations on first use.
| Channel | Description |
|------------------ |------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| LTS | Latest long-term supported release. |
| Current | Most current release - typically 'preview' releases. |
## Funnels and discovery mechanisms for CLI bits
There are multiple ways that we will funnel users towards the installers for the CLI:
1. [Getting Started Page](https://aka.ms/dotnetcoregs)
2. [Repo landing page](../../README.md)
3. Package repositories for platforms (`apt-get`, `brew` etc.)
4. IDEs and editors that integrate with CLI (e.g. Visual Studio, VS Code, Sublime etc.)
Out of the above, the first two funnels are under the control of the CLI team so we will go into slightly more details. The rest of the funnels will use a prescribed way to get to the bits and will have guidance on what bits to use.
### Getting Started page
The page can be found on https://aka.ms/dotnetcoregs. This is the main curated first-run funnel for the dotnet CLI. The intent of the page is to help users test out the CLI quickly and become familiar with what the platform offers. This should be the most stable and curated experience we can offer.
The Getting Started page should only point users to curated install experiences that can contain only stable or LKG bits.
The below table shows other pertinent information for installs on the "Getting started" page.
| Property | Description |
|----------------------- |--------------------------------------------------------------- |
| Debian feed | Development |
| Brew repo/tap | Brew binary repo (https://github.com/Homebrew/homebrew-binary) |
| CentOS feed | TBD |
### Repo landing page
The repo landing page can be found on: [Repo landing page](../../README.md). Download links on the landing page should be decreased in importance. First thing for "you want to get started" section should link to the getting started page on the marketing site. The Repo Landing Page should be used primarily by contributors to the CLI. There should be a separate page that has instructions on how to install both the latest stable as well as latest development with proper warnings around it. The separate page is to really avoid the situation from people accidentally installing unstable bits (since search engines can drop them in the repo first).
The source branches and other items are actually branch specific for the repo landing page. As the user switches branches, the links and badges on the page will change to reflect the builds from that branch.
## Acquisition modes
There are multiple acquisition modes that the CLI will have:
1. Native installers
2. Install scripts
3. NuGet packages (for use in other people's commands/code)
4. Docker
Let's dig into some details.
### Native installers
These installation experiences are the primary way new users are getting the bits. The primary way to get information about this mode of installation is the [Getting Started page](#getting-started-page). The native installers are considered to be stable by default; this does not imply lack of bugs, but it does imply predictable behavior. They are generated from the stable branches and are never used to get the Future bits.
There are three main components that will be installed
The native installers are:
| Platform | Installer | Status | Package name |
|--------------------- |------------------ |---------- |-------------------- |
| Windows | Bundle installer | Done | dotnet-{version}; |
| Ubuntu 14.04/Debian | apt-get feed | Done | dotnet; dotnet-dbg |
| OS X | PKG | Done | dotnet |
| OS X | Homebrew | Not done | dotnet |
| CentOS/RH | RPM | Not done | dotnet |
### Installation script
This approach is a shell one-liner that downloads an installation script and runs it. The installation script will download the latest zip/tarball (depending on the script used) and will unpack it to a given location. After that, the script will print out what needs to be set for the entire CLI to work (env variables, $PATH modification etc.).
This install covers the following main scenario:
* Local installation on a dev machine
* Acquiring tools on a CI build server
The features the script needs to support/have are:
* Support for specifying the channel
* Support for specifying the version
* Support for specifying the installation location
* Automatically add the install to $PATH unless --no-path/-NoPath is present
It is recommended to use the stable version that is hosted on [.NET Core main website](https://dot.net). The direct path to the scripts are:
* https://dot.net/v1/dotnet-install.sh (bash, UNIX)
* https://dot.net/v1/dotnet-install.ps1 (powershell, Windows)
#### Installation script features
The following arguments are needed for the installation script:
| dotnet-install.sh arg (Linux, OSX) | dotnet-install.ps1 arg (Windows) | Defaults | Description |
|------------------------------------|----------------------------------|-----------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| --channel | -Channel | "LTS" | Which channel (i.e. "LTS", "Current", "1.0", "2.0", etc) to install from. |
| --version | -Version | Latest | Which version of CLI to install; you need to specify the version as 3-part version (i.e. 1.0.0-13232). The 'version' parameter supersedes the 'channel' parameter. |
| --install-dir | -InstallDir | .dotnet | Path to where to install the CLI bundle. The directory is created if it doesn't exist. On Linux/OSX this directory is created in the user home directory (`$HOME`). On Windows, this directory is created in `%LocalAppData%`. |
| --no-path | -NoPath | false | Do not export the installdir to the path for the current session. This makes CLI tools available immediately after install. |
| --shared-runtime | -SharedRuntime | false | Install just the shared runtime bits, not the entire SDK. |
| --architecture | -Architecture | Current OS (`<auto>`) | Architecture to install. The possible values are `<auto>`, `x64` and `x86`. |
| --dry-run | -DryRun | false | If set, it will not perform the installation but will show, on standard output, what the invocation of the script will do with the options selected. |
| --verbose | -Verbose | false | Display diagnostic information. |
| N/A | -ProxyAddress | "" | If set, the installer will use the specified proxy server for all of its invocations. |
> Note: Powershell arg naming convention is supported on Windows and non-Windows platforms. Non-Windows platforms do additionally support convention specific to their platform.
##### Install the 1.1.0 of the shared runtime
Windows:
```
./dotnet-install.ps1 -SharedRuntime -Version 1.1.0
```
macOS/Linux:
```
./dotnet-install.sh --shared-runtime --version 1.1.0
```
##### Install the latest supported CLI
Windows:
```
./dotnet-install.ps1 -Channel LTS
```
OSX/Linux:
```
./dotnet-install.sh --channel LTS
```
##### Install the latest CLI to specified location
Windows:
```
./dotnet-install.ps1 -Channel Current -InstallDir C:\cli
```
OSX/Linux:
```
./dotnet-install.sh --channel Current --install-dir ~/cli
```
##### Install the latest CLI in the 2.0 channel
Windows:
```
./dotnet-install.ps1 -Channel 2.0
```
OSX/Linux:
```
./dotnet-install.sh --channel 2.0
```
### Docker
[Docker](https://docs.docker.com/) has become a pretty good way to use developer tools, from trying them out in an interactive image use to using it for deployment. We have Docker images on DockerHub already.
Docker images should always be updated as we make new releases. We should have Docker images of stable releases, built from the release branches.
### NuGet packages
NuGet packages of the CLI bits that make sense are published to relevant feeds. The developer who wishes to use these needs to specify a version. The actual "installation" here is restoring the package as a dependency for a certain project (i.e. `ProjectServer` or similar).
## Acquiring through other products
### IDEs and editors
Anything that goes into the higher-level tools should always use a stable build of CLI coming frol release branches as required.
If there exist any mechanism that notifies users of updates of the CLI, it should ideally point users to the Getting Started page to acquire the installers, or, if that is deemed too heavy-handed, it should point people to the last stable release. If there is a need of the URL to be "baked in" to the higher-level tool, that URL should be an aka.ms URL because it needs to be stable on that end.
Cross-platform IDEs/editors will work in similar way as above. The notification should also point people to the Getting Started page. The reason is simple: it is the one page where users can pick and choose their installation experience.
### Visual Studio
Visual Studio will not be shipping CLI in-box. However, it will use CLI when installed. The install will be tied into other installs like WET and similar. The URL that is baked in VS should be an aka.ms URL or other stable URL/location.
# Detecting dotnet/cli installation
## Windows
### Requirements for CLI SDK and shared framework installer
- Support side by side installation and can be compatible with older versions of themselves
- Supports removing of any side by side version
- Prerelease versions are compatible only with the same prerelease versions
#### Scenarios
- Installing the product produces registry value informing about full version of the product which is being installed
- Installing the product produces registry values informing about compatible versions of the products
- Removing the product removes the registry keys if none of the versions of the product is supporting the given version. Specifically at least one registry key with full version should be removed.
- Installing older version of the product is possible
#### Registry keys and values
- Full version refers to NuGet semantic version which contains the build number
- Version refers to NuGet semantic version which does *not* contain build number
Registry key should be created under following path:
```
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\dotnet\Setup\InstalledVersions\<platform>\<installer-name>\[REG_DWORD]<nuget-version>=1
```
`<platform>=(x86|x64)`
`<installer-name>=(sdk|sharedfx)`
Example output (installing CLI SDK x86 with version 1.0.3-123456):
```
HKLM\SOFTWARE\WOW6432Node\dotnet\Setup\InstalledVersions\x86\sdk\[REG_DWORD]1.0.0=1
HKLM\SOFTWARE\WOW6432Node\dotnet\Setup\InstalledVersions\x86\sdk\[REG_DWORD]1.0.1=1
HKLM\SOFTWARE\WOW6432Node\dotnet\Setup\InstalledVersions\x86\sdk\[REG_DWORD]1.0.2=1
HKLM\SOFTWARE\WOW6432Node\dotnet\Setup\InstalledVersions\x86\sdk\[REG_DWORD]1.0.3=1
HKLM\SOFTWARE\WOW6432Node\dotnet\Setup\InstalledVersions\x86\sdk\[REG_DWORD]1.0.3-123456=1
```
Note: 1.0.3 has two entries
Explanation:
CLI SDK version 1.0.3-123456 is compatible with any build of 1.0.3, 1.0.2, 1.0.1 and 1.0.0. If another installer is trying to find if there exists CLI SDK which supports specific version of installer they can check for presence of the value 1 under the registry path.
### Requirements for shared host installer
- Supports only in-place updated and is assumed to be always compatible with older versions of itself
#### Scenarios
- Installing the product produces one registry value containing the latest version
- Installing older version on top of the other is not possible
- Removing removes the product completely with its registry keys, regardless of any previous installations
Registry key should be created under following path:
```
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\dotnet\Setup\InstalledVersions\<platform>\[REG_SZ]sharedhost=<nuget-semversion>
```
##### Example
```
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\dotnet\Setup\x64\[REG_SZ]sharedhost=1.0.0-rc2-123456
```
### Other Examples
Operations:
`NOP` - key already existed, do nothing with it
`ADD` - add
`DEL` - delete
`RF+` - not adding because key already exist (installer will increse ref count on GUID related to this value)
`RF-` - not deleting because something else is compatible with this (decrease ref count)
#### Scenario 1
Installing 1.0.3-123456 (RTM) to a clean machine
Note: Installer is compatible with all previous versions and all their RCs.
```
ADD HKLM\SOFTWARE\WOW6432Node\dotnet\Setup\InstalledVersions\x86\sdk\[REG_DWORD]1.0.0-rc1=1
ADD HKLM\SOFTWARE\WOW6432Node\dotnet\Setup\InstalledVersions\x86\sdk\[REG_DWORD]1.0.0-rc2=1
ADD HKLM\SOFTWARE\WOW6432Node\dotnet\Setup\InstalledVersions\x86\sdk\[REG_DWORD]1.0.0=1
ADD HKLM\SOFTWARE\WOW6432Node\dotnet\Setup\InstalledVersions\x86\sdk\[REG_DWORD]1.0.1-rc1=1
ADD HKLM\SOFTWARE\WOW6432Node\dotnet\Setup\InstalledVersions\x86\sdk\[REG_DWORD]1.0.1-rc2=1
ADD HKLM\SOFTWARE\WOW6432Node\dotnet\Setup\InstalledVersions\x86\sdk\[REG_DWORD]1.0.1=1
ADD HKLM\SOFTWARE\WOW6432Node\dotnet\Setup\InstalledVersions\x86\sdk\[REG_DWORD]1.0.2-rc1=1
ADD HKLM\SOFTWARE\WOW6432Node\dotnet\Setup\InstalledVersions\x86\sdk\[REG_DWORD]1.0.2-rc2=1
ADD HKLM\SOFTWARE\WOW6432Node\dotnet\Setup\InstalledVersions\x86\sdk\[REG_DWORD]1.0.2=1
ADD HKLM\SOFTWARE\WOW6432Node\dotnet\Setup\InstalledVersions\x86\sdk\[REG_DWORD]1.0.3-rc1=1
ADD HKLM\SOFTWARE\WOW6432Node\dotnet\Setup\InstalledVersions\x86\sdk\[REG_DWORD]1.0.3-rc2=1
ADD HKLM\SOFTWARE\WOW6432Node\dotnet\Setup\InstalledVersions\x86\sdk\[REG_DWORD]1.0.3=1
ADD HKLM\SOFTWARE\WOW6432Node\dotnet\Setup\InstalledVersions\x86\sdk\[REG_DWORD]1.0.3-123456=1
```
Installing 1.0.4-234567 (RTM) on top of that
```
RF+ HKLM\SOFTWARE\WOW6432Node\dotnet\Setup\InstalledVersions\x86\sdk\[REG_DWORD]1.0.0-rc1=1
RF+ HKLM\SOFTWARE\WOW6432Node\dotnet\Setup\InstalledVersions\x86\sdk\[REG_DWORD]1.0.0-rc2=1
RF+ HKLM\SOFTWARE\WOW6432Node\dotnet\Setup\InstalledVersions\x86\sdk\[REG_DWORD]1.0.0=1
RF+ HKLM\SOFTWARE\WOW6432Node\dotnet\Setup\InstalledVersions\x86\sdk\[REG_DWORD]1.0.1-rc1=1
RF+ HKLM\SOFTWARE\WOW6432Node\dotnet\Setup\InstalledVersions\x86\sdk\[REG_DWORD]1.0.1-rc2=1
RF+ HKLM\SOFTWARE\WOW6432Node\dotnet\Setup\InstalledVersions\x86\sdk\[REG_DWORD]1.0.1=1
RF+ HKLM\SOFTWARE\WOW6432Node\dotnet\Setup\InstalledVersions\x86\sdk\[REG_DWORD]1.0.2-rc1=1
RF+ HKLM\SOFTWARE\WOW6432Node\dotnet\Setup\InstalledVersions\x86\sdk\[REG_DWORD]1.0.2-rc2=1
RF+ HKLM\SOFTWARE\WOW6432Node\dotnet\Setup\InstalledVersions\x86\sdk\[REG_DWORD]1.0.2=1
RF+ HKLM\SOFTWARE\WOW6432Node\dotnet\Setup\InstalledVersions\x86\sdk\[REG_DWORD]1.0.3-rc1=1
RF+ HKLM\SOFTWARE\WOW6432Node\dotnet\Setup\InstalledVersions\x86\sdk\[REG_DWORD]1.0.3-rc2=1
RF+ HKLM\SOFTWARE\WOW6432Node\dotnet\Setup\InstalledVersions\x86\sdk\[REG_DWORD]1.0.3=1
NOP HKLM\SOFTWARE\WOW6432Node\dotnet\Setup\InstalledVersions\x86\sdk\[REG_DWORD]1.0.3-123456=1
ADD HKLM\SOFTWARE\WOW6432Node\dotnet\Setup\InstalledVersions\x86\sdk\[REG_DWORD]1.0.4-rc1=1
ADD HKLM\SOFTWARE\WOW6432Node\dotnet\Setup\InstalledVersions\x86\sdk\[REG_DWORD]1.0.4-rc2=1
ADD HKLM\SOFTWARE\WOW6432Node\dotnet\Setup\InstalledVersions\x86\sdk\[REG_DWORD]1.0.4=1
ADD HKLM\SOFTWARE\WOW6432Node\dotnet\Setup\InstalledVersions\x86\sdk\[REG_DWORD]1.0.4-234567=1
```
Removing 1.0.3-123456
```
RF- HKLM\SOFTWARE\WOW6432Node\dotnet\Setup\InstalledVersions\x86\sdk\[REG_DWORD]1.0.0-rc1=1
RF- HKLM\SOFTWARE\WOW6432Node\dotnet\Setup\InstalledVersions\x86\sdk\[REG_DWORD]1.0.0-rc2=1
RF- HKLM\SOFTWARE\WOW6432Node\dotnet\Setup\InstalledVersions\x86\sdk\[REG_DWORD]1.0.0=1
RF- HKLM\SOFTWARE\WOW6432Node\dotnet\Setup\InstalledVersions\x86\sdk\[REG_DWORD]1.0.1-rc1=1
RF- HKLM\SOFTWARE\WOW6432Node\dotnet\Setup\InstalledVersions\x86\sdk\[REG_DWORD]1.0.1-rc2=1
RF- HKLM\SOFTWARE\WOW6432Node\dotnet\Setup\InstalledVersions\x86\sdk\[REG_DWORD]1.0.1=1
RF- HKLM\SOFTWARE\WOW6432Node\dotnet\Setup\InstalledVersions\x86\sdk\[REG_DWORD]1.0.2-rc1=1
RF- HKLM\SOFTWARE\WOW6432Node\dotnet\Setup\InstalledVersions\x86\sdk\[REG_DWORD]1.0.2-rc2=1
RF- HKLM\SOFTWARE\WOW6432Node\dotnet\Setup\InstalledVersions\x86\sdk\[REG_DWORD]1.0.2=1
RF- HKLM\SOFTWARE\WOW6432Node\dotnet\Setup\InstalledVersions\x86\sdk\[REG_DWORD]1.0.3-rc1=1
RF- HKLM\SOFTWARE\WOW6432Node\dotnet\Setup\InstalledVersions\x86\sdk\[REG_DWORD]1.0.3-rc2=1
RF- HKLM\SOFTWARE\WOW6432Node\dotnet\Setup\InstalledVersions\x86\sdk\[REG_DWORD]1.0.3=1
DEL HKLM\SOFTWARE\WOW6432Node\dotnet\Setup\InstalledVersions\x86\sdk\[REG_DWORD]1.0.3-123456=1
NOP HKLM\SOFTWARE\WOW6432Node\dotnet\Setup\InstalledVersions\x86\sdk\[REG_DWORD]1.0.4-rc1=1
NOP HKLM\SOFTWARE\WOW6432Node\dotnet\Setup\InstalledVersions\x86\sdk\[REG_DWORD]1.0.4-rc2=1
NOP HKLM\SOFTWARE\WOW6432Node\dotnet\Setup\InstalledVersions\x86\sdk\[REG_DWORD]1.0.4=1
NOP HKLM\SOFTWARE\WOW6432Node\dotnet\Setup\InstalledVersions\x86\sdk\[REG_DWORD]1.0.4-234567=1
```
#### Scenario 2
Installing 1.0.0-123456 (RTM) to a clean machine
```
ADD HKLM\SOFTWARE\WOW6432Node\dotnet\Setup\InstalledVersions\x86\sdk\[REG_DWORD]1.0.0-rc1=1
ADD HKLM\SOFTWARE\WOW6432Node\dotnet\Setup\InstalledVersions\x86\sdk\[REG_DWORD]1.0.0-rc2=1
ADD HKLM\SOFTWARE\WOW6432Node\dotnet\Setup\InstalledVersions\x86\sdk\[REG_DWORD]1.0.0=1
ADD HKLM\SOFTWARE\WOW6432Node\dotnet\Setup\InstalledVersions\x86\sdk\[REG_DWORD]1.0.0-123456=1
```
Installing 1.1.0-567890 (RTM) which is incompatible since 1.0.2
Note: User is unable to run apps targeting 1.0.1 or 1.0.2 until compatible version is installed.
```
NOP HKLM\SOFTWARE\WOW6432Node\dotnet\Setup\InstalledVersions\x86\sdk\[REG_DWORD]1.0.0-rc1=1
NOP HKLM\SOFTWARE\WOW6432Node\dotnet\Setup\InstalledVersions\x86\sdk\[REG_DWORD]1.0.0-rc2=1
NOP HKLM\SOFTWARE\WOW6432Node\dotnet\Setup\InstalledVersions\x86\sdk\[REG_DWORD]1.0.0=1
NOP HKLM\SOFTWARE\WOW6432Node\dotnet\Setup\InstalledVersions\x86\sdk\[REG_DWORD]1.0.0-123456=1
ADD HKLM\SOFTWARE\WOW6432Node\dotnet\Setup\InstalledVersions\x86\sdk\[REG_DWORD]1.0.3-rc1=1 (first back-incompatible version)
ADD HKLM\SOFTWARE\WOW6432Node\dotnet\Setup\InstalledVersions\x86\sdk\[REG_DWORD]1.0.3-rc2=1
ADD HKLM\SOFTWARE\WOW6432Node\dotnet\Setup\InstalledVersions\x86\sdk\[REG_DWORD]1.0.3=1
ADD HKLM\SOFTWARE\WOW6432Node\dotnet\Setup\InstalledVersions\x86\sdk\[REG_DWORD]1.0.4-rc1=1
ADD HKLM\SOFTWARE\WOW6432Node\dotnet\Setup\InstalledVersions\x86\sdk\[REG_DWORD]1.0.4-rc2=1
ADD HKLM\SOFTWARE\WOW6432Node\dotnet\Setup\InstalledVersions\x86\sdk\[REG_DWORD]1.0.4=1
ADD HKLM\SOFTWARE\WOW6432Node\dotnet\Setup\InstalledVersions\x86\sdk\[REG_DWORD]1.1.0-rc1=1
ADD HKLM\SOFTWARE\WOW6432Node\dotnet\Setup\InstalledVersions\x86\sdk\[REG_DWORD]1.1.0-rc2=1
ADD HKLM\SOFTWARE\WOW6432Node\dotnet\Setup\InstalledVersions\x86\sdk\[REG_DWORD]1.1.0=1
ADD HKLM\SOFTWARE\WOW6432Node\dotnet\Setup\InstalledVersions\x86\sdk\[REG_DWORD]1.1.0-567890=1
```
#### Scenario 3
Installing 1.0.0-rc2-123456 to a clean machine
Note: User is unable to run apps targeting 1.0.0 until RTM is installed.
```
ADD HKLM\SOFTWARE\WOW6432Node\dotnet\Setup\InstalledVersions\x86\sdk\[REG_DWORD]1.0.0-rc1=1
ADD HKLM\SOFTWARE\WOW6432Node\dotnet\Setup\InstalledVersions\x86\sdk\[REG_DWORD]1.0.0-rc2=1
ADD HKLM\SOFTWARE\WOW6432Node\dotnet\Setup\InstalledVersions\x86\sdk\[REG_DWORD]1.0.0-rc2-123456=1
```
Installing 1.0.1-rc1-234567
Note: User is still unable to run apps targeting 1.0.0 until any 1.0.0+ RTM is installed.
```
NOP HKLM\SOFTWARE\WOW6432Node\dotnet\Setup\InstalledVersions\x86\sdk\[REG_DWORD]1.0.0-rc1=1
NOP HKLM\SOFTWARE\WOW6432Node\dotnet\Setup\InstalledVersions\x86\sdk\[REG_DWORD]1.0.0-rc2=1
NOP HKLM\SOFTWARE\WOW6432Node\dotnet\Setup\InstalledVersions\x86\sdk\[REG_DWORD]1.0.0-rc2-123456=1
ADD HKLM\SOFTWARE\WOW6432Node\dotnet\Setup\InstalledVersions\x86\sdk\[REG_DWORD]1.0.1-rc1=1
ADD HKLM\SOFTWARE\WOW6432Node\dotnet\Setup\InstalledVersions\x86\sdk\[REG_DWORD]1.0.1-rc1-123456=1
```

101
Documentation/specs/corehost.md
View file

@ -1,101 +0,0 @@
# corehost runtime/assembly resolution
The shared host locates assemblies and native libraries using a combination of: Servicing Index, Files in the application folder (aka "app-local") and files from package caches.
## Definitions and Formats
### Terms/Notes
* The term "Library" (Title Case) is used throughout this document to refer to a NuGet Package. We use this term because it is used in the code to represent multiple things: Packages, Projects and Framework Assemblies are all types of "Library".
* All of the assembly resolution here refers to setting up the default assembly load context for the runtime. Further dynamic loads (plugins, etc.) can still have custom resolution logic provided by using an `AssemblyLoadContext` in the managed code. Essentially, we are setting up the necessary assemblies to launch the `Program.Main` (and all the assemblies that are statically-referenced by that).
### Servicing Index
The servicing index is loaded when the `DOTNET_SERVICING` environment variable is non-empty. When this variable is non-empty, it points to a directory that will be the **Servicing Root**. There may be platform-specific default locations, to be determined later.
An index file is located at the path defined by `$DOTNET_SERVICING/servicing_index.txt`. In this file are a series of lines of one of the following formats:
```
# Lines starting with a '#' and blank lines are ignored.
# Identifies an asset from a NuGet Package that has been serviced.
package|[Package ID]|[Package Version]|[Original Asset Relative Path]=[New Asset Path, relative to Servicing Root]
package|System.Threading.Thread|1.2.3.4|lib/dotnet5.4/System.Threading.Thread.dll=patches/abc123/System.Threading.Thread.dll
# TBD: Host/Runtime servicing entries.
```
Paths in this file are **always** specified using `/`, even on Windows. They must be converted to platform-specific directory separators.
This index is loaded when needed during the Resolution Process (see below).
### Runtime Configuration File
The runtime configuration file is used to determine settings to apply to the runtime during initialization and for building the TPA and Native Library Search Path lists. See the [spec for the runtime configuration file](runtime-configuration-file.md) for more information.
### Files in the application folder
Any file with the suffix `.dll` in the same folder as the managed application being loaded (the "Application Base") will be considered a viable assembly during the resolution process. The host **assumes** that the assembly's short name is the same as the file name with the `.dll` suffix removed (yes, this is not technically required by the CLR, but we assume it for use with this host).
### Files from package caches
Only assemblies listed in the dependencies file can be resolved from a package cache. To resolve those assemblies, two environment variables are used:
* `DOTNET_PACKAGES` - The primary package cache. If not set, defaults to `$HOME/.nuget/packages` on Unix or `%LOCALAPPDATA%\NuGet\Packages` (TBD) on Windows. **NOTE**: Currently the host uses different folders as we are still coordinating with NuGet to get the directories right (there are compatability considerations). Currently we always use `$HOME/.dnx/packages`(Unix)/`%USERPROFILE%\.dnx\packages`(Win).
* `DOTNET_PACKAGES_CACHE` - The secondary cache. This is used by shared hosts (such as Azure) to provide a cache of pre-downloaded common packages on a faster disk. If not set, it is not used.
Given the Package ID, Package Version, Package Hash and Asset Relative Path provided in the runtime configuration file, **and the assembly is not serviced** (see the full resolution algorithm below) resolution proceeds as follows (Unix-style paths will be used for convenience but these variables and paths all apply to Windows as well):
1. If `DOTNET_PACKAGES_CACHE` is non-empty, read the file `$DOTNET_PACKAGES_CACHE/[Package ID]/[Package Version]/[Package Id].[Package Version].nupkg.sha512` if present. If the file is present and the content matches the `[Package Hash]` value from the dependencies file. Use that location as the Package Root and go to 3
2. Using `DOTNET_PACKAGES`, or it's default value, use `$DOTNET_PACKAGES/[Package ID]/[Package Version]` as the Package Root
3. Concatenate the Package Root and the Asset Relative Path. This is the path to the asset (managed assembly or native library).
## Assembly Resolution
During host start-up, the host identifies if a runtime configuration file is present and loads it. It also scans the files located in the Application Base and determines the assembly name for each (using the file name). It builds a set of assembly names to be loaded by the union of the assembly names listed in runtime configuration file and the assemblies located in the Application Base.
A runtime configuration file is **not** required to successfully launch an application, but without it, all the dependent assemblies must be located within the same folder as the application. Also, since servicing is performed on the basis of packages, an application without a runtime configuration file file cannot use the servicing index to override the location of assemblies.
The host looks for the `.deps` file in the Application Base with the file name `[AssemblyName].deps`. The path to the deps file can be overridden by specifying `--depsfile:{path to deps file}` as the first parameter to the application.
Given the set of assembly names, the host performs the following resolution. In some steps, the Package ID/Version/Relative Path data is required. This is only available if the assembly was listed in the deps file. If the assembly comes from the app-local folder, these resolution steps are skipped.
1. If there is an entry in the servicing index for the Package ID/Version/Relative Path associated with the assembly, the Servicing Root is concatenated with the New Asset Path from the index and used as the Assembly Path. This occurs **even if the assembly is also located app-local**, as long as it is also in the runtime configuration file.
2. If there is a file in the Application Base with the file name `[AssemblyName].dll`, `[AssemblyName].ni.dll`, `[AssemblyName].exe`, or `[AssemblyName].ni.exe` (in that order), it its full path is used as the Assembly Path
3. The Assembly Path is resolved out of the Package Caches using the algorithm above (in 'Files from package caches').
A similar process is used to produce a list of Native Library Paths. Native libraries are listed in the runtime configuration file (under the `native` asset section) and searched in the same way as managed assemblies (Servicing, then app-local, then package caches). The main exception is that the app-local file extensions vary by platform (`.dll` on Windows, `.so` on Linux, `.dylib` on Mac OS X)
Once a the list of assemblies and native libraries is produced, the host will check for duplicates. If both an `.ni.dll`/`.ni.exe` image and a `.dll`/`.exe` assembly are found for an assembly, the native image will be preferred and the IL-only assembly will be removed. The presence of two different paths for the same assembly name will be considered an error. The managed assemblies are provided in the Trusted Platform Assemblies (TPA) list for the CoreCLR during startup. The folder paths for each native library are deduplicated and provided in the Native Search Paths list for the CoreCLR during startup.
**NOTE**: The CLR may add support for providing a similar structure as the TPA list for native libraries (i.e. a flat list of full file paths).
### Satellite Assemblies
Satellite Assemblies (assemblies containing only embedded resources used in place of the resources provided by an assembly) are detected by path convention in the host. The convention will be to look at the last two segments of the path (the file name and the immediate parent directory name). If the parent directory matches an [IETF Language Tag](https://en.wikipedia.org/wiki/IETF_language_tag) (or more specifically, a value usable in the Culture field for a CLR Assembly Name), then the assembly is considered culture-specific (for the culture specified in that folder name). Upon determining this, the host will place the culture-neutral assemblies on the TPA list and provide the directories containing the assemblies as Platform Resource Roots to the CLR to allow it to locate the assemblies.
## Runtime Resolution
Runtime resolution is controlled by these environment variables:
* `DOTNET_RUNTIME_SERVICING` -> Global override for runtime
* `DOTNET_PACKAGES_CACHE` -> Secondary cache
* `DOTNET_PACKAGES` -> Package restore location
The runtime is located by searching the following paths in order, where `APP_BASE` refers to the directory containing the managed application assembly and `LIBCORECLR` refers to the platform-specific name for the CoreCLR library (`libcoreclr.so` on Unix, `libcoreclr.dylib` on Mac OS X, `coreclr.dll` on Windows). The first path that matches is used as the path to load the CoreCLR from.
* `$DOTNET_RUNTIME_SERVICING/runtime/coreclr/LIBCORECLR`
* `$DOTNET_PACKAGES_CACHE/<Package Id>/<Package Version>/runtimes/<RID>/native/LICORECLR`
* `APP_BASE/LIBCORECLR`
* `$DOTNET_PACKAGES/<Package Id>/<Package Version>/runtimes/<RID>/native/LIBCORECLR`
* On Unix:
* `/usr/local/share/dotnet/runtime/coreclr/LIBCORECLR` [1]
* `/usr/share/dotnet/runtime/coreclr/LIBCORECLR`
* On Windows:
* `%LocalAppData%\dotnet\runtime\coreclr\LIBCORECLR`
* `%ProgramFiles%\dotnet\runtime\coreclr\LIBCORECLR` [2]
Notes:
1. The Unix paths should be this way but are reversed in the actual code. Generally `/usr/local` is considered to have higher precedence than `/usr`
2. Not yet implemented.

391
Documentation/specs/runtime-configuration-file.md
View file

@ -1,391 +0,0 @@
# Runtime Configuration Files
The runtime configuration files store the dependencies of an application (formerly stored in the `.deps` file). They also include runtime configuration options, such as the Garbage Collector mode. Optionally they can also include data for runtime compilation (compilation settings used to compile the original application, and reference assemblies used by the application).
**Note:** This document doesn't provide full explanations as to why individual items are needed in this file. That is covered in the [`corehost` spec](corehost.md) and via the `Microsoft.Extensions.DependencyModel` assembly.
## What produces the files and where are they?
There are two runtime configuration files for a particular application. Given a project named `MyApp`, the compilation process produces the following files (on Windows, other platforms are similar):
* `MyApp.dll` - The managed assembly for `MyApp`, including an ECMA-compliant entry point token.
* `MyApp.exe` - A copy of the `corehost.exe` executable.
* `MyApp.runtimeconfig.json` - An **optional** configuration file containing runtime configuration settings.
* `MyApp.deps.json` - A list of dependencies, as well as compilation context data and compilation dependencies. Not technically required, but required to use the servicing or package cache/shared package install features.
The `MyApp.runtimeconfig.json` is designed to be user-editable (in the case of an app consumer wanting to change various CLR runtime options for an app, much like the `MyApp.exe.config` XML file works in .NET 4.x today). However, the `MyApp.deps.json` file is designed to be processed by automated tools and should not be user-edited. Having the files as separate makes this clearer. We could use a different format for the deps file, but if we're already integrating a JSON parser into the host, it seems most appropriate to re-use that here. Also, there are diagnostic benefits to being able to read the `.deps.json` file in a simple text editor.
**IMPORTANT**: Portable Applications, i.e. those published without a specific RID, have some adjustments to this spec which is covered at the end.
## File format
The files are both JSON files stored in UTF-8 encoding. Below are sample files. Note that not all sections are required and some will be opt-in only (see below for more details). The `.runtimeconfig.json` file is completely optional, and in the `.deps.json` file, only the `runtimeTarget`, `targets` and `libraries` sections are required (and within the `targets` section, only the runtime-specific target is required).
### [appname].runtimeconfig.json
```json
{
"runtimeOptions": {
"configProperties": {
"System.GC.Server": true,
"System.GC.Concurrent": true,
"System.Threading.ThreadPool.MinThreads": 4,
"System.Threading.ThreadPool.MaxThreads": 8
},
"framework": {
"name": "Microsoft.DotNetCore",
"version": "1.0.1"
},
"applyPatches": false
}
}
```
### [appname].deps.json
```json
{
"runtimeTarget": ".NETStandardApp,Version=v1.5/osx.10.10-x64",
"compilationOptions": {
"defines": [ "DEBUG" ]
},
"targets": {
".NETStandardApp,Version=v1.5": {
"MyApp/1.0": {
"type": "project",
"dependencies": {
"AspNet.Mvc": "1.0.0"
}
},
"System.Foo/1.0.0": {
"type": "package",
},
"System.Banana/1.0.0": {
"type": "package",
"dependencies": {
"System.Foo": "1.0.0"
},
"compile": {
"ref/dotnet5.4/System.Banana.dll": { }
}
}
},
".NETStandardApp,Version=v1.5/osx.10.10-x64": {
"MyApp/1.0": {
"type": "project",
"dependencies": {
"AspNet.Mvc": "1.0.0"
}
},
"System.Foo/1.0.0": {
"type": "package",
"runtime": {
"lib/dnxcore50/System.Foo.dll": { }
}
},
"System.Banana/1.0.0": {
"type": "package",
"dependencies": {
"System.Foo": "1.0.0"
},
"runtime": {
"lib/dnxcore50/System.Banana.dll": { }
},
"resources": {
"lib/dnxcore50/fr-FR/System.Banana.resources.dll": { "locale": "fr-FR" }
},
"native": {
"runtimes/osx.10.10-x64/native/libbananahelper.dylib": { }
}
}
}
},
"libraries": {
"MyApp/1.0": {
"type": "project"
},
"System.Foo/1.0": {
"type": "package",
"serviceable": true,
"sha512": "[base64 string]"
},
"System.Banana/1.0": {
"type": "package",
"sha512": "[base64 string]"
}
}
}
```
## Sections
### `runtimeOptions` Section (`.runtimeconfig.json`)
This section is copied verbatim from an identical section in the input `project.json` file (with the exception of the `target` parameter which is generated by the compilation process). The `runtimeConfig` section specifies parameters to be provided to the runtime during initialization. Known parameters include:
* `configProperties` - Indicates configuration properties to configure the runtime and the framework
* Examples:
* Full list of [configuration properties](https://github.com/dotnet/coreclr/blob/master/Documentation/project-docs/clr-configuration-knobs.md) for CoreCLR.
* `System.GC.Server` (old: `gcServer`) - Boolean indicating if the server GC should be used (Default: `true`).
* `System.GC.Concurrent` (old: `gcConcurrent`) - Boolean indicating if background garbage collection should be used.
* `framework` - Indicates the `name`, `version`, and other properties of the shared framework to use when activating the application. The presence of this section indicates that the application is a portable app designed to use a shared redistributable framework.
* `applyPatches` - When `false`, the framework version is strictly obeyed by the host. When `applyPatches` is unspecified or specified as `true`, the framework from either the same or a higher version that differs only in the `SemVer` patch field will be used.
* For example, if `version=1.0.1` and `applyPatches` is `true`, the host would load the shared framework from `1.0.{n}`, where `n >= 1`, but will not load from `1.1.0`, even if present. When `applyPatches` is `false`, the shared framework will be loaded from `1.0.1` strictly.
* **Note:** This does not apply to `SemVer`'s `prerelease` versions, but only for `production` releases.
* **Note:** This section will not be used for standalone applications that do not rely upon a shared framework.
* Others _TBD_
These settings are read by `corehost` to determine how to initialize the runtime. All versions of `corehost` **must ignore** settings in this section that they do not understand (thus allowing new settings to be added in later versions).
### `compilationOptions` Section (`.deps.json`)
This section is copied by storing the merged `compilationOptions` from the input `project.json`. The `project.json` can define three sets of compilation options: Global, Per-Configuration, and Per-Framework. However, the `[appname].runtimeconfig.json` is specific to a configuration and framework so there is only one merged section here.
The exact settings found here are specific to the compiler that produced the original application binary. Some example settings include: `defines`, `languageVersion` (C#/VB), `allowUnsafe` (C#), etc.
As an example, here is a possible `project.json` file:
```json
{
"compilationOptions": {
"allowUnsafe": true
},
"frameworks": {
"net451": {
"compilationOptions": {
"defines": [ "DESKTOP_CLR" ]
}
},
"dnxcore50": {
"compilationOptions": {
"defines": [ "CORE_CLR" ]
}
}
},
"configurations": {
"Debug": {
"compilationOptions": {
"defines": [ "DEBUG_MODE" ]
}
}
}
}
```
When this project is built for `dnxcore50` in the `Debug` configuration, the outputted `MyApp.deps.json` file will have the following `compilationOptions` section:
```json
{
"compilationOptions": {
"allowUnsafe": true,
"defines": [ "CORE_CLR", "DEBUG_MODE" ]
}
}
```
### `runtimeTarget` Section (`.deps.json`)
This property contains the name of the target from `targets` that should be used by the runtime. This is present to simplify `corehost` so that it does not have to parse or understand target names and the meaning thereof.
### `targets` Section (`.deps.json`)
This section contains subsetted data from the input `project.lock.json`.
Each property under `targets` describes a "target", which is a collection of libraries required by the application when run or compiled in a certain framework and platform context. A target **must** specify a Framework name, and **may** specify a Runtime Identifier. Targets without Runtime Identifiers represent the dependencies and assets used for compiling the application for a particular framework. Targets with Runtime Identifiers represent the dependencies and assets used for running the application under a particular framework and on the platform defined by the Runtime Identifier. In the example above, the `.NETStandardApp,Version=v1.5` target lists the dependencies and assets used to compile the application for `dnxcore50`, and the `.NETStandardApp,Version=v1.5/osx.10.10-x64` target lists the dependencies and assets used to run the application on `dnxcore50` on a 64-bit Mac OS X 10.10 machine.
There will always be two targets in the `[appname].runtimeconfig.json` file: A compilation target, and a runtime target. The compilation target will be named with the framework name used for the compilation (`.NETStandardApp,Version=v1.5` in the example above). The runtime target will be named with the framework name and runtime identifier used to execute the application (`.NETStandardApp,Version=v1.5/osx.10.10-x64` in the example above). However, the runtime target will also be identified by name in the `runtimeOptions` section, so that `corehost` need not parse and understand target names.
The content of each target property in the JSON is a JSON object. Each property of that JSON object represents a single dependency required by the application when compiled for/run on that target. The name of the property contains the ID and Version of the dependency in the form `[Id]/[Version]`. The content of the property is another JSON object containing metadata about the dependency.
The `type` property of a dependency object defines what kind of entity satisfied the dependency. Possible values include `project` and `package` (further comments on dependency types below).
**Open Question:** `type` is also present in the `libraries` section. We don't really need it in both. It's in both now because the lock file does that and we want the formats to be similar. Should we remove it?
The `dependencies` property of a dependency object defines the ID and Version of direct dependencies of this node. It is a JSON object where the property names are the ID of the dependency and the content of each property is the Version of the dependency.
The `runtime` property of a dependency object lists the relative paths to Managed Assemblies required to be available at runtime in order to satisfy this dependency. The paths are relative to the location of the Dependency (see below for further details on locating a dependency).
The `resources` property of a dependency object lists the relative paths and locales of Managed Satellite Assemblies which provide resources for other languages. Each item contains a `locale` property specifying the [IETF Language Tag](https://en.wikipedia.org/wiki/IETF_language_tag) for the satellite assembly (or more specifically, a value usable in the Culture field for a CLR Assembly Name).
The `native` property of a dependency object lists the relative paths to Native Libraries required to be available at runtime in order to satisfy this dependency. The paths are relative to the location of the Dependency (see below for further details on locating a dependency).
In compilation targets, the `runtime`, `resources` and `native` properties of a dependency are omitted, because they are not relevant to compilation. Similarly, in runtime targets, the `compile` property is omitted, because it is not relevant to runtime.
Only dependencies with a `type` value of `package` should be considered by `corehost`. There may be other items, used for other purposes (for example, Projects, Reference Assemblies, etc.
### `libraries` Section (`.deps.json`)
This section contains a union of all the dependencies found in the various targets, and contains common metadata for them. Specifically, it contains the `type`, as well as a boolean indicating if the library can be serviced (`serviceable`, only for `package`-typed libraries) and a SHA-512 hash of the package file (`sha512`, only for `package`-typed libraries.
## How the file is used
The file is read by two different components:
* `corehost` uses it to determine what to place on the TPA and Native Library Search Path lists, as well as what runtime settings to apply (GC type, etc.). See [the `corehost` spec](corehost.md).
* `Microsoft.Extensions.DependencyModel` uses it to allow a running managed application to query various data about it's dependencies. For example:
* To find all dependencies that depend on a particular package (used by ASP.NET MVC and other plugin-based systems to identify assemblies that should be searched for possible plugin implementations)
* To determine the reference assemblies used by the application when it was compiled in order to allow runtime compilation to use the same reference assemblies (used by ASP.NET Razor to compile views)
* To determine the compilation settings used by the application in order to allow runtime compilation to use the same settings (also used by ASP.NET Razor views).
## Opt-In Compilation Data
Some of the sections in the `.deps.json` file contain data used for runtime compilation. This data is not provided in the file by default. Instead, a project.json setting `preserveCompilationContext` must be set to true in order to ensure this data is added. Without this setting, the `compilationOptions` will not be present in the file, and the `targets` section will contain only the runtime target. For example, if the `preserveCompilationContext` setting was not present in the `project.json` that generated the above example, the `.deps.json` file would only contain the following content:
```json
{
"runtimeTarget": {
"name": ".NETStandardApp,Version=v1.5/osx.10.10-x64",
"portable": false
},
"targets": {
".NETStandardApp,Version=v1.5/osx.10.10-x64": {
"MyApp/1.0": {
"dependencies": {
"AspNet.Mvc": "1.0.0"
}
},
"System.Foo/1.0.0": {
"runtime": {
"lib/dnxcore50/System.Foo.dll": { }
}
},
"System.Banana/1.0.0": {
"dependencies": {
"System.Foo": "1.0.0"
},
"runtime": {
"lib/dnxcore50/System.Banana.dll": { }
},
"resources": {
"lib/dnxcore50/fr-FR/System.Banana.resources.dll": { "locale": "fr-FR" }
},
"native": {
"runtimes/osx.10.10-x64/native/libbananahelper.dylib": { }
}
}
}
},
"libraries": {
"MyApp/1.0": {
"type": "project"
},
"System.Foo/1.0": {
"type": "package",
"serviceable": true,
"sha512": "[base64 string]"
},
"System.Banana/1.0": {
"type": "package",
"sha512": "[base64 string]"
}
}
}
```
## Portable Deployment Model
An application can be deployed in a "portable" deployment model. In this case, the RID-specific assets of packages are published within a folder structure that preserves the RID metadata. However, `corehost` does not use this folder structure, rather it reads data from the `.deps.json` file. Also, during deployment, the `.exe` file (`corehost` renamed) is not deployed.
In the portable deployment model, the `*.runtimeConfig.json` file will contain the `runtimeOptions.framework` section:
```json
{
"runtimeOptions": {
"framework": {
"name": "NETCore.App",
"version": "1.0.1"
}
}
}
```
This data is used to locate the shared framework folder. The exact mechanics of which version are selected are defined elsewhere, but in general, it locates the shared runtime in the `shared` folder located beside it by using the relative path `shared/[runtimeOptions.framework.name]/[runtimeOptions.framework.version]`. Once it has applied any version roll-forward logic and come to a final path to the shared framework, it locates the `[runtimeOptions.framework.name].deps.json` file within that folder and loads it **first**.
Next, the deps file from the application is loaded and merged into this deps file (this is conceptual, the host implementation doesn't necessary have to directly merge the data ;)). Data from the app-local deps file trumps data from the shared framework.
The shared framework's deps file will also contain a `runtimes` section defining the fallback logic for all RIDs known to that shared framework. For example, a shared framework deps file installed into a Ubuntu machine may look something like the following:
```json
{
"runtimeTarget": {
"name": ".NETStandardApp,Version=v1.5",
"portable": false
},
"targets": {
".NETStandardApp,Version=v1.5": {
"System.Runtime/4.0.0": {
"runtime": "lib/netstandard1.5/System.Runtime.dll"
},
"... other libraries ...": {}
}
},
"libraries": {
"System.Runtime/4.0.0": {
"type": "package",
"serviceable": true,
"sha512": "[base64 string]"
},
"... other libraries ...": {}
},
"runtimes": {
"ubuntu.15.04-x64": [ "ubuntu.14.10-x64", "ubuntu.14.04-x64", "debian.8-x64", "linux-x64", "linux", "unix", "any", "base" ],
"ubuntu.14.10-x64": [ "ubuntu.14.04-x64", "debian.8-x64", "linux-x64", "linux", "unix", "any", "base" ],
"ubuntu.14.04-x64": [ "debian.8-x64", "linux-x64", "linux", "unix", "any", "base" ]
}
}
```
The host will have a RID embedded in it during compilation (for example, `win10-x64` for Windows 64-bit). It will look up the corresponding entry in the `runtimes` section to identify what the fallback list is for `win10-x64`. The fallbacks are identified from most-specific to least-specific. In the case of `win10-x64` and the example above, the fallback list is: `"win10-x64", "win10", "win81-x64", "win81", "win8-x64", "win8", "win7-x64", "win7", "win-x64", "win", "any", "base"` (note that an exact match on the RID itself is the first preference, followed by the first item in the fallback list, then the next item, and so on).
In the app-local deps file for a `portable` application, the package entries may have an additional `runtimeTargets` section detailing RID-specific assets. The `corehost` application should use this data, along with the current RID and the RID fallback data defined in the `runtimes` section of the shared framework deps file to select one **and only one** RID value out of each package individually. The most specific RID present within the package should always be selected.
Consider `corehost` built for `ubuntu.14.04-x64` and the following snippet from an app-local deps file (some sections removed for brevity).
```json
{
"targets": {
".NETStandardApp,Version=v1.5": {
"System.Data.SqlClient/4.0.0": {
"compile": {
"ref/netstandard1.5/System.Data.SqlClient.dll": {}
},
"runtimeTargets": {
"runtimes/unix/lib/netstandard1.5/System.Data.SqlClient.dll": {
"assetType": "runtime",
"rid": "unix"
},
"runtimes/win7-x64/lib/netstandard1.5/System.Data.SqlClient.dll": {
"assetType": "runtime",
"rid": "win7-x64"
},
"runtimes/win7-x86/lib/netstandard1.5/System.Data.SqlClient.dll": {
"assetType": "runtime",
"rid": "win7-x86"
},
"runtimes/win7-x64/native/sni.dll": {
"assetType": "native",
"rid": "win7-x64"
},
"runtimes/win7-x86/native/sni.dll": {
"assetType": "native",
"rid": "win7-x86"
}
}
}
}
}
}
```
When setting up the TPA and native library lists, it will do the following for the `System.Data.SqlClient` entry in the example above:
1. Add all entries from the root `runtime` and `native` sections (not present in the example). (Note: This is essentially the current behavior for the existing deps file format)
2. Add all appropriate entries from the `runtimeTargets` section, based on the `rid` property of each item:
1. Attempt to locate any item for the RID `ubuntu.14.04-x64`. If any asset is matched, take **only** the items matching that RID exactly and add them to the appropriate lists based on the `assetType` value (`runtime` for managed code, `native` for native code)
2. Reattempt the previous step using the first RID in the list provided by the list in the `runtimes."ubuntu.14.04-x64"` section of the shared framework deps file. If any asset is matched, take **only** the items matching that RID exactly and add them to the appropriate lists
3. Continue to reattempt the previous search for each RID in the list, from left to right until a match is found or the list is exhausted. Exhausting the list without finding an asset, when a `runtimeTargets` section is present is **not** an error, it simply indicates that there is no need for a runtime-specific asset for that package.
Note one important aspect about asset resolution: The resolution scope is **per-package**, **not per-application**, **nor per-asset**. For each individual package, the most appropriate RID is selected, and **all** assets taken from that package must match the selected RID exactly. For example, if a package provides both a `linux-x64` and a `unix` RID (in the `ubuntu.14.04-x64` example above), **only** the `linux-x64` asset would be selected for that package. However, if a different package provides only a `unix` RID, then the asset from the `unix` RID would be selected.
The path to a runtime-specific asset is resolved in the same way as a normal asset (first check Servicing, then Package Cache, App-Local, Global Packages Location, etc.) with **one exception**. When searching app-local, rather than just looking for the simple file name in the app-local directory, a runtime-specific asset is expected to be located in a subdirectory matching the relative path information for that asset in the lock file. So the `native` `sni.dll` asset for `win7-x64` in the `System.Data.SqlClient` example above would be located at `APPROOT/runtimes/win7-x64/native/sni.dll`, rather than the normal app-local path of `APPROOT/sni.dll`.

17
ISSUE_TEMPLATE
View file

@ -1,17 +0,0 @@
## Steps to reproduce
## Expected behavior
## Actual behavior
## Environment data
`dotnet --info` output:

7
NuGet.master.config
View file

@ -1,7 +0,0 @@
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<packageSources>
<clear />
<add key="NuGet" value="https://api.nuget.org/v3/index.json" />
</packageSources>
</configuration>

0
TestAssets/DesktopTestProjects/AppWithProjTool2Fx/.noautobuild
View file

23
TestAssets/DesktopTestProjects/AppWithProjTool2Fx/App.csproj
View file

@ -1,23 +0,0 @@
<Project Sdk="Microsoft.NET.Sdk" ToolsVersion="15.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Import Project="$([MSBuild]::GetDirectoryNameOfFileAbove($(MSBuildThisFileDirectory), testAsset.props))\testAsset.props" />
<PropertyGroup>
<TargetFrameworks>netcoreapp2.0;net451</TargetFrameworks>
<OutputType>Exe</OutputType>
<AssetTargetFallback Condition=" '$(TargetFramework)' == 'netcoreapp2.0' ">$(AssetTargetFallback);portable-net45+win8;dnxcore50</AssetTargetFallback>
<RuntimeIdentifiers>win7-x64;win7-x86;osx.10.10-x64;osx.10.11-x64;ubuntu.14.04-x64;ubuntu.16.04-x64;ubuntu.16.10-x64;centos.7-x64;rhel.7.2-x64;debian.8-x64;fedora.24-x64;opensuse.42.1-x64</RuntimeIdentifiers>
<RestoreAdditionalProjectSources Condition="'$(TEST_PACKAGES)' != ''">$(TEST_PACKAGES)</RestoreAdditionalProjectSources>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="dotnet-desktop-and-portable" Version="1.0.0-*" />
</ItemGroup>
<ItemGroup Condition=" '$(TargetFramework)' == 'net451' ">
<Reference Include="System" />
<Reference Include="Microsoft.CSharp" />
</ItemGroup>
<ItemGroup>
<DotNetCliToolReference Include="dotnet-dependency-tool-invoker" Version="1.0.0-*" />
</ItemGroup>
</Project>

15
TestAssets/DesktopTestProjects/AppWithProjTool2Fx/Program.cs
View file

@ -1,15 +0,0 @@
// Copyright (c) .NET Foundation and contributors. All rights reserved.
// Licensed under the MIT license. See LICENSE file in the project root for full license information.
using System;
namespace ConsoleApplication
{
public class Program
{
public static void Main(string[] args)
{
Console.WriteLine("Hello World!");
}
}
}

30
TestAssets/DesktopTestProjects/BindingRedirectSample/AppWithRedirectsAndConfig/AppWithRedirectsAndConfig.csproj
View file

@ -1,30 +0,0 @@
<Project Sdk="Microsoft.NET.Sdk" ToolsVersion="15.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<TargetFramework>net46</TargetFramework>
<AssemblyName>AppWithRedirectsAndConfig</AssemblyName>
<OutputType>Exe</OutputType>
<RuntimeIdentifiers>win7-x64;win7-x86</RuntimeIdentifiers>
<RestoreAdditionalProjectSources Condition="'$(TEST_PACKAGES)' != ''">$(TEST_PACKAGES)</RestoreAdditionalProjectSources>
</PropertyGroup>
<ItemGroup>
<Compile Include="..\src\*.cs" Exclude="bin\**;obj\**;**\*.xproj;packages\**" />
</ItemGroup>
<ItemGroup>
<PackageReference Include="Newtonsoft.Json" Version="8.0.3" />
<PackageReference Include="Microsoft.AspNet.Mvc" Version="3.0.50813.1" />
<PackageReference Include="Unity.Mvc" Version="3.0.1304" />
<PackageReference Include="dotnet-desktop-binding-redirects" Version="1.0.0-*" />
</ItemGroup>
<ItemGroup Condition=" '$(TargetFramework)' == 'net46' ">
<Reference Include="System" />
<Reference Include="Microsoft.CSharp" />
</ItemGroup>
<ItemGroup>
<DotNetCliToolReference Include="dotnet-dependency-tool-invoker" Version="1.0.0-*" />
</ItemGroup>
</Project>

20
TestAssets/DesktopTestProjects/BindingRedirectSample/AppWithRedirectsAndConfig/app.config
View file

@ -1,20 +0,0 @@
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral" />
<bindingRedirect oldVersion="3.5.0.0" newVersion="8.0.0.0" />
<bindingRedirect oldVersion="4.5.0.0" newVersion="8.0.0.0" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="Some.Foo.Assembly" publicKeyToken="814f48568d36eed5" culture="neutral" />
<bindingRedirect oldVersion="3.0.0.0" newVersion="5.5.5.1" />
</dependentAssembly>
</assemblyBinding>
</runtime>
<appSettings>
<add key="Setting1" value="Hello"/>
<add key="Setting2" value="World"/>
</appSettings>
</configuration>

30
TestAssets/DesktopTestProjects/BindingRedirectSample/AppWithRedirectsNoConfig/AppWithRedirectsNoConfig.csproj
View file

@ -1,30 +0,0 @@
<Project Sdk="Microsoft.NET.Sdk" ToolsVersion="15.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<TargetFramework>net46</TargetFramework>
<AssemblyName>AppWithRedirectsNoConfig</AssemblyName>
<OutputType>Exe</OutputType>
<RuntimeIdentifiers>win7-x64;win7-x86</RuntimeIdentifiers>
<RestoreAdditionalProjectSources Condition="'$(TEST_PACKAGES)' != ''">$(TEST_PACKAGES)</RestoreAdditionalProjectSources>
</PropertyGroup>
<ItemGroup>
<Compile Include="..\src\*.cs" Exclude="bin\**;obj\**;**\*.xproj;packages\**" />
</ItemGroup>
<ItemGroup>
<PackageReference Include="Newtonsoft.Json" Version="8.0.3" />
<PackageReference Include="Microsoft.AspNet.Mvc" Version="3.0.50813.1" />
<PackageReference Include="Unity.Mvc" Version="3.0.1304" />
<PackageReference Include="dotnet-desktop-binding-redirects" Version="1.0.0-*" />
</ItemGroup>
<ItemGroup Condition=" '$(TargetFramework)' == 'net46' ">
<Reference Include="System" />
<Reference Include="Microsoft.CSharp" />
</ItemGroup>
<ItemGroup>
<DotNetCliToolReference Include="dotnet-dependency-tool-invoker" Version="1.0.0-*" />
</ItemGroup>
</Project>

52
TestAssets/DesktopTestProjects/BindingRedirectSample/src/Program.cs
View file

@ -1,52 +0,0 @@
// Copyright (c) .NET Foundation and contributors. All rights reserved.
// Licensed under the MIT license. See LICENSE file in the project root for full license information.
using System;
using System.Collections.Generic;
using System.Diagnostics;
using System.Linq;
using System.Reflection;
namespace BindingRedirects
{
public class Program
{
private const string ExpectedNewtonSoftVersion = "8.0.0.0";
public static int Main(string[] args)
{
return VerifyJsonLoad();
}
private static int VerifyJsonLoad()
{
WriteLine("=======Verifying Redirected Newtonsoft.Json assembly load=======");
int result = 0;
try
{
var jsonAsm = typeof(Newtonsoft.Json.JsonConvert).Assembly;
var version = jsonAsm.GetName().Version.ToString();
if (version != ExpectedNewtonSoftVersion)
{
WriteLine($"Failure - Newtonsoft.Json: ExpectedVersion - {ExpectedNewtonSoftVersion}, ActualVersion - {version}");
result = -1;
}
}
catch (Exception ex)
{
WriteLine($"Failed to load type 'Newtonsoft.Json.JsonConvert'");
throw ex;
}
return result;
}
private static void WriteLine(string str)
{
var currentAssembly = Assembly.GetExecutingAssembly().GetName().Name;
Console.WriteLine($"{currentAssembly}: {str}");
}
}
}

0
TestAssets/DesktopTestProjects/DesktopAppWithNativeDep/.noautobuild
View file

14
TestAssets/DesktopTestProjects/DesktopAppWithNativeDep/Program.cs
View file

@ -1,14 +0,0 @@
// Copyright (c) .NET Foundation and contributors. All rights reserved.
// Licensed under the MIT license. See LICENSE file in the project root for full license information.
using System;
namespace DesktopAppWithNativeDep
{
public static class Program
{
public static void Main(string[] args)
{
}
}
}

13
TestAssets/DesktopTestProjects/DesktopAppWithNativeDep/project.json
View file

@ -1,13 +0,0 @@
{
"version": "1.0.0-*",
"dependencies": {
"PackageWithFakeNativeDep": "1.0.0-*",
"Microsoft.NETCore.Platforms": "1.0.1"
},
"buildOptions": {
"emitEntryPoint": true
},
"frameworks": {
"net451": {}
}
}

0
TestAssets/DesktopTestProjects/DesktopAppWithRuntimes/.noautobuild
View file

14
TestAssets/DesktopTestProjects/DesktopAppWithRuntimes/Program.cs
View file

@ -1,14 +0,0 @@
// Copyright (c) .NET Foundation and contributors. All rights reserved.
// Licensed under the MIT license. See LICENSE file in the project root for full license information.
using System;
namespace DesktopAppWithRuntimes
{
public static class Program
{
public static void Main(string[] args)
{
}
}
}

15
TestAssets/DesktopTestProjects/DesktopAppWithRuntimes/project.json
View file

@ -1,15 +0,0 @@
{
"version": "1.0.0-*",
"dependencies": {
"Microsoft.NETCore.Windows.ApiSets": "1.0.1-rc3-24206-00"
},
"buildOptions": {
"emitEntryPoint": true
},
"frameworks": {
"net451": {}
},
"runtimes": {
"win7-x64": {}
}
}

0
TestAssets/DesktopTestProjects/DesktopKestrelSample/KestrelDesktop/.noautobuild
View file

20
TestAssets/DesktopTestProjects/DesktopKestrelSample/KestrelDesktop/project.json
View file

@ -1,20 +0,0 @@
{
"version": "1.0.0-*",
"dependencies": {
"Microsoft.AspNetCore.Server.Kestrel": "1.0.0-rc2-20113",
"Microsoft.AspNetCore.Hosting": "1.0.0-rc2-20113",
"Microsoft.Extensions.Logging.Console": "1.0.0-rc2-20254",
"Microsoft.NETCore.Platforms": "1.0.1"
},
"buildOptions": {
"emitEntryPoint": true,
"compile": {
"include": [
"../src/*.cs"
]
}
},
"frameworks": {
"net451": {}
}
}

0
TestAssets/DesktopTestProjects/DesktopKestrelSample/KestrelDesktopForce32/.noautobuild
View file

21
TestAssets/DesktopTestProjects/DesktopKestrelSample/KestrelDesktopForce32/project.json
View file

@ -1,21 +0,0 @@
{
"version": "1.0.0-*",
"dependencies": {
"Microsoft.AspNetCore.Server.Kestrel": "1.0.0-rc2-20113",
"Microsoft.AspNetCore.Hosting": "1.0.0-rc2-20113",
"Microsoft.Extensions.Logging.Console": "1.0.0-rc2-20254",
"Microsoft.NETCore.Platforms": "1.0.1"
},
"buildOptions": {
"platform": "anycpu32bitpreferred",
"emitEntryPoint": true,
"compile": {
"include": [
"../src/*.cs"
]
}
},
"frameworks": {
"net451": {}
}
}

0
TestAssets/DesktopTestProjects/DesktopKestrelSample/KestrelDesktopWithRuntimes/.noautobuild
View file

25
TestAssets/DesktopTestProjects/DesktopKestrelSample/KestrelDesktopWithRuntimes/project.json
View file

@ -1,25 +0,0 @@
{
"version": "1.0.0-*",
"dependencies": {
"Microsoft.AspNetCore.Server.Kestrel": "1.0.0-rc2-20113",
"Microsoft.AspNetCore.Hosting": "1.0.0-rc2-20113",
"Microsoft.Extensions.Logging.Console": "1.0.0-rc2-20254",
"Microsoft.NETCore.Platforms": "1.0.1"
},
"buildOptions": {
"emitEntryPoint": true,
"compile": {
"include": [
"../src/*.cs"
]
}
},
"frameworks": {
"net451": {}
},
"runtimes": {
"win7-x86": {},
"win7-x64": {},
"osx.10.11-x64": {}
}
}

88
TestAssets/DesktopTestProjects/DesktopKestrelSample/src/Startup.cs
View file

@ -1,88 +0,0 @@
// Licensed to the .NET Foundation under one or more agreements.
// The .NET Foundation licenses this file to you under the MIT license.
// See the LICENSE file in the project root for more information.
using System;
using System.IO;
using System.Security.Cryptography.X509Certificates;
using System.Threading;
using System.Threading.Tasks;
using Microsoft.AspNetCore.Builder;
using Microsoft.AspNetCore.Hosting;
using Microsoft.AspNetCore.Http;
using Microsoft.AspNetCore.Server.Kestrel;
using Microsoft.AspNetCore.Server.Kestrel.Filter;
using Microsoft.Extensions.Logging;
namespace SampleApp
{
public class Startup
{
private static string Args { get; set; }
private static CancellationTokenSource ServerCancellationTokenSource { get; set; }
public void Configure(IApplicationBuilder app, ILoggerFactory loggerFactory)
{
var ksi = app.ServerFeatures.Get<IKestrelServerInformation>();
ksi.NoDelay = true;
loggerFactory.AddConsole(LogLevel.Error);
app.UseKestrelConnectionLogging();
app.Run(async context =>
{
Console.WriteLine("{0} {1}{2}{3}",
context.Request.Method,
context.Request.PathBase,
context.Request.Path,
context.Request.QueryString);
Console.WriteLine($"Method: {context.Request.Method}");
Console.WriteLine($"PathBase: {context.Request.PathBase}");
Console.WriteLine($"Path: {context.Request.Path}");
Console.WriteLine($"QueryString: {context.Request.QueryString}");
var connectionFeature = context.Connection;
Console.WriteLine($"Peer: {connectionFeature.RemoteIpAddress?.ToString()} {connectionFeature.RemotePort}");
Console.WriteLine($"Sock: {connectionFeature.LocalIpAddress?.ToString()} {connectionFeature.LocalPort}");
var content = $"Hello world!{Environment.NewLine}Received '{Args}' from command line.";
context.Response.ContentLength = content.Length;
context.Response.ContentType = "text/plain";
await context.Response.WriteAsync(content);
});
}
public static int Main(string[] args)
{
if (args.Length == 0)
{
Console.WriteLine("KestrelHelloWorld <url to host>");
return 1;
}
var url = new Uri(args[0]);
Args = string.Join(" ", args);
var host = new WebHostBuilder()
.UseServer("Microsoft.AspNetCore.Server.Kestrel")
.UseUrls(url.ToString())
.UseStartup<Startup>()
.Build();
ServerCancellationTokenSource = new CancellationTokenSource();
// shutdown server after 20s.
var shutdownTask = Task.Run(async () =>
{
await Task.Delay(20000);
ServerCancellationTokenSource.Cancel();
});
host.Run(ServerCancellationTokenSource.Token);
shutdownTask.Wait();
return 0;
}
}
}

0
TestAssets/DesktopTestProjects/LibWithProjTool2Fx/.noautobuild
View file

20
TestAssets/DesktopTestProjects/LibWithProjTool2Fx/Lib.csproj
View file

@ -1,20 +0,0 @@
<Project Sdk="Microsoft.NET.Sdk" ToolsVersion="15.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<TargetFrameworks>netstandard1.6;net451</TargetFrameworks>
<OutputType>Library</OutputType>
<AssetTargetFallback Condition=" '$(TargetFramework)' == 'netstandard1.6' ">$(AssetTargetFallback);portable-net45+win8;dnxcore50;netcoreapp2.0</AssetTargetFallback>
<RestoreAdditionalProjectSources Condition="'$(TEST_PACKAGES)' != ''">$(TEST_PACKAGES)</RestoreAdditionalProjectSources>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="dotnet-desktop-and-portable" Version="1.0.0-*" />
</ItemGroup>
<ItemGroup Condition=" '$(TargetFramework)' == 'net451' ">
<Reference Include="System" />
<Reference Include="Microsoft.CSharp" />
</ItemGroup>
<ItemGroup>
<DotNetCliToolReference Include="dotnet-dependency-tool-invoker" Version="1.0.0-*" />
</ItemGroup>
</Project>

15
TestAssets/DesktopTestProjects/LibWithProjTool2Fx/Program.cs
View file

@ -1,15 +0,0 @@
// Copyright (c) .NET Foundation and contributors. All rights reserved.
// Licensed under the MIT license. See LICENSE file in the project root for full license information.
using System;
namespace ConsoleApplication
{
public class Program
{
public static void Main(string[] args)
{
Console.WriteLine("Hello World!");
}
}
}

24
TestAssets/DesktopTestProjects/MultiTFMXunitProject/TestLibrary/Helper.cs
View file

@ -1,24 +0,0 @@
// Copyright (c) .NET Foundation and contributors. All rights reserved.
// Licensed under the MIT license. See LICENSE file in the project root for full license information.
using System;
namespace TestLibrary
{
public static class Helper
{
/// <summary>
/// Gets the message from the helper. This comment is here to help test XML documentation file generation, please do not remove it.
/// </summary>
/// <returns>A message</returns>
public static string GetMessage()
{
return "This string came from the test library!";
}
public static void SayHi()
{
Console.WriteLine("Hello there!");
}
}
}

7
TestAssets/DesktopTestProjects/MultiTFMXunitProject/TestLibrary/TestLibrary.csproj
View file

@ -1,7 +0,0 @@
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>netstandard2.0</TargetFramework>
</PropertyGroup>
</Project>

24
TestAssets/DesktopTestProjects/MultiTFMXunitProject/XUnitProject/UnitTest1.cs
View file

@ -1,24 +0,0 @@
// Copyright (c) .NET Foundation and contributors. All rights reserved.
// Licensed under the MIT license. See LICENSE file in the project root for full license information.
using System;
using TestLibrary;
using Xunit;
namespace TestNamespace
{
public class VSTestXunitTests
{
[Fact]
public void VSTestXunitPassTest()
{
Assert.Equal("This string came from the test library!", Helper.GetMessage());
}
[Fact]
public void VSTestXunitFailTest()
{
Assert.Equal(2, 2);
}
}
}

17
TestAssets/DesktopTestProjects/MultiTFMXunitProject/XUnitProject/XUnitProject.csproj
View file

@ -1,17 +0,0 @@
<Project Sdk="Microsoft.NET.Sdk" ToolsVersion="15.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Import Project="$([MSBuild]::GetDirectoryNameOfFileAbove($(MSBuildThisFileDirectory), testAsset.props))\testAsset.props" />
<PropertyGroup>
<TargetFrameworks>net461;netcoreapp2.0</TargetFrameworks>
</PropertyGroup>
<ItemGroup>
<ProjectReference Include="../TestLibrary/TestLibrary.csproj" />
</ItemGroup>
<ItemGroup>
<PackageReference Include="Microsoft.NET.Test.Sdk" Version="$(CLI_TestPlatform_Version)" />
<PackageReference Include="xunit" Version="2.2.0-beta4-build3444" />
<PackageReference Include="xunit.runner.visualstudio" Version="2.2.0-beta4-build1194" />
</ItemGroup>
</Project>

0
TestAssets/DesktopTestProjects/TestAppWithFrameworkAssemblies/ProjectA/.noautobuild
View file

19
TestAssets/DesktopTestProjects/TestAppWithFrameworkAssemblies/ProjectA/Program.cs
View file

@ -1,19 +0,0 @@
// Copyright (c) .NET Foundation and contributors. All rights reserved.
// Licensed under the MIT license. See LICENSE file in the project root for full license information.
using System;
using System.Diagnostics;
using TestLibrary;
namespace TestApp
{
public class Program
{
public static int Main(string[] args)
{
Console.WriteLine("This string came from ProjectA");
Console.WriteLine($"{ProjectD.GetMessage()}");
return 0;
}
}
}

34
TestAssets/DesktopTestProjects/TestAppWithFrameworkAssemblies/ProjectA/project.json
View file

@ -1,34 +0,0 @@
{
"version": "1.0.0-*",
"buildOptions": {
"emitEntryPoint": true,
"preserveCompilationContext": true
},
"dependencies": {
"ProjectB": {
"target": "project",
"version": "1.0.0-*"
}
},
"frameworks": {
"netcoreapp1.1": {
"dependencies": {
"Microsoft.NETCore.App": "1.1.0"
}
},
"net451": {}
},
"runtimes": {
"win7-x64": {},
"win7-x86": {},
"osx.10.10-x64": {},
"osx.10.11-x64": {},
"ubuntu.14.04-x64": {},
"ubuntu.16.04-x64": {},
"centos.7-x64": {},
"rhel.7.2-x64": {},
"debian.8-x64": {},
"fedora.23-x64": {},
"opensuse.13.2-x64": {}
}
}

0
TestAssets/DesktopTestProjects/TestAppWithFrameworkAssemblies/ProjectB/.noautobuild
View file

15
TestAssets/DesktopTestProjects/TestAppWithFrameworkAssemblies/ProjectB/Helper.cs
View file

@ -1,15 +0,0 @@
// Copyright (c) .NET Foundation and contributors. All rights reserved.
// Licensed under the MIT license. See LICENSE file in the project root for full license information.
using System;
namespace TestLibrary
{
public static class ProjectB
{
public static string GetMessage()
{
return "This string came from ProjectB";
}
}
}

23
TestAssets/DesktopTestProjects/TestAppWithFrameworkAssemblies/ProjectB/project.json
View file

@ -1,23 +0,0 @@
{
"version": "1.0.0-*",
"buildOptions": {
"nowarn": [
"CS1591"
],
"xmlDoc": true,
"additionalArguments": [
"-highentropyva+"
]
},
"dependencies": {
"NETStandard.Library": "1.6.0"
},
"frameworks": {
"netstandard1.5": {},
"net451": {
"frameworkAssemblies": {
"System.ComponentModel.DataAnnotations": ""
}
}
}
}

25
TestAssets/LockFiles/ExportFiles/invalid_missing-exports/project.fragment.lock.json
View file

@ -1,25 +0,0 @@
{
"version": 2,
"exports": {
"ClassLibrary2/1.0.0": {
"type": "project",
"framework": ".NETFramework,Version=v4.6",
"compile": {
"bin/Debug/ClassLibrary2.dll": {}
},
"runtime": {
"bin/Debug/ClassLibrary2.dll": {}
}
},
"ClassLibrary3/1.0.0": {
"type": "project",
"framework": ".NETFramework,Version=v4.6",
"compile": {
"bin/Debug/ClassLibrary3.dll": {}
},
"runtime": {
"bin/Debug/ClassLibrary3.dll": {}
}
}
}
}

21
TestAssets/LockFiles/ExportFiles/invalid_missing-exports/project.json
View file

@ -1,21 +0,0 @@
{
"version": "1.0.0-*",
"buildOptions": {
"emitEntryPoint": true
},
"frameworks": {
"net46": {
"dependencies": {
"ClassLibrary1": {
"target": "project"
},
"ClassLibrary2": {
"target": "project"
},
"ClassLibrary3": {
"target": "project"
}
}
}
}
}

61
TestAssets/LockFiles/ExportFiles/invalid_missing-exports/project.lock.json
View file

@ -1,61 +0,0 @@
{
"locked": false,
"version": 2,
"targets": {
".NETFramework,Version=v4.6": {
"ClassLibrary1/1.0.0": {
"type": "project"
},
"ClassLibrary2/1.0.0": {
"type": "project"
},
"ClassLibrary3/1.0.0": {
"type": "project"
}
},
".NETFramework,Version=v4.6/win7-x64": {
"ClassLibrary1/1.0.0": {
"type": "project"
},
"ClassLibrary2/1.0.0": {
"type": "project"
},
"ClassLibrary3/1.0.0": {
"type": "project"
}
},
".NETFramework,Version=v4.6/win7-x86": {
"ClassLibrary1/1.0.0": {
"type": "project"
},
"ClassLibrary2/1.0.0": {
"type": "project"
},
"ClassLibrary3/1.0.0": {
"type": "project"
}
}
},
"libraries": {
"ClassLibrary1/1.0.0": {
"type": "project",
"msbuildProject": "../../ClassLibrary1/ClassLibrary1.csproj"
},
"ClassLibrary2/1.0.0": {
"type": "project",
"msbuildProject": "../../ClassLibrary2/ClassLibrary2.csproj"
},
"ClassLibrary3/1.0.0": {
"type": "project",
"msbuildProject": "../../ClassLibrary3/ClassLibrary3.csproj"
}
},
"projectFileDependencyGroups": {
"": [],
".NETFramework,Version=v4.6": [
"ClassLibrary1",
"ClassLibrary2",
"ClassLibrary3"
]
}
}

35
TestAssets/LockFiles/ExportFiles/invalid_missmatching-versions/project.fragment.lock.json
View file

@ -1,35 +0,0 @@
{
"version": 3,
"exports": {
"ClassLibrary1/1.0.0": {
"type": "project",
"framework": ".NETFramework,Version=v4.5.2",
"compile": {
"bin/Debug/ClassLibrary1.dll": {}
},
"runtime": {
"bin/Debug/ClassLibrary1.dll": {}
}
},
"ClassLibrary2/1.0.0": {
"type": "project",
"framework": ".NETFramework,Version=v4.6",
"compile": {
"bin/Debug/ClassLibrary2.dll": {}
},
"runtime": {
"bin/Debug/ClassLibrary2.dll": {}
}
},
"ClassLibrary3/1.0.0": {
"type": "project",
"framework": ".NETFramework,Version=v4.6",
"compile": {
"bin/Debug/ClassLibrary3.dll": {}
},
"runtime": {
"bin/Debug/ClassLibrary3.dll": {}
}
}
}
}

21
TestAssets/LockFiles/ExportFiles/invalid_missmatching-versions/project.json
View file

@ -1,21 +0,0 @@
{
"version": "1.0.0-*",
"buildOptions": {
"emitEntryPoint": true
},
"frameworks": {
"net46": {
"dependencies": {
"ClassLibrary1": {
"target": "project"
},
"ClassLibrary2": {
"target": "project"
},
"ClassLibrary3": {
"target": "project"
}
}
}
}
}

61
TestAssets/LockFiles/ExportFiles/invalid_missmatching-versions/project.lock.json
View file

@ -1,61 +0,0 @@
{
"locked": false,
"version": 2,
"targets": {
".NETFramework,Version=v4.6": {
"ClassLibrary1/1.0.0": {
"type": "project"
},
"ClassLibrary2/1.0.0": {
"type": "project"
},
"ClassLibrary3/1.0.0": {
"type": "project"
}
},
".NETFramework,Version=v4.6/win7-x64": {
"ClassLibrary1/1.0.0": {
"type": "project"
},
"ClassLibrary2/1.0.0": {
"type": "project"
},
"ClassLibrary3/1.0.0": {
"type": "project"
}
},
".NETFramework,Version=v4.6/win7-x86": {
"ClassLibrary1/1.0.0": {
"type": "project"
},
"ClassLibrary2/1.0.0": {
"type": "project"
},
"ClassLibrary3/1.0.0": {
"type": "project"
}
}
},
"libraries": {
"ClassLibrary1/1.0.0": {
"type": "project",
"msbuildProject": "../../ClassLibrary1/ClassLibrary1.csproj"
},
"ClassLibrary2/1.0.0": {
"type": "project",
"msbuildProject": "../../ClassLibrary2/ClassLibrary2.csproj"
},
"ClassLibrary3/1.0.0": {
"type": "project",
"msbuildProject": "../../ClassLibrary3/ClassLibrary3.csproj"
}
},
"projectFileDependencyGroups": {
"": [],
".NETFramework,Version=v4.6": [
"ClassLibrary1",
"ClassLibrary2",
"ClassLibrary3"
]
}
}

21
TestAssets/LockFiles/ExportFiles/invalid_nofragment/project.json
View file

@ -1,21 +0,0 @@
{
"version": "1.0.0-*",
"buildOptions": {
"emitEntryPoint": true
},
"frameworks": {
"net46": {
"dependencies": {
"ClassLibrary1": {
"target": "project"
},
"ClassLibrary2": {
"target": "project"
},
"ClassLibrary3": {
"target": "project"
}
}
}
}
}

61
TestAssets/LockFiles/ExportFiles/invalid_nofragment/project.lock.json
View file

@ -1,61 +0,0 @@
{
"locked": false,
"version": 2,
"targets": {
".NETFramework,Version=v4.6": {
"ClassLibrary1/1.0.0": {
"type": "project"
},
"ClassLibrary2/1.0.0": {
"type": "project"
},
"ClassLibrary3/1.0.0": {
"type": "project"
}
},
".NETFramework,Version=v4.6/win7-x64": {
"ClassLibrary1/1.0.0": {
"type": "project"
},
"ClassLibrary2/1.0.0": {
"type": "project"
},
"ClassLibrary3/1.0.0": {
"type": "project"
}
},
".NETFramework,Version=v4.6/win7-x86": {
"ClassLibrary1/1.0.0": {
"type": "project"
},
"ClassLibrary2/1.0.0": {
"type": "project"
},
"ClassLibrary3/1.0.0": {
"type": "project"
}
}
},
"libraries": {
"ClassLibrary1/1.0.0": {
"type": "project",
"msbuildProject": "../../ClassLibrary1/ClassLibrary1.csproj"
},
"ClassLibrary2/1.0.0": {
"type": "project",
"msbuildProject": "../../ClassLibrary2/ClassLibrary2.csproj"
},
"ClassLibrary3/1.0.0": {
"type": "project",
"msbuildProject": "../../ClassLibrary3/ClassLibrary3.csproj"
}
},
"projectFileDependencyGroups": {
"": [],
".NETFramework,Version=v4.6": [
"ClassLibrary1",
"ClassLibrary2",
"ClassLibrary3"
]
}
}

35
TestAssets/LockFiles/ExportFiles/valid/project.fragment.lock.json
View file

@ -1,35 +0,0 @@
{
"version": 2,
"exports": {
"ClassLibrary1/1.0.0": {
"type": "project",
"framework": ".NETFramework,Version=v4.5.2",
"compile": {
"bin/Debug/ClassLibrary1.dll": {}
},
"runtime": {
"bin/Debug/ClassLibrary1.dll": {}
}
},
"ClassLibrary2/1.0.0": {
"type": "project",
"framework": ".NETFramework,Version=v4.6",
"compile": {
"bin/Debug/ClassLibrary2.dll": {}
},
"runtime": {
"bin/Debug/ClassLibrary2.dll": {}
}
},
"ClassLibrary3/1.0.0": {
"type": "project",
"framework": ".NETFramework,Version=v4.6",
"compile": {
"bin/Debug/ClassLibrary3.dll": {}
},
"runtime": {
"bin/Debug/ClassLibrary3.dll": {}
}
}
}
}

21
TestAssets/LockFiles/ExportFiles/valid/project.json
View file

@ -1,21 +0,0 @@
{
"version": "1.0.0-*",
"buildOptions": {
"emitEntryPoint": true
},
"frameworks": {
"net46": {
"dependencies": {
"ClassLibrary1": {
"target": "project"
},
"ClassLibrary2": {
"target": "project"
},
"ClassLibrary3": {
"target": "project"
}
}
}
}
}

65
TestAssets/LockFiles/ExportFiles/valid/project.lock.json
View file

@ -1,65 +0,0 @@
{
"locked": false,
"version": 2,
"targets": {
".NETFramework,Version=v4.6": {
"ClassLibrary1/1.0.0": {
"type": "project"
},
"ClassLibrary2/1.0.0": {
"type": "project"
},
"ClassLibrary3/1.0.0": {
"type": "project"
}
},
".NETFramework,Version=v4.6/win7-x64": {
"ClassLibrary1/1.0.0": {
"type": "project"
},
"ClassLibrary2/1.0.0": {
"type": "project"
},
"ClassLibrary3/1.0.0": {
"type": "project"
}
},
".NETFramework,Version=v4.6/win7-x86": {
"ClassLibrary1/1.0.0": {
"type": "project"
},
"ClassLibrary2/1.0.0": {
"type": "project"
},
"ClassLibrary3/1.0.0": {
"type": "project"
}
}
},
"libraries": {
"ClassLibrary1/1.0.0": {
"type": "project",
"msbuildProject": "../../ClassLibrary1/ClassLibrary1.csproj"
},
"ClassLibrary2/1.0.0": {
"type": "project",
"msbuildProject": "../../ClassLibrary2/ClassLibrary2.csproj"
},
"ClassLibrary3/1.0.0": {
"type": "project",
"msbuildProject": "../../ClassLibrary3/ClassLibrary3.csproj"
}
},
"projectFileDependencyGroups": {
"": [],
".NETFramework,Version=v4.6": [
"ClassLibrary1",
"ClassLibrary2",
"ClassLibrary3"
]
},
"packageFolders": {
"/foo/packages": {},
"/foo/packages2": {}
}
}

35
TestAssets/LockFiles/ExportFiles/valid_staleFragment/project.fragment.lock.json
View file

@ -1,35 +0,0 @@
{
"version": 2,
"exports": {
"ClassLibrary1/1.0.0": {
"type": "project",
"framework": ".NETFramework,Version=v4.5.2",
"compile": {
"bin/Debug/ClassLibrary1.dll": {}
},
"runtime": {
"bin/Debug/ClassLibrary1.dll": {}
}
},
"ClassLibrary2/1.0.0": {
"type": "project",
"framework": ".NETFramework,Version=v4.6",
"compile": {
"bin/Debug/ClassLibrary2.dll": {}
},
"runtime": {
"bin/Debug/ClassLibrary2.dll": {}
}
},
"ClassLibrary3/1.0.0": {
"type": "project",
"framework": ".NETFramework,Version=v4.6",
"compile": {
"bin/Debug/ClassLibrary3.dll": {}
},
"runtime": {
"bin/Debug/ClassLibrary3.dll": {}
}
}
}
}

9
TestAssets/LockFiles/ExportFiles/valid_staleFragment/project.json
View file

@ -1,9 +0,0 @@
{
"version": "1.0.0-*",
"buildOptions": {
"emitEntryPoint": true
},
"frameworks": {
"net46": {}
}
}

13
TestAssets/LockFiles/ExportFiles/valid_staleFragment/project.lock.json
View file

@ -1,13 +0,0 @@
{
"locked": false,
"version": 2,
"targets": {
".NETFramework,Version=v4.6": { }
},
"libraries": {
},
"projectFileDependencyGroups": {
"": [],
".NETFramework,Version=v4.6": []
}
}

17
TestAssets/NonRestoredTestProjects/AppThrowingException/App/AppThrowingException.csproj
View file

@ -1,17 +0,0 @@
<Project Sdk="Microsoft.NET.Sdk" ToolsVersion="15.0">
<Import Project="$([MSBuild]::GetDirectoryNameOfFileAbove($(MSBuildThisFileDirectory), testAsset.props))\testAsset.props" />
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>netcoreapp1.1</TargetFramework>
<AssemblyName>dotnet-throwingtool</AssemblyName>
<PackageId>$(AssemblyName)</PackageId>
</PropertyGroup>
<ItemGroup>
<BuiltProjectOutputGroupOutput Include="$(ProjectRuntimeConfigFilePath)">
<FinalOutputPath>$(ProjectRuntimeConfigFilePath)</FinalOutputPath>
</BuiltProjectOutputGroupOutput>
</ItemGroup>
</Project>

15
TestAssets/NonRestoredTestProjects/AppThrowingException/App/Program.cs
View file

@ -1,15 +0,0 @@
// Copyright (c) .NET Foundation and contributors. All rights reserved.
// Licensed under the MIT license. See LICENSE file in the project root for full license information.
using System;
namespace AppThrowing
{
class MyException : Exception
{
static void Main(string[] args)
{
throw new MyException();
}
}
}

13
TestAssets/NonRestoredTestProjects/AppThrowingException/AppDependingOnOtherAsTool/AppDependingOnOtherAsTool.csproj
View file

@ -1,13 +0,0 @@
<Project Sdk="Microsoft.NET.Sdk" ToolsVersion="15.0">
<Import Project="$([MSBuild]::GetDirectoryNameOfFileAbove($(MSBuildThisFileDirectory), testAsset.props))\testAsset.props" />
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>netcoreapp2.0</TargetFramework>
</PropertyGroup>
<ItemGroup>
<DotNetCliToolReference Include="dotnet-throwingtool" Version="1.0.0" />
</ItemGroup>
</Project>

6
TestAssets/NonRestoredTestProjects/AppThrowingException/AppDependingOnOtherAsTool/NuGet.Config
View file

@ -1,6 +0,0 @@
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<packageSources>
<add key="test-packages" value="../pkgs" />
</packageSources>
</configuration>

11
TestAssets/NonRestoredTestProjects/AppThrowingException/AppDependingOnOtherAsTool/Program.cs
View file

@ -1,11 +0,0 @@
// Copyright (c) .NET Foundation and contributors. All rights reserved.
// Licensed under the MIT license. See LICENSE file in the project root for full license information.
using System;
class Program
{
static void Main(string[] args)
{
}
}

13
TestAssets/NonRestoredTestProjects/AppWithNonExistingToolDependency/AppWithNonExistingToolDependency.csproj
View file

@ -1,13 +0,0 @@
<Project Sdk="Microsoft.NET.Sdk" ToolsVersion="15.0">
<Import Project="$([MSBuild]::GetDirectoryNameOfFileAbove($(MSBuildThisFileDirectory), testAsset.props))\testAsset.props" />
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>netcoreapp2.0</TargetFramework>
</PropertyGroup>
<ItemGroup>
<DotNetCliToolReference Include="dotnet-nonexistingtool" Version="1.0.0" />
</ItemGroup>
</Project>

15
TestAssets/NonRestoredTestProjects/AppWithNonExistingToolDependency/Program.cs
View file

@ -1,15 +0,0 @@
// Copyright (c) .NET Foundation and contributors. All rights reserved.
// Licensed under the MIT license. See LICENSE file in the project root for full license information.
using System;
namespace ConsoleApplication
{
public class Program
{
public static void Main(string[] args)
{
Console.WriteLine("Hello World!");
}
}
}

15
TestAssets/NonRestoredTestProjects/AppWithProjectDependencyAsTarget/TestApp/Program.cs
View file

@ -1,15 +0,0 @@
// Copyright (c) .NET Foundation and contributors. All rights reserved.
// Licensed under the MIT license. See LICENSE file in the project root for full license information.
using System;
namespace ConsoleApplication
{
public class Program
{
public static void Main(string[] args)
{
Console.WriteLine("Hello World!");
}
}
}

29
TestAssets/NonRestoredTestProjects/AppWithProjectDependencyAsTarget/TestApp/project.json
View file

@ -1,29 +0,0 @@
{
"version": "1.0.0-*",
"buildOptions": {
"emitEntryPoint": true
},
"dependencies": {
"Microsoft.NETCore.App": "1.1.1",
"TestLibraryAsAPackage": {
"version": "1.0.0",
"target": "package"
}
},
"frameworks": {
"netcoreapp1.1": {}
},
"runtimes": {
"win7-x64": {},
"win7-x86": {},
"osx.10.10-x64": {},
"osx.10.11-x64": {},
"ubuntu.14.04-x64": {},
"ubuntu.16.04-x64": {},
"centos.7-x64": {},
"rhel.7.2-x64": {},
"debian.8-x64": {},
"fedora.23-x64": {},
"opensuse.13.2-x64": {}
}
}

0
TestAssets/NonRestoredTestProjects/AppWithProjectDependencyAsTarget/TestLibraryAsAPackage/.noautobuild
View file

24
TestAssets/NonRestoredTestProjects/AppWithProjectDependencyAsTarget/TestLibraryAsAPackage/Helper.cs
View file

@ -1,24 +0,0 @@
// Copyright (c) .NET Foundation and contributors. All rights reserved.
// Licensed under the MIT license. See LICENSE file in the project root for full license information.
using System;
namespace TestLibrary
{
public static class Helper
{
/// <summary>
/// Gets the message from the helper. This comment is here to help test XML documentation file generation, please do not remove it.
/// </summary>
/// <returns>A message</returns>
public static string GetMessage()
{
return "This string came from the test library!";
}
public static void SayHi()
{
Console.WriteLine("Hello there!");
}
}
}

18
TestAssets/NonRestoredTestProjects/AppWithProjectDependencyAsTarget/TestLibraryAsAPackage/project.json
View file

@ -1,18 +0,0 @@
{
"version": "1.0.0-*",
"buildOptions": {
"nowarn": [
"CS1591"
],
"xmlDoc": true,
"additionalArguments": [
"-highentropyva+"
]
},
"dependencies": {
"NETStandard.Library": "1.6.0"
},
"frameworks": {
"netstandard1.5": {}
}
}

3
TestAssets/NonRestoredTestProjects/AppWithProjectDependencyAsTarget/global.json
View file

@ -1,3 +0,0 @@
{
"projects": [ "." ]
}

10
TestAssets/NonRestoredTestProjects/DotnetAddP2PProjects/Broken/Broken.csproj
View file

@ -1,10 +0,0 @@
<Project Sdk="Microsoft.NET.Sdk" ToolsVersion="15.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<OutputType>Library</OutputType>
<TargetFrameworks>net451;netcoreapp2.0</TargetFrameworks>
</PropertyGroup>
<ItemGroup>
<Compile Include="**\*.cs" />
<EmbeddedResource Include="**\*.resx" />
<!-- intentonally broken -->

6
TestAssets/NonRestoredTestProjects/DotnetAddP2PProjects/EmptyItemGroup/EmptyItemGroup.cs
View file

@ -1,6 +0,0 @@
// Copyright (c) .NET Foundation and contributors. All rights reserved.
// Licensed under the MIT license. See LICENSE file in the project root for full license information.
public class EmptyItemGroup
{
}

16
TestAssets/NonRestoredTestProjects/DotnetAddP2PProjects/EmptyItemGroup/EmptyItemGroup.csproj
View file

@ -1,16 +0,0 @@
<Project Sdk="Microsoft.NET.Sdk" ToolsVersion="15.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Import Project="$([MSBuild]::GetDirectoryNameOfFileAbove($(MSBuildThisFileDirectory), testAsset.props))\testAsset.props" />
<PropertyGroup>
<OutputType>Library</OutputType>
<TargetFrameworks>net451;netcoreapp2.0</TargetFrameworks>
</PropertyGroup>
<ItemGroup Condition=" '$(TargetFramework)' == 'netcoreapp2.0' ">
<PackageReference Include="Microsoft.NETCore.App" Version="$(CLI_SharedFrameworkVersion)" />
</ItemGroup>
<ItemGroup>
<!-- Existing but empty item group - do not remove -->
</ItemGroup>
</Project>

4
TestAssets/NonRestoredTestProjects/DotnetAddP2PProjects/Lib/Lib.cs
View file

@ -1,4 +0,0 @@
// Dummy reference - it can be used as an existing reference in any of the projects
public class Lib
{
}

12
TestAssets/NonRestoredTestProjects/DotnetAddP2PProjects/Lib/Lib.csproj
View file

@ -1,12 +0,0 @@
<Project Sdk="Microsoft.NET.Sdk" ToolsVersion="15.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Import Project="$([MSBuild]::GetDirectoryNameOfFileAbove($(MSBuildThisFileDirectory), testAsset.props))\testAsset.props" />
<PropertyGroup>
<OutputType>Library</OutputType>
<TargetFrameworks>net451;netcoreapp2.0;netstandard1.4</TargetFrameworks>
</PropertyGroup>
<ItemGroup Condition=" '$(TargetFramework)' == 'netcoreapp2.0' ">
<PackageReference Include="Microsoft.NETCore.App" Version="$(CLI_SharedFrameworkVersion)" />
</ItemGroup>
</Project>

6
TestAssets/NonRestoredTestProjects/DotnetAddP2PProjects/MoreThanOne/SomeSourceFile.cs
View file

@ -1,6 +0,0 @@
// Copyright (c) .NET Foundation and contributors. All rights reserved.
// Licensed under the MIT license. See LICENSE file in the project root for full license information.
public class SomeClass
{
}

12
TestAssets/NonRestoredTestProjects/DotnetAddP2PProjects/MoreThanOne/a.csproj
View file

@ -1,12 +0,0 @@
<Project Sdk="Microsoft.NET.Sdk" ToolsVersion="15.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Import Project="$([MSBuild]::GetDirectoryNameOfFileAbove($(MSBuildThisFileDirectory), testAsset.props))\testAsset.props" />
<PropertyGroup>
<OutputType>Library</OutputType>
<TargetFrameworks>netcoreapp2.0</TargetFrameworks>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.NETCore.App" Version="$(CLI_SharedFrameworkVersion)" />
</ItemGroup>
</Project>

12
TestAssets/NonRestoredTestProjects/DotnetAddP2PProjects/MoreThanOne/b.csproj
View file

@ -1,12 +0,0 @@
<Project Sdk="Microsoft.NET.Sdk" ToolsVersion="15.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Import Project="$([MSBuild]::GetDirectoryNameOfFileAbove($(MSBuildThisFileDirectory), testAsset.props))\testAsset.props" />
<PropertyGroup>
<OutputType>Library</OutputType>
<TargetFrameworks>netcoreapp2.0</TargetFrameworks>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.NETCore.App" Version="$(CLI_SharedFrameworkVersion)" />
</ItemGroup>
</Project>

6
TestAssets/NonRestoredTestProjects/DotnetAddP2PProjects/Net452AndNetCoreApp10Lib/Net452AndNetCoreApp10Lib.cs
View file

@ -1,6 +0,0 @@
// Copyright (c) .NET Foundation and contributors. All rights reserved.
// Licensed under the MIT license. See LICENSE file in the project root for full license information.
public class Net452AndNetCoreApp10Lib
{
}

11
TestAssets/NonRestoredTestProjects/DotnetAddP2PProjects/Net452AndNetCoreApp10Lib/Net452AndNetCoreApp10Lib.csproj
View file

@ -1,11 +0,0 @@
<Project Sdk="Microsoft.NET.Sdk" ToolsVersion="15.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Import Project="$([MSBuild]::GetDirectoryNameOfFileAbove($(MSBuildThisFileDirectory), testAsset.props))\testAsset.props" />
<PropertyGroup>
<OutputType>Library</OutputType>
<TargetFrameworks>net452;netcoreapp2.0</TargetFrameworks>
</PropertyGroup>
<ItemGroup Condition=" '$(TargetFramework)' == 'netcoreapp2.0' ">
<PackageReference Include="Microsoft.NETCore.App" Version="$(CLI_SharedFrameworkVersion)" />
</ItemGroup>
</Project>

6
TestAssets/NonRestoredTestProjects/DotnetAddP2PProjects/Net45Lib/Net45Lib.cs
View file

@ -1,6 +0,0 @@
// Copyright (c) .NET Foundation and contributors. All rights reserved.
// Licensed under the MIT license. See LICENSE file in the project root for full license information.
public class Net45Lib
{
}

6
TestAssets/NonRestoredTestProjects/DotnetAddP2PProjects/Net45Lib/Net45Lib.csproj
View file

@ -1,6 +0,0 @@
<Project Sdk="Microsoft.NET.Sdk" ToolsVersion="15.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<OutputType>Library</OutputType>
<TargetFrameworks>net45</TargetFrameworks>
</PropertyGroup>
</Project>

5
TestAssets/NonRestoredTestProjects/DotnetAddP2PProjects/ValidRef/ValidRef.cs
View file

@ -1,5 +0,0 @@
// Dummy reference - it should not be referenced by any other project directly
// it should be used as a reference passed to the dotnet add p2p
public class ValidRef
{
}

11
TestAssets/NonRestoredTestProjects/DotnetAddP2PProjects/ValidRef/ValidRef.csproj
View file

@ -1,11 +0,0 @@
<Project Sdk="Microsoft.NET.Sdk" ToolsVersion="15.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Import Project="$([MSBuild]::GetDirectoryNameOfFileAbove($(MSBuildThisFileDirectory), testAsset.props))\testAsset.props" />
<PropertyGroup>
<OutputType>Library</OutputType>
<TargetFrameworks>net451;netcoreapp1.0;netstandard1.4</TargetFrameworks>
</PropertyGroup>
<ItemGroup Condition=" '$(TargetFramework)' == 'netcoreapp2.0' ">
<PackageReference Include="Microsoft.NETCore.App" Version="$(CLI_SharedFrameworkVersion)" />
</ItemGroup>
</Project>

6
TestAssets/NonRestoredTestProjects/DotnetAddP2PProjects/WithDoubledRef/WithDoubledRef.cs
View file

@ -1,6 +0,0 @@
// Copyright (c) .NET Foundation and contributors. All rights reserved.
// Licensed under the MIT license. See LICENSE file in the project root for full license information.
public class WithDoubledRef
{
}

Some files were not shown because too many files have changed in this diff Show more