Sdk: dotnet-clean command

[TheRealPiotrP]

We need to determine what this does. Is it project specific?

[TheRealPiotrP]

Think about what it means to clean a:

• console app
• AOT console app
• Web App
• Others?

[richlander]

I don't _know_ what the answer is, but I do have a strawman for the model.

• Multi-file compile drops files in a bin directory.
• Single file compile drops the single file in the project directory.

clean, then, should operate on that assumption to delete files. It's an open q of whether it is reasonable to delete files in a developer-owned directory. I'm not sure it is.

/cc @brthor

[gkhanna79]

Why would the compilation affect the drop location?

[brthor]

It seems like we don't quite have clarity on what dotnet compile will be producing. And that will ultimately determine what needs to be cleaned.

In the managed case, as I understand it, we currently require the framework assemblies and runtime to be applocal, or in a shared location. In this case the question is whether a "dotnet compile" will produce a single dll/exe, which is only runnable by a subsequent "dotnet run", or a dll with the name of your app and coreconsole/framework assemblies all in the same location.

If "dotnet compile" will produce a single dll, which is run from some shared runtime, then it makes sense to give clean some knowledge of the project to clean up the appropriate dll only. If "dotnet compile" is going to produce a fully standalone app, then it makes sense for that to be in a bin directory of some sort so we don't blow up the source working directory. In that case "dotnet clean" would only be removing that bin directory.

The dotnet native compilation case I expect would be similar to the single file managed dll case. We could give clean some knowledge of the project to ensure it is only cleaning the appropriate binaries.

These are my thoughts on the current compilation cases, but I could easily be misunderstanding something.

Thoughts? @richlander @gkhanna79

[brthor]

Following up on this. Now it is looking like "dotnet compile" in its various forms will produce artifacts in the "bin" ( dotnet/cli#48 ) and "obj" ( dotnet/cli#70 ), it seems like the responsibility of "dotnet clean" will be primarily to remove those folders, if they exist in the current working directory.

A couple open questions, should dotnet clean have an option to do this recursively through subdirectories? It seems like it could be useful in multiproject situations.

On that same note, how much should dotnet clean know about multiproject builds? Right now this is supported through project to project references in the project.json and is supplemented by the global.json. In these environments it would be pretty useful to be able to do a dotnet clean in your root project and have it clean the referenced projects as well.

/cc @richlander @gkhanna79

[brthor]

Looking at the proposal for "dotnet-install-package" ( dotnet/cli#76 ), if we are creating an applocal package cache, I think it'd make sense for clean to remove that as well.

Something like:
dotnet clean --packages

Would remove the "bin", "obj", and "packages" folders.

[davidfowl]

I don't think e should support app local packages folders that way. This wil exist in nuget config as multiple source have to read it. Command like switches that let you specify where packages go don't work well because other tools consuming them have to know where to look.

In DNX we allow relocating via global.json and we will also support reading nuget.config

[weshaggard]

@davidfowl what about repo level package caches? Perhaps you can scope a global.json to a given repo I'm not sure.

As for the question about recursive cleaning I would have a similar question for other commands like compile and publish as well. So perhaps that should be raised as a more general question.

[richlander]

@brthor I worry about recursive clean. I'd suggest that we get some experience with multi-project solutions before we build that. One scenario is where someone includes both native and managed projects in the same build. Might dotnet clean accidentally delete a native bin / obj directory?

On the other hand, dotnet restore is recursive. We could look at the model it uses and see if that can be applied to dotnet clean. They don't operate over the same assets (only project.json is in common) but it is worth looking at.

Thoughts @blackdwarf?

[richlander]

@blackdwarf I think we should write a real man page for this to address these questions. Good?

[davidfowl]

@davaidfowl what about repo level package caches? Perhaps you can scope a global.json to a given repo I'm not sure.

Yes, this already works, you can put global.json anywhere in the hierarchy an the packages folder can be relative to that (declared in there or nuget.config)

[blackdwarf]

@richlander good, will put something together for discussion here. :)

[blackdwarf]

dotnet-clean

NAME
dotnet-clean -- Clean the binary artifacts (compilation results) from the project folder(s)

SYNOPSIS
dotnet-clean [options] [directory]

DESCRIPTION
This command is used to clean the compilation products out of the project directories. The command will remove the contents of bin/ and obj/ directories as well as the directories themselves. This will bring the entire project in the state before the first compilation. This command will not clean or in any way interact with packages that were installed/restored for the application.

If global.json is present in the directory where the command is invoked, the command will read the global.json file and will clean the directories referenced in the global.json file. You can also use the --path switch to specify a global.json file that exists in a different directory. If the directory paths are present on the command line during invocation, those directories specified are used for the clean operation. If the command is invoked as-is, without any paths, it assumes the current directory as the target.

The command will not recursively walk the directory path. If this is required, the directories need to be specified in the global.json file.

Arguments
[directory]
A space-separated list of paths to clean.

Options
-p, --paths [path]
Path to the global.json which to use for directories to clean.

EXAMPLES
dotnet clean
Clean the current directory.
dotnet clean path/to/1 path/to/2
Clean the directories specified in the command invocation.
dotnet clean --source path/to/global.json
Cleans the directories specified in global.json.

SEE ALSO
dotnet-compile

[brthor]

@blackdwarf I like the way global.json is handled, although I'm not sold on the "--source" switch. That being said I can't think of a better name right now.

For the default path arguments though, why comma separated? I haven't seen this convention before in command line tools. Any reason not to just separate them with spaces?

[blackdwarf]

@brthor no, nothing particular. I agree, the comma-separated is probably not a good choice.

[blackdwarf]

Updated with changes @brthor suggested.

@richlander @piotrpMSFT any comments?

[richlander]

Thanks @blackdwarf. Is "directory" the same as "path to project" or is it "path to bin"? Since the command deletes directories, the use of "directory" is a bit ambiguous. Intuitively, I think of clean as targeting a project.

How did this work in DNX? Or did it have this?

/cc @davidfowl, @glennc

[blackdwarf]

Yeah, it is path to project. I guess renaming it to [project] would be better?

I don't think we had this in DNX...at least that I remember.

[blackdwarf]

@glennc mentioned to me yesterday that DNX didn't really have this, since it was usually running from source, and if you want to dnu build stuff, you should know where they are dropped and will be able to clean them manually. Given that we are here now making slightly different conventions/reccomendations to developers, I think a clean that is aware of our compile conventions is a good addition.

[blackdwarf]

I will add a new overall issue to track all of these that cover commands that are not yet implemented. Closing this for that.

[sayedihashimi]

@blackdwarf is there a new issue? We are interested in integrating the clean command into the .xproj file. I'd like to get details on what's the status of clean so that we can plan accordingly on our side.

[blackdwarf]

@sayedihashimi it is referenced above (#1578). :) As it looks now, we will not be making dotnet clean for v1.

[niemyjski]

This functionality needs to be removed from vs if it's not going to be supported on the command line :)

[GiorgioG]

@blackdwarf why isn't it making it into v1?