Home

Awesome

.NET Command Line Interface

Join the chat at https://gitter.im/dotnet/cli

This repo contains the source code for cross-platform .NET Core command line toolchain. It contains the implementation of each command and the documentation.

Looking for the .NET Core SDK tooling?

If you are looking for the latest nightly of the .NET Core SDK, see https://github.com/dotnet/core-sdk.

Found an issue?

You can consult the Documents Index to find out the current issues and to see the workarounds.

If you don't find your issue, file one! However, given that this is a very high-frequency repo, we've setup some basic guidelines to help you. Consult those first.

This project has adopted the code of conduct defined by the Contributor Covenant to clarify expected behavior in our community. For more information, see the .NET Foundation Code of Conduct.

Build status

Windows x64
Build Status

Basic usage

When you have the .NET Command Line Interface installed on your OS of choice, you can try it out using some of the samples on the dotnet/core repo. You can download the sample in a directory, and then you can kick the tires of the CLI.

First, you will need to restore the packages:

dotnet restore

This will restore all of the packages that are specified in the project.json file of the given sample.

Then you can either run from source or compile the sample. Running from source is straightforward:

dotnet run

Compiling to IL is done using:

dotnet build

This will drop an IL assembly in ./bin/[configuration]/[framework]/[binary name] that you can run using dotnet bin/[configuration]/[framework]/[binaryname.dll].

For more details, refer to the documentation.

Building from source

If you are building from source, take note that the build depends on NuGet packages hosted on MyGet, so if it is down, the build may fail. If that happens, you can always see the MyGet status page for more info.

Read over the contributing guidelines and developer documentation for prerequisites for building from source.

Questions and comments

For all feedback, use the Issues on this repository.

License

By downloading the .zip you are agreeing to the terms in the project EULA.

Repository SLA

This Service-Level Agreement (SLA) represents the commitment of the maintainers of the .NET Core CLI/SDK repositories to community members and contributors.

Pull requests

While the maintainers of this repository have the right and obligation to move .NET Core in a direction which might conflict with pull requests from community contributors, pull requests from community contributors should receive prompt feedback and either be approved by assigning to an appropriate release milestone or closed with gratitude and a valid explanation. Pull requests from community contributors should not be put in the backlog milestone because pull requests rarely stay valid over long periods of time; thanking the contributor for their effort and closing the pull request with an explanation is preferable to letting the pull request linger in backlog limbo.

New pull requests

The maintainers of the repository will triage new pull requests from community contributors within one week of the creation of the pull request.

The community pull request will be triaged as follows:

For any pull request, if the contributor has been asked for updates or clarifications and the maintainer has not heard back from the contributor for one month, the pull request will be assumed to be abandoned and will be closed, unless other time limits have been agreed upon between the contributor and the maintainer.

Stale pull requests

As codebases change significantly over time and stale pull requests are unlikely to be merged without significant additional work, any pull request older than six months from a community contributor should be closed with an explanation as to why the pull request was not merged. However, contributors may choose to update their feature branch and re-open the pull request (or re-submit a new pull request) if it is again ready to merge. At such time, the maintainers should treat the reopening as if it were a new pull request and decide to accept the pull request and for which release milestone it belongs to.

Issues

Reported issues from community members will be treated identically to any other issue, whether discovered by the maintainers, other Microsoft employees, etc.

The maintainers will triage issues each business day:

Issues may be closed by the maintainers of the repository for the following reasons:

Because any code repository gradually amasses a non-trivial number of minor bugs that are unlikely to ever get fixed due to scheduling or other constraints, and which become increasingly irrelevant as the product changes, the maintainers should periodically (once or twice a year) close minor issues older than a year that no longer meet the bar as won't fix. This action should include issues assigned to the backlog milestone so that the backlog isn't an issue graveyard.