Visual Studios 2010 SP1 "Unable to copy file '...\.svn\all-wcprops' Access to the path 'bin\\.svn\all-wcprops' is denied"

Question

I am using Visual Studio 2010 to develop an MVC 3 application for Azure. We are using AnkhSVN for subversion control, which has been slightly buggy in the past.

The error I'm getting when I try and Build/Debug my application is:

Unable to copy file "C:\Xxx_bin_deployableAssemblies.svn\all-wcprops" to "bin\.svn\all-wcprops". Access to the path 'bin\.svn\all-wcprops' is denied.

The story gets more convoluted, since this error is not thrown on another one of our developer machines, just on mine. The only real difference in our machines is that I have SP1 installed on mine.

Also when I updated AnkhSVN and re-checked out the app from the subversion server it work without throwing an error for the first build. After shutting my comp and then starting back up there error popped back up again.

Update:

I still haven't found a real solution. I just delete the .svn file in the folder and that takes care of the issue with Building the app. However, when I update or commit it throws an unversioned error.

I think the problem is that the app is trying to copy the .svn file over during the build, instead of just ignoring.

Do you know of any way to have the .svn file to be explicitly excluded from the build?

I need to resolve this issue asap, so any help is great!

Thanks

Yearn

oi! Accept my answer, it works, its the real solution and it should be at the top to help people! prod, prod. Also you need to improve your "accept ratio" – Latinist

Answer 1

I received the same errors after I versioned my MVC 3 app for Azure on VS 2010 SP1. I was able to resolve this issue in three simple steps.

1.) From the VS 2010 Solution Explorer, click 'Show All Files'. This will show the hidden 'bin' and 'obj' folders in your Web/Worker role project. Right-click and delete both 'bin' and 'obj' folders.

2.) In Windows Explorer, browse to the folder that is versioned (should be your root solution folder). Right-click -> 'SVN Update'. This will download and put back the 'bin' and 'obj' folders that you deleted in VS. This is necessary because your project will exclude these folders from the solution, however SVN will still think they are part of it.

3.) The final step is to delete these files from your repository. In Windows Explorer, browse to the project that contains the 'bin' and 'obj' folder. Select the 'bin' and 'obj' folder -> right-click -> TortoiseSVN -> Delete. Go back to the root versioned folder and SVN commit to remove them from the repository.

The next time you build your Solution, the 'bin' and 'obj' folders will be recreated. Just make sure you don't add or commit them to your repository.

Nebulose

Good advice. Don't forget after that third step to Commit those deletes. – Staphylo

Answer 2

I fixed this problem by going into Windows Explorer and changing the properties of the folder to not index (look in advanced settings) and then manually copying the files giving me errors.

Syllable

Answer 3

I had the same problem and fixed it.

You have your build output checked into SVN. This Azure target (that's complaining) should only be messing with \bin, \obj directories during a build. It will be cleaning and building. This clashes with .svn as source controlled files under .svn have hidden files and folders with read-only access. Therefore the build runs and subsequently breaks when the Azure targets try to delete/move the .svn files.

To fix just remove your build output from SVN (anything in \bin or \obj). You should not be placing these files into source control anyway as the rest of the files in SVN produce this output, so there is no reason to save it separately. Then you can delete the bin/obj etc folders and you should no longer experience the issue.

If you just delete the bin and obj files as other people have suggested then you're just leaving the problem for the next poor sucker that checks out a clean.

Latinist

Answer 4

I had the same problem. It appear that the project bin folder was "accidentally" also committed into the svn. After removing the bin which of course shouldn't be in the svn the problem was solved.

Now it is still needed to understand why the build try to copy the sv folder to the bin.

Oceanography

Answer 5

Somehow another application keeps the file locked while Subversion (below AnkhSVN) tries to replace it with a different version.

Usually this is caused by a virus or index scanner. Retrying a bit later usually resolves this issue.

Sometimes a Subversion "Cleanup" (Solution explorer->(relevant node, E.g. Solution)->Subversion->Cleanup) is required to recover from similar errors.

Pincince

Thanks for the response, however I have tried the Clean up solution with no change in the error message. I have also done a virus scan and my system came up as clean. Any other suggestions? – Yearn

Answer 6

I also had this problem. The cause for me was that I had created the bin directory myself instead of letting VS create the bin directory. Once I deleted the bin directory cleaned the build and did a rebuild, everything worked fine.

Namedropping