Sdk: dotnet-run

[richlander]

dotnet-run

NAME
dotnet-run -- Runs source code 'in-place' without any explicit compile or launch commands.

SYNOPSIS
dotnet run [options]

DESCRIPTION
The run command provides a convenient option to run source code with one command. It compiles source code, generates an output program and then runs that program. This command is useful for fast iterative development and can also be used to run a source-distributed program (e.g. website).

This command relies on the compile command to compile source inputs to a .NET assembly, before launching the program. The requirements for and handling of source inputs for this command are all inhereted from the compile command. The documentation for the compile command provides more information on those requirements.

The native command uses compile in the following way:

dotnet compile -o dotnetapp.exe [overriden defaults from dotnet run]

Output files, including temporary files, are written to the child bin folder, which will be created if it doesn't exist. Files will be overwritten as needed.

Options

-v, --verbose
Prints verbose logging information, to follow the flow of execution of the command.

[davidfowl]

To make this work well with the IL scenario we're going to need to be able to load dlls in place because publishing will be wayyy too slow.

[shanselman]

run should be default and implied. I realize this is a go compete and go syntax copy, but why not

dotnet foo.cs
dotnet foo.fs

is the same as

dotnet run foo.cs
dotnet run foo.fs

If you see watever.xx then run is implied. This is more like Node or Java.

[anurse]

I don't really like it... Since we will be supporting all sorts of things like a folder full of source files and compiled binaries, you could get in to conflicts. What if there was a folder named compile? Should dotnet compile run that folder or the compile command?

I'd much rather have a consistent UI where dotnet is always followed by a command than have some magic around eliding one of those commands.

[ellismg]

+1. It also keeps the mental model very clean, dotnet itself is a wrapper around sub commands which can slice and dice as you please.

[shanselman]

You're not thinking about the beginners and the competition. Python, Ruby,
Java all run apps just like that. Run is THE most common thing folks will
do. It should absolutely be the default and it hurts no one to do it. It
only makes it easier to teach, demo, and explain. The newbie (who we are
trying to get to use this new product) should bump up again as few concepts
as possible. You're all talking about sub commands...they
won't have those concepts yet.

apt-get install dotnet
dotnet program.cs

And @anurse, you just have rules for those few exceptions. Commands are
reserved words so you can't have folders with the same name. Same reason
that .NET isn't called COM3. ;)

On Tue, Oct 20, 2015 at 9:55 AM, Matt Ellis [email protected]
wrote:

+1. It also keeps the mental model very clean, dotnet itself is a wrapper
around sub commands which can slice and dice as you please.

—
Reply to this email directly or view it on GitHub
https://github.com/dotnet/cli/issues/59#issuecomment-149631658.

Scott Hanselman
Donate to fight diabetes: http://hnsl.mn/fightdiabetes

[anurse]

Having exceptions won't really be tenable when we're talking about arbitrary extensibility of the dotnet tool. Right now, all dotnet foo does is shell out to dotnet-foo (much like how Git works), so dotnet doesn't actually know about the possible sub-commands.

[anurse]

And matching against Python/Ruby/Java doesn't quite work here because they don't have the same kind of single unified command. Python and Ruby are interpreters, and packaging/"compilation"/etc. is all handled by other tools (gem, bundler, etc.). Java has a separate tool for compilation (javac).

If we're OK splitting the executor from the SDK, then we can investigate that, but if we want them to be unified, they really should be well-defined and isolated. go did exactly that which, I would expect, is why it was used as a basis for that. I don't think dropping run actually makes it easier for newbies if you just have to follow it up with explaining the sub-commands, thus raising the issue of conflicts.

[shanselman]

So if I make a little public static void main() and put it in program.cs,
how do I run it? What are the commands?

On Tue, Oct 20, 2015 at 3:01 PM, Andrew Stanton-Nurse <
[email protected]> wrote:

And matching against Python/Ruby/Java doesn't quite work here because they
don't have the same kind of single unified command. Python and Ruby are
interpreters, and packaging/"compilation"/etc. is all handled by other
tools (gem, bundler, etc.). Java has a separate tool for compilation (
javac).

If we're OK splitting the executor from the SDK, then we can investigate
that, but if we want them to be unified, they really should be well-defined
and isolated. go did exactly that which, I would expect, is why it was
used as a basis for that. I don't think dropping run actually makes it
easier for newbies if you just have to follow it up with explaining the
sub-commands, thus raising the issue of conflicts.

—
Reply to this email directly or view it on GitHub
https://github.com/dotnet/cli/issues/59#issuecomment-149715580.

Scott Hanselman
Donate to fight diabetes: http://hnsl.mn/fightdiabetes

[Petermarcu]

Current proposal is:
dotnet compile helloworld.cs
./helloworld

[shanselman]

I thought the beginning of this thread said

dotnet run helloworld.cs

full stop. Are these equivalent?

On Wed, Oct 21, 2015 at 11:42 PM, Peter Marcu [email protected]
wrote:

Current proposal is:
dotnet compile helloworld.cs
./helloworld

—
Reply to this email directly or view it on GitHub
https://github.com/dotnet/cli/issues/59#issuecomment-150123433.

Scott Hanselman
Donate to fight diabetes: http://hnsl.mn/fightdiabetes

[anurse]

Yeah, I think this issue is proposing a dotnet run command that can combine those two. Ideally, I'd like to just be able to do dotnet run inside a folder/project and have it work.

[shanselman]

Again, if run is the default then I feel you're making my point for me.

dotnet foo.cs

The run is optional.

On Thu, Oct 22, 2015 at 12:06 PM, Andrew Stanton-Nurse <
[email protected]> wrote:

Yeah, I think this issue is proposing a dotnet run command that can
combine those two. Ideally, I'd like to just be able to do dotnet run
inside a folder/project and have it work.

—
Reply to this email directly or view it on GitHub
https://github.com/dotnet/cli/issues/59#issuecomment-150324932.

Scott Hanselman
Donate to fight diabetes: http://hnsl.mn/fightdiabetes

[davidfowl]

This needs to dump the output to a temp folder similar to go:

on OSX:

/private/var/folders/sk/6y6p1xt96519ldvbrs40hqr40000gn/T/go-build045720396/command-line-arguments/_obj/exe/hellotest

It cleans up on exit as well.

This preserves the magic

[davidfowl]

We have an implementation of this and no @shanselman it doesn't take a file name. The input is a folder :smile:

[davidfowl]

Here's a verbose trace of that output:

[ManishJayaswal]

With a .csx file, you should be able to just say "dotnet run HelloWorld.csx". This needs no scaffolding of main or project.json

[davidfowl]

Thats why overloading this command to run csx is a mistake.

[ManishJayaswal]

I think we need to treat C# script files as first class citizen in dotnet driver. If one wants to run a C# script file, the most intuitive way is to type run. If we force users to type "dotnet tools csi myscript.csx" then we are just making it too hard for them and .csx files won't look like first class citizens. Also running a csx files does exactly the same thing as regular run. It builds the file and then runs it. So why should it be different?

[davidfowl]

dotnet run takes a path to a folder via an optional parameter --project. dotnet run {project} does not work because it's impossible to distinguish command line arguments for the application VS the file you're trying to run. The only way to make it work would be to hard code .csx and.vbx and fsi and all the other file base extensions, or make the project a required argument instead of an optional parameter.

FWIW we went through this evolution with the dnx. It was:

dnx run

Run in the current folder. This required that build script cd into the target project folder to run and that was a fail.

dnx {path} run

The path was mandatory so you ended up with dnx . run to run things in the current folder.

dnx -p {path} run

Eventually we settled on an optional parameter instead of an argument. We still supported dnx run which assumed the current folder.

[spboyer]

@davidfowl @shanselman so I'm clear. dotnet run == dnx web today for web apps? Or what would be the equivalent?

[anurse]

It would certainly work similarly. Moving forward, you'll have three main options

1. dotnet run it from source directly, this compiles the project and launches it
2. dotnet compile the managed code and run the output (dotnet compile drops a shim native executable that loads coreclr and launches your app)
3. dotnet compile --native into a completely self-contained native application with no dependencies and run the output.

[blackdwarf]

We've moved the documentation for this into the proper MD file in the repo. Will close this, reopen if needed.