-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
dotnet-clean command #4294
Comments
Think about what it means to clean a:
|
I don't know what the answer is, but I do have a strawman for the model.
/cc @brthor |
Why would the compilation affect the drop location? |
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 |
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. |
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: Would remove the "bin", "obj", and "packages" folders. |
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 |
@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. |
@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? |
@blackdwarf I think we should write a real man page for this to address these questions. Good? |
Yes, this already works, you can put |
@richlander good, will put something together for discussion here. :) |
dotnet-cleanNAME SYNOPSIS DESCRIPTION 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 Options EXAMPLES SEE ALSO |
@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? |
@brthor no, nothing particular. I agree, the comma-separated is probably not a good choice. |
Updated with changes @brthor suggested. @richlander @piotrpMSFT any comments? |
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 |
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. |
@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. |
I will add a new overall issue to track all of these that cover commands that are not yet implemented. Closing this for that. |
@blackdwarf is there a new issue? We are interested in integrating the |
@sayedihashimi it is referenced above (#1578). :) As it looks now, we will not be making |
This functionality needs to be removed from vs if it's not going to be supported on the command line :) |
@blackdwarf why isn't it making it into v1? |
We need to determine what this does. Is it project specific?
The text was updated successfully, but these errors were encountered: