Which Files Should Be Read-Only for TFS? - visual-studio-2010

I was upgrading from VS 2008 to VS 2010. When I was getting errors in the auto-upgrade saying that files could not be opened, I made (what a I believe to be) a mistake and just went to Explorer and un-checked "read-only" for the containing folders and didn't check the files out. I now want to go through and set those files to "read-only" again, so I don't break stuff. Does anyone know which files are meant to be read-only and which ones, if any, are not?

Files which are not checked out should be read-only. Once a file is checked out, it becomes writable.

the simplest solution is the following:
Mark all files read-write
In Visual Studio Clean the solution to remove all not versioned files
Mark all files read-only
Run "tfpt online" or "tf folderdiff" to find all modified files and check them out
check in files checked out in previous step
run build to make sure everything is fine

Related

Can I safely delete files created by Visual Studio from external drive?

When I installed Visual Studio, it also placed hundreds of files on my external hard drive. And now the folder structure is full of "junk" that I don't want.
Is it safe to delete these files? Will deleting these files affect my Visual Studio installation (which is on a different disk) at all? Why does VS do this anyway? Why does it place all this crap on a drive I never even gave it permission to put it on in the first place?
You can safely delete any of those files, since, quoting Microsoft KB,
These temporary files are erroneously generated by the installer into the root directory of one of your drives, instead of the temp directory
Those are temporary files indeed and they, still quoting Microsoft,
are generated on the root directory of a drive that has the largest available space in the system
Check Microsoft knowledgebase pages like this for more detail.
What about archiving those files, opening visual studio and check it is still working?
If it doesn't just put the files back where they were...
You should be safe deleting those files. Someone already asked this question. :D
Visual Studio 9.0 Beta Program files in C:\
hope I was helpfull
Jasper.
Cause
These temporary files are erroneously generated by the installer into the root directory of one of your drives, instead of the temp directory.
Resolution
These files are unnecessary and can be safely deleted from the system. The functioning of the runtime library will not be affected by this.
Its a known bug and is fixed in VS2008 SP1.
Ref: https://support.microsoft.com/en-us/kb/950683

Should we ignore Solution Output folder while we are using Visual Studio and Version Control?

I'm using Bazaar and Visual Studio 2010 in a C# project. I have prepared an ignore list but still I think all the files in Solution Output directory could be ignored.
I search a lot but nobody had mentioned it. So I'm going to know if I can ignore this directory because output files are changing regularly and seems are not important for repository copy.
What do you suggest about this issue ?
In general, any file that is automatically generated by compiler or build tools should NOT be committed into source control. This includes object files, executables, generated resource files, symbols, etc. Committing those files does not serve any useful purpose. Also, sometimes there are configuration files which look like can be committed, but really should not if they only contain local user specific info - for Visual Studio there are *.user files.
By that logic, solution output folder should be always put into ignore list.

Error MSB3541: Files has invalid value

I just deployed an asp.net mvc 3 web application to AppHarbor but it failed:
C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets(3932,5): error MSB3541: Files has invalid value "<<<<<<< HEAD". Illegal characters in path. [D:\temp\q5cmde4m.uk1\input\MyProject\MyProject.csproj]
This happened after I opened the project with Visual Studio 2012 (the application was created with VS2010).
Try to search the entire solution for the value and remove it from where it occurs, and then delete the obj folder from your project. When you build again it should work.
The obj folders are hidden in Visual Studio. You can see them with a file explorer.
Delete the obj folder within your project and it will fix the issue.
though it is very old question but I would like to add an answer here.
when you work with multiple developer in visual studio you should git ignore obj folder, .suo,.sln etc which is only holding the visual studio information user based.
refer to this SO question
Ok this might be helpful to someone else.
in my case my .vbproj file and some form files somehow had the last lines of its code truncated, I fixed this by restoring this missing part of the code (around the last 10 lines were missing) from a previous backup of the same project.
The other files got corrupted in a simillar way and were fixed by restoring the missing parts of the files from the backed up ones on a text editor (notepad)
After getting this the project loaded without issue.
Delete both obj and bin folder it will fix the issue, which in my cas its been done and it was causing when create pull request from remote repository !!
Yes, it is about merging conflicts. Usually Visual Studio highlights most of the errors with file paths. However, it does miss some files.
All you have to do is REMOVE the "obj" an "bin" folder from your solution.
If you are in Visual Studio, you have to select "Show All/Hidden files" as "obj" folder is hidden, and then delete it.
You can also delete it by going to your directory where your project is stored e.g C:/Users/username/source/repos/project/ (can be different in your case).

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

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
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.
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.
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.
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.
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.
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.

visual studio: unable to delete folder this function is not supported on this system

Appparantly I'm the only one on the Internet experiencing this problem because I can find ZERO other reports of anyone else encountering it. Unfortunately I've been dealing with it for months and I don't know what else to do.
sometimes when I attempt to delete a folder from visual studio 2010, I get the error
unable to delete folder 'XXXX' this function is not supported on this
system
I can't delete it from the file system either unless I reboot the machine. Apparently there is a lock on it somewhere, but I can't find it. I tried to use Unlocker, but that doesn't work on Windows 7 x64 so I'm stuck.
This happens most often with the App_Theme folder, though it happens with other folders as well.
I would suspect it has something to do with source control (we are using sourcegear fortress), however I've encountered this error at home on my personal projects, and I don't use source control on that...
so does anyone have any ideas? has anyone out there experienced this issue? please help, it's driving me quickly and certainly towards insanity.
same thing to me here, what i am doing to fix that is to delete that file or folder from the file system and after that delete it from visual studio.
This is happened to me because previously I opened file in browser to see what is the content. Probably IIS locked files under this folder so it does not let you delete them.
Do iisreset and try again, it will release lock and you can delete it from visual studio.
You are probably trying to delete a file in a folder for which you don't have permission. Try to move your files to another folder or run Visual Studio as administrator.
This may happen if you do not have folder permissions within windows itself. Give the user folder permissions (full control) for the folder containing the solution and make sure those permissions are inherited by children of the folder. Once that is done (in the case of one of our employees) folders can be deleted from within visual studio.

Resources