2. Use `artifacts/{os}-{arch}/stage2/bin/dotnet` to try out the `dotnet` command. You can also add `artifacts/{os}-{arch}/stage2/bin` to the PATH if you want to run `dotnet` from anywhere.
All the CLI tests are located under `test`. In order to run them, after doing a restore on the CLI repo just do the following:
1. Navigate to a test project, for instance: `cd test\dotnet-test.UnitTests`
2.`dotnet test`
For unit test projects (they have UnitTests at the name), that's all that you need to do, as they take a dependency on the product code directly, which gets rebuilt by dotnet when you run the tests.
For E2E and functional tests, they all depend on the binaries located under `artifacts\rid\stage2\bin`. So, after changing the code, you will need to re-build the product code and copy the new bits to the folder above. For instance, imagine you changed something in dotnet itself, you would have to do the following:
The dotnet CLI considers any executable on the path named `dotnet-{commandName}` to be a command it can call out to. `dotnet publish`, for example, is added to the path as an executable called `dotnet-publish`. To add a new command we must create the executable and then add it to the distribution packages for installation.
- 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.
