I have on TFS that projects in folders:
\root
\website1
\website2
\libraries
class project1
class project2
class project3
when I map by TFS to local every folder and project map ok,
but after open by visual studio all project below website1 was move to website1 folder ;/
Can anybody explain me this VS behavior or how to repair it ?
p.s. after close visual studio sln file missed and I must map everything ones again ;/
Try to minimise the number of folder mappings that you set up - a good project will need only one, to say where the root folder of the source code tree will be stored on your local hard drive. In your case, this should be something like:
$/root -> C:\MyCode
The more mappings you add, the less correspondence you will see between the source control file structure and your local disk structure, and things can get messy very fast.
(Another place that can cause problems is that if you add files within the Visual Studio Solution Explorer, it will often copy the files to the location you're adding them in your solution, rather than referencing them from their original location on your hard drive. But this doesn't sound like it relatesto your question)
Once you have set up the solution, make sure you save it (File -> Save All is useful for ensuring this is done) and you may need to manually add the .sln file into source control and check it in to get it all into TFS.
Related
My Visual Studio (VS) project/solution works as intended, but VS has somehow organized the directory structure (source files) of my project in a non-logical way.
The current directory structure
Solution Folder
Project 1 folder
Project 1 source files
Sub folder
Project 2 source files
.sln Solution file
Project 3 folder
Project 3 source files
I guess I have made a mistake at some point when adding the projects to the solution in VS, since it is organized like this now.
What I would ideally like is this more clean structure:
Solution Folder
Project 1 folder
Project 1 source files
Project 2 folder
Project 2 source files
Project 3 folder
Project 3 sources files
.sln Solution file
When I tried this - or whenver I move/try to reorganize the files/folders outside of VS according to the above by simply moving them around, and then try to build the solution in VS afterwards, I get the following error for (pretty much) all items:
The item (name) does not exist in the project directory.
It may have been moved, renamed or deleted.
So my question is:
How do I reorganize my folders/files for my solution outside of VS, without breaking my solution?
For people who might be having similar obstacle, I found the answer to it from this thread:
Visual Studio move project to a different folder
As described in there, you have to delete the project you wish to move from inside your Solution Explorer in Visual Studio (VS). Afterwards, you move the project folder (outside VS) to where-ever you want it. Finally, in VS Solution Explorer, you right click on your Solution --> Add --> Existing project.
Make sure you dont separate any folders or files, that belong together (be very careful/aware of this).
If you were referencing the different projects e.g. through namespaces, you have to add this again simply by right clicking the project (in Solution Explorer) that you want to reference another project --> Add --> Reference.
EDIT: Visual Studio might, for whatever reason, change which project is initializing first when building/debugging etc. If you look in VS Solution Explorer, the project which is initialized first is bold. If you need to change this, right-click on your desired start-up project --> Set as StartUp Project.
All of the above is for Visual Studio 2017
I searched already on stackoverflow and on the internet but I couldn't find a similar specific question.
When i have to rename a already checked-in (tfs) project in my visual studio (2010-2013) solution, I always use a procedure similar to this one here in the accepted question:
stackoverflow.com/questions/2043618/proper-way-to-rename-solution-and-directories-in-visual-studio
Here is the important snippet from there (thanks to author):
Close Visual Studio.
Create a backup of your .sln file (you can always roll back).
Imagine you want to rename directory "Project1" to "Project2".
If not using source control, rename the folder from "Project1" to "Project2" using Windows Explorer.
If using source control, rename the folder from "Project1" to "Project2" using the functions supplied by source control. This
preserves the history of the file. For example, with TortoiseSVN,
right click on the file, select TortoiseSVN .. Rename.
In the .sln file, edit all instances of "Project1" to be "Project2".
Restart Visual Studio, and everything will work as before, but with the project in a different directory.
..and there i always do step 6:
Step 6.: In the .sln file, edit all instances of "Project1" to be "Project2".
By observing the .sln file i could see that until step 6 (so in my case of using the tfs i did steps 1,2,3 and 5) there are still occurrences of the old project name in the .sln file:
Project("{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}") = "Project2",
"Project1\Project2.csproj", "{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}"
and:
SccProjectUniqueName92 = Project1\Project2.csproj
SccProjectName92 = Project1
SccLocalPath92 = Project1
Until now i had no problems with that approach. But as i could see a colleague of me is skipping step 6 and there are still occurrences of the old project name in the .sln file.
Now i wonder if step 6 is really needed/required?
I am keeping using step 6 just for more cleanness! But whats your opinion on this?
Could the old project name occurrences in the .sln file (if skipping step 6) even some time lead to functional problems with tfs/vs etc.?
Or is it only for the purpose of a cleaner/clearer code better to do carry out step 6?
If you are renaming a project within a solution, that is under source control, really all you need to do is to rename the project in Visual Studio and then submit the changes to the project file and the solution file, back into source control.
Visual Studio and TFS should handle all of the changes for you, VS will rename the project and update the references in the SLN file.
TFS will handle the rename and will maintain the history line.
The only time it should get complicated is if you are moving projects and solutions within source control, when you are carrying out this sort of task then the list above is a fair description of what needs to be done, but after step 4 i would just open the solution remove the project that can no longer be found and add in the newly renamed project, this would then automatically handle the sln file changes. now obviously this would orphan your history on the project if it was under source control, but you would make the project name change through TFS before reopening the solution.
if you want to manually change the sln file then a find and replace operation is the simplest way to update the file.
Coming Back to your question.
You really should ensure the sln file is correct as this tells VS where to download the files from and what projects actually make up the solution, by not updating the sln file correctly you, or other users of TFS may not get the correct files downloaded and you may have issues opening your solution.
An example of fall out from not having these files in line can be found in this question Why missing <SccProjectName> in project file cause "The project file is not bound to source control"
How can I make a solution in visual studio so that the .dll dependencies that reside in some other directory totally different from where the solution itself is affected by "get latest".
What I've tried is creating a Dependencies solution folder within the solution itself and added the dlls to it, that way they belong to the solution even though they don't belong to the directory structure of the solution.
So for example the .sln file is in:
D:\tfs\repository\main\SolutionA\solution.sln
and the dlls are in:
d:\tfs\repository\main\SolutionX\Dependencies\Binaries
What I really want to achieve is to have a foolproof way to build the solution, including the following scenario:
1- Have a brand new installation of windows, visual studio, etc.
2- open visual studio
3- find solution.sln on TFS, double click on it so that visual studio gets every project and files in the solution, and opens the solution
4- successfully build
What happens when I try the Dependencies solution folder approach and repeat the scenario above, it will get all the projects within the solution, opens it, but the dependencies solution contents won't be pulled from TFS (although Visual Studio shows them on Solution explorer), which I think is flawed.
Some suggestions that don't involve creating pre/post build scripts are appreciated.
When you attempt to open a solution for the first time using the TFS Source Control Explorer, you may find that not all of your dependencies will be retrieved - the squiggly line may be highlighting some of your missing References.
One work around is to...
SOLUTION SETUP
Checkout all of your source code from TFS (i.e. Main and all of the sub-directories)
Open your solution in Visual Studio (i.e. MyApplication.sln)
In the solution explorer, create a New Solution Folder called ThirdPartyDll, and then add the appropriate assembly references (i.e. Assembly1.dll, Assembly2.dll,...)
Check-in your solution to TFS
SAMPLE FILE STRUCTURE
Main
MyApplication.sln
Source
MyProjectA
MyProjectA.csproj
MyProjectB
MyProjectB.csproj
Dependencies
Assembly1.dll
Assembly2.dll
You've run into a limitation of the "Open from Source Control" functionality. If you added the solution to source control from Visual Studio you should have seen the following message:
"The project that you are attempting to add to source control may cause other source control users to have difficulty opening this solution or getting newer versions of it. To avoid this problem, add the project from a location below the binding root of the other source controlled projects in the solution."
Open from Source Control will create a workspace mapping for the solutions root directory (D:\tfs\repository\main\SolutionA) but not a separate one for the SolutionX folder which is a peer to SolutionA. On the "new" machine you will need to manually create a workspace mapping to d:\tfs\repository\main in order to get both the SolutionA and SolutionX folder.
Create a solution folder and add the dependencies to it, that way when VS gets latest for the solution it will download these files. A bit brittle as people will need to maintain that folder but it works.
Alternatively create a nuget package and use restore packages on build. It will require a couple of extra steps when you create a new developer box (your nuget package repo will need to be added) but it will work for all projects going forward and is less brittle than the solution folder method.
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.
Whenever I try to add a new project to my SourceSafe repository it creates 3 folders with the same name nested within each other. There is only one folder on my drive yet in Sourcesafe there are 3??
Can anyone suggest what may be causing this?
Thanks
If you drag and rop a new project folder into VSS and do a recursive add then that's just how it works. Otherwise you have to create your own root project folder in VSS and add each file one at a time to VSS by hand.
Try creating the project in VS2005 disconnected from source control, then creating the project folder in VSS, set the working folder correctly, add the files to sourcesafe from VSS, then lastly edit the source control bindings in VS2005 and check the bound project into source control.
A little kludgey but this is how I do it.
well, that problem comes due to visual studio. because visual stuio by default save solution file in the my documents/...../.../vs 2008/projects/ location and that address is also saved in the .sln file.
that's why every time you get latest within visual stuio it try to creat same strucute and make another copy with in the main project folder.
Solution, well i still trying to figure out how to tackle it.
cheers,
Genious