I have several projects in TFS. Now I wanted to modify folder structure of the project.
Current structure is as shown below. With my project folder i have all the forms and .sln files.
Project Root
my project
myproject.sln
file1.vb
file2.vb
.
.
.
file n.vb
Now I want move the all the other files other than .sln file to a new folder named codingfilesfolder .
Project Root
my project
myproject.sln
codingfilesfolder
file1.vb
file2.vb
.
.
.
file n.vb
So now all the files other than .sln file will be in new folder. I can do it easily in TFS by adding files. But there are so many workspaces of developers for this project. So after i do changes in structure , if anyone does get latest version then files will be messed up in there workspace and he will be again getting a new folder which I created . And also files where they have made changes will be outside the current folder of TFS and there changes cannot be checked in or recognised. So how can I manage the existing workspaces after changing the folder structure of TFS project?
So long as you do a "move" on the files, and the check-in shows as a rename/move, then everything should just work. When the other devs do a Get Latest it will move their file keeping their pending changes in tact.
What you want to avoid is TFS detecting it as a delete+add instead of a move.
Related
I am just learning and following a tutorial on how to create a web project. When I create the new project I do see two new folders called bin and obj. I have read what these are but I am confused as to why when they are created they are not 'included'. These folders are white and the others are yellow. If I right click on the folder it provides the option to Include in project. But the other folders provide option to 'Exclude from project. So I have a few questions:
1. Why aren't these folders automatically included in the project?
2. Should I automatically include in the project?
3. Is there any reason not to include these folders in the project?
The bin and obj folders are for temporary files. They are created and filled automatically when you build your application.
Why aren't these folders automatically included in the project?
The files aren't automatically included in the project because they aren't really part of the project. They are the results of the project. In other words, you won't be editing the files in the bin and obj folders directly.
Should I automatically include in the project? 3. Is there any reason not to include these folders in the project?
You should not be including these folders in your project because they are temporary and the contents will be deleted, created, and changed without updating the project (.csproj, .vbproj, etc.) file when you build, rebuild, or clean your solution. Visual Studio looks at the project file to figure out which files to show you through its user interface.
You don't want to be checking for files to include in your bin and obj folders every time you build your solution. Just know that these folders will be used behind the scenes when you debug or publish your web application.
I've renamed one of the projects in a Visual Studio solution. Renaming the project involved renaming its directory and as a result the paths to some files have changed. The solution is under TFS source control. When trying to check in I get a "file not found" error displaying the old path of one of the files. How do I check in the changes?
As I know, when you rename the project, underlying source folder path keeps unchanged (maybe it depends of Visual Studio version).
Try this:
Rename the project folder from Source Control Explorer.
If you have errors with old path, try to unload the project from Solution Exproler, open proj file for edit, and replace old path entries with a new one.
Don't forget to update references from other projects.
I am working on an extension for visual studio to update a project.
The situation is a follows:
We create a new project from a template.
We put the solution in tfs
We change the project which was used to create the template. The project on the tfs server still needs te be updated.
We publish the project to a folder. I now want to update the files in the TFS repo with the current files in the publish folder
I thought of the following approach:
In the application we have all the project stored that are on the TFS server. When I want to update a specific project I select the project from the database. Next I load this project from the TFS server and create a new checkout for this project. So far so good. The problem arise when I copy the files from the published folder to the new checkout. Files that are already registered in the workspace get marked as changed but the files that are new are not added.
The only solution I can think of is to add all the files through the TFS SDK. But this seems pretty heavy to me.
So I got a couple of questions:
Is this the right approach to update
the project?
Is there any other way to add the files to the workspace instead of adding all files through the TFS SDK?
Thanks!
Don't do a blind copy of the files. Instead, have your program iterate through them one by one.
First, update your workspace with the latest from TFS.
Then, for each file in the source directory:
If the file exists in the target directory, "pend edit" the file, then copy it.
If the file does not exist, copy the file, then "pend add" the file.
When you've finished, check in all pending changes in the workspace.
If a VS2008 project is created initially with a web app project, and class projects are added, and the structure is like this:
Parent Folder
Web App Project Folder - (solution Files in this folder)
Class Project 1
Class Project 2
...
do you see any problems with moving the .sln and .suo files to the parent directory?
Parent Folder - (solution Files in this folder)
Web App Project Folder
Class Project 1
Class Project 2
...
I adjusted the .sln project directories and the solution seems to be working fine, but I'm wondering if this action will break something I didn't anticipate.
Only the project files determine their build outputs - solutions only link projects together into a logical entity, so that they can be loaded at the same time in a Visual Studio instance. If the projects are still the same, nothing's broken.
And the .suo file can be safely deleted. It's a user-specific file that simply retains a particular user's options for a solution. It contains nothing that's important to projects, build settings etc.
You can open your .sln file with whatever editor you'd like, even notepad, and see that it contains only references to your project files in it, you can modify it so that the relative paths to your project files in it match your layout. VS wouldn't have anything against it.
All build settings are stored in project files, so you don't loose any configuration changes you've done in your projects.
I copied the root folder to my desktop, deleted all files in that folder or under that folder if the file was a VSS file, opened the project, confirmed that I wanted to removed VSS integration and still my web project but not the referenced projects in the solution were tied to VSS and they changed my checkout folder in VSS!
You should also remove the source control related settings from the sln file.
Look for hidden .vss files.