Add -r for recursive cleanup about dotnetcleanup HOT 8 OPEN

Hello @kzu

The idea is that the tool acts like many other .NET Global Tools and work on a per-project-basis. So if the command is run in a folder and it contains a .sln-file, it uses that file to map the projects. If there is a .csproj-file, it uses this to know it's a project-folder. Otherwise, it assumes that the folder you're executing in is the project-folder.

Never really thought about supporting recursion, but it should be too hard :) I'll look into it!

from dotnetcleanup.

yeah, I think the scenario in my case is where you run it on the root of a repo, which typically contains one or more solutions down to the src folder level. So it would be a smarter way of doing git clean -xffd, say. Alternatively, I think it would be worth exploring whether to clean the entire obj or just the per-config folders, since nuget restore (for example) doesn't need to be done again if you preserve the .json in the base obj folder... Maybe another switch?

from dotnetcleanup.

Hello again @kzu. Sorry for the slow response.

I started exploring the concept of a recursive -r-parameter, but I find it doesn't make sense.

If you have a reasonable sized project, it would search trough every sub-folder, including every folder (and sub-folder) of code, and look for bin, obj, node_modules, and so on. I would, of course, makes sure that a folder already flagged for deletion would not be recursively explored.

In your case, if the functionality of this .NET Global Tool would be as intended, you should just be able to point it towards your (one or multiple) .sln-files and it should find the referenced project-files (.csproj and so on) and clean those project-folders accordingly.

What are your thoughts?

from dotnetcleanup.

Hi @sebnilsson! One of the things I do quite frequently is run a shell tool to "Clean Sources" that I've been keeping around for years now (from before Scott even blogged about it ;)):

It's still one of the first things I install when I revamp the machine or get a new one. that common it is to do this sort of cleanup. For repos with multiple solutions, submodules, and what-not, it's a must have. Passing a sln to your tool will typically not be enough IMHO.

I'm curious as to why you think the feature itself doesn't make sense though. Sure, the implementation won't be super trivial, but I can run that shell extension shown above on fairly large repos with sub-second performance.

from dotnetcleanup.

The implementation should not be too hard, but does it make sense to recursively look through all folders, down the line in a normal sized repository, to see if there are bin, obj, and other folders in each of them?

One level of recursion might make sense, to try to cover scenarios of projects laying in a sub-folder, but that should be covered by just pointing the tool toward the correct .sln-file.

Basically, I'm just trying to understand what scenario is not covered by a simple PowerShell-script looping all folders in your repositories (or equivalent) folder and finding the first .sln (or not) and running the tool over it.

If I understand your use-case and what is not covered in above suggestion, I might add it, even if it doesn't make complete sense, just for the practice 😄.

from dotnetcleanup.

I can use powershell all-right, but in that case, why would I use your tool at all? ;)

The point is precisely not to have to use powershell and just rely on a simple dotnet CLI tool to do the job.

Again, if the scenario itself didn't make sense, that Clean Sources tool would have never existed in the first place. Any repo with complex submodules that are built as part of a build script and not an .sln would benefit from this feature, I think :).

from dotnetcleanup.

I think all the .NET Global Tools that I've used work on folders, .sln-files, and/or .csproj-files, not recursively from an arbitrary folder.

But again, I'm up for the pure problem-solving of it all. What is the expected behavior in your book? Just point it to your root Repositories-folder (or GitHub-folder) and it just walks through every single folder recursively and looks for bin, obj, node_modules and so on for every single sub-folder, no matter if it's a .NET-project, Node.js-project, Rust-project, or anything else?

I see a risk in a too broad application that might not work for most people, but I'm open to your thoughts on the matter.

from dotnetcleanup.

Yep, walking and killing folders recursively, plain and simple. Exactly as the Clean Sources shell extension mentioned above does. Sure, it won't be great for everyone, which is why they would need to explicitly opt-in with the -r switch, so I think that's safe enough.

This is basically the gist of it: https://stackoverflow.com/questions/755382/i-want-to-delete-all-bin-and-obj-folders-to-force-all-projects-to-rebuild-everyt

;)

from dotnetcleanup.