roslyn: Can no longer git clean solution directory with VS open

git clean is a simple and essential tool when switching branches for any kind of project. It allows us to remove all build artifacts and temporary files generated in the current branch before starting to build and work with another branch. It is a bit annoying that this can’t be done when VS is open.

@CyrusNajmabadi You can also use this:

git clean -dxf -e .vs/

It ignores the contents of .gitignore, but explicitly adds back .vs/.

Seems like this fell off the radar, but this has been coming up for me a lot recently since about 15.7.3.

The issue for me is that this happens after closing the solution. I don’t feel like VS should be locking files in my repo when I’m no longer working on it. I routinely close one solution, then run a clean on it before I move on to another solution (I like to keep my local repos tidy), but this issue prevents me from doing so unless I close VS entirely and re-open it every time I want to load a different solution.

Once upon a time we could git clean -fxd with the solution open. It’s a shame that’s regressed.

To be clear, what we want is to run git clean -fxd. We want to remove stuff which is in .gitignore. E.g. bin, obj, etc.

.vs comes along for the ride in that scenario.

Can we distinguish between “Close VS” and “Close Solution”? If I have VS still running, but have closed the solution, can I clean the .vs directory?

@sharwell Perhaps the change to exclusive access in sqlite?

IMO, this is acceptable behavior. This is a folder being used by the IDE while it is running in VS. It is not expected that this would be removed out from under it while running.

–

As a workaround, is it possible to add .vs to your gitignore so that git doesn’t try to do anything with it when you’re doing cleans and whatnot?

I think it makes sense to leave the .vs folder in the working directory. You just need to clean up the file locks after the solution is closed.

In my case, it seems that VS2017 locks some files in the sqlite3 folder even when the solution is closed. This means I have to close VS to be able to clean the working directory.

Relocate the SQLite cache so it’s no longer part of the repository.

This is my vote for a solution here.

The IDE has always handled that it was removed underneath it.

I don’t think that’s the case. There were certainly folders in VS2005 and whatnot that couldn’t be removed while the IDE was running. It’s likely at the switch to Roslyn this became possible.

Or, in other words, the ability to remove this folder was never an intentional design point of the IDE. It may have fallen out because of certain design decisions, but it was never a guarantee.

–

Now, what to do about this at this point remains to be seen. There are several options:

1. First, find out if it’s possible to get the benefits that we got recently from the sqlite changes, while also removing the locking restriction. I have no idea if this is possible. But @sharwell and @onyxmaster may know of a way.
2. Consider the degradation in git behavior here worse than the gain in Roslyn performance. Roll back the changes made.
3. Consider the degradation in git behavior acceptable given the gain. Keep things as is.

Remember, for this to be added to .gitignore, you basically have to change every single repo in the world.

That honestly doesn’t seem like a large problem to me. The users that hit this have to be in the venn diagram of:

A. Use git. B. Use Roslyn. C. Want to git clean while Roslyn is running.

Those users will definitely exist. But there will also be many users who won’t do any of that. Furthermore, there is a workaround which is fairly easy to apply. Given that, i would lean toward ‘3’ if ‘1’ is not possible. I think the benefit to performance is worth the inconvenience of people doing A, B, and C needing to edit their .gitignore file. Just my 2c on this 😃