I had a solution containing the following projects:
Web App 01
Server Control Foo
Server Control Bar
Each project has its own directory in the root of the solution directory, directly mirroring the structure of the solution.
I branched the solution, then combined items 2 & 3 into a new project within that solution, then deleted projects 2 & 3. I committed the changeset. The resulting structure in VS2015 solution explorer was this:
Web App 01
Server Control Library
I then merged the branch, and committed this also. Over time, branching and merging has got slower and slower. On inspecting the file structure of my hard drive, and Visual Studio Online, I see this folder structure:
Web App 01
Server Control Foo
Server Control Bar
Server Control Library
Despite Solution Explorer not listing the deleted projects, the folders and files from all my deleted projects remain. Despite their status, they are also being branched every time. Is this the correct behaviour, and is it safe to delete them? If so, should I delete using VSO, Windows, or VS2015?
I assume you are using TFVC (changeset, branched the solution).
First, delete the projects from solution (right click the project in VS > Remove) just remove the relationship between projects and solution, the projects’ files and folder are still existing in the hard drive. So you need to delete these files and folders from hard drive (file system).
Secondly, these files are still existing in the source control too, because they aren’t marked as deleted if you just remove projects from solution, so check in changes just affect the solution file, it won’t delete files from source control. So you need to delete them from source control and it’s safe.
Steps to delete files:
Go to Source Control Explorer in VS
Right click Folder or file > Delete
Check in changes
BTW, the files still can be restored if you don’t permanently destroy them. (Destroy command), more information, you can refer to this article: Delete or restore files and folders in Team Foundation Version Control (TFVC)
Related
I am a bit confused about the concept of workspace and working folders. I see in the Source Control Explorer I can setup multiple workspaces on my machine. My understanding of workspace is basically a folder that contains all of my projects (even unrelated ones). For example, C:\Projects
I currently have a single workspace that is called the name of my computer which points to a directory called C:\Projects that has several projects in it that are each their own project on visual studio online. For example: DESKTOP-43DDV90P has a working folder for each project inside of it.
WORKSPACE: DESKTOP-43DDV90P
Source Control Folder: $/Project1, Local Folder C:\Projects\Project1
Source Control Folder: $/Project2, Local Folder C:\Projects\Project2
I would like to know if this is a correct assumption OR if I should be creating a workspace per project like the following:
WORKSPACE: PROJECT1-WS
Source Control Folder: $/Project1, Local Folder C:\Projects\Project1
WORKSPACE: PROJECT2-WS
Source Control Folder: $/Project2, Local Folder C:\Projects\Project2
When I finish setting everything up with a new ASP.NET Core web application under source control my directory structure looks like the following:
C:\Projects\Project 1
this contains:
Project1 (folder vs creates for solution)
BuildProcessTemplates (folder from vs online)
C:\Projects\Project 1\Project1
this folder contains:
Project1 vs solution file
Project1 (folder that finally takes you to the project1 site files)
A TFS workspace is basically an account between your computer and the TFS server. It contains a set of ServerPath -> Local Path mappings, and some settings about how the workspace is maintained (e.g. permissions, file timestamp behavior, etc).
Often when working on a project you'll end up creating branches. This is when workspace mappings become relevant. If you don't have branches, then you'll usually just want to map the entire codebase - i.e. you want all of the sources. But when you do have branches, often you'll want only one branch at a time. For example, if I have this:
You can see how each branch contains the same set of files. If I'm developing something in the FeatureX branch, eventually I will merge it into the Master branch.
This is when your question becomes most relevant: do I have a workspace that contains both of these, or do I have separate workspaces for each branch? This is a matter of preference. I prefer to have separate workspaces, because it avoids the case where I've made changes in multiple branches and only want to check in changes to one of them. For example:
I might not notice in a larger project that I have modified files from two different branches. TFS does allow this, but usually when I'm working in one branch I don't want to affect another one. Another issue that can occur is that TFS sometimes has issues when merging changes if one of the included changesets spans multiple branches. For example, say I check in the pictured change; then I create a new branch (Feature2); then I merge the changeset into Feature2. What should happen? Does it take the copy that I checked into Master or into FeatureX? You can make this work, but the point is that you can also fall into some weird situations. With multiple workspaces, I would only ever see changes for the branch pertaining to that workspace:
That’s depending on your situation, company policy etc… It’s hard to manage if there are too many mapping in a workspace, if not, a workspace is ok.
Some articles about optimize that can help you:
Using multiple workspaces with Visual Studio
Optimize your workspace
I have Team project in TFS, and I map it to folder "Common projects" with many projects inside, by example
Common projects
prj1
prj2
..
prjn
TFS adds all of them and it slows my machine. I want to unmap most of them, but if I make "Remove mapping" for prj1, it also deletes its folder physically from my hard drive. Is there a way to map projects in mapped folder selectively, and leave other on harddrive? Or I need to create separate folder especially for synchronization with TFS..
upd.:
I update my post with answer as I understand from google that people searching the solution.
Step 1: File-> Source control-> Advanced-> Workspaces-> Remove, click "No" when popup dialog appears. But after this on next random "Get"(on other project in other folder) - files will be deleted from local, becouse TFS "remembers" associations even they are removed from Workspace. To prevent it - step 2:
p.s.: try it on Your own risk, make backups and tests.
You are looking for something called Cloaking. By using cloaking, you can map a root folder to a local workspace. As you've noticed, this implicitly downloads all the sub folders beneath the root folder.
When you now select a sub folder you don't want, you can select Cloak. This means that the sub folder (and anything beneath it) won't be downloaded to your pc.
The MSDN topic Optimize your workspace has the info you need. If you look at the example, you want to perform step 2 and 4.
OK, so one or more of the references required that the solution be in C drive. I cut-pasted the solution from one folder in D drive to another in C, and bam, all TFS bindings went down the drain.
I've changed my workspace local folder to point to my new folder, so I'm not sure why TFS doesn't recognize it. OK, I admit I was working without TFS connection for a period of time, but now I would like to get some changes checked in. But when I go to File -> Source Control -> Advanced -> Change Source Control, it tells me that the Status for my .sln and .proj files are all Invalid.
I've tried unbinding and rebinding projects but this doesn't seem to work.
This is frustrating. Is there any other way than to delete and re-download the entire solution? Or is this a caveat of TFS, is there any file on my hard drive that defines my solution location? It's 10GB worth, I don't want to need to do this every time I move my solution, especially when I actually have all the files on my hard drive.
If I understand you right, you had your sources connected to TFS on your D: drive. For some strange reason you needed to move them to C: drive and you did this by using Windows Explorer (or any other not TFS related tool)? After that you changed your code and now want to check it in to TFS, but it denies it. Right?
The problem is that TFS didn't got any information about your moving and changes you made in the new location. This only works if you used "local workspace" setting when creating the workspace or if you changed your workspace to the new location and checked out the files there.
How I would "fix" this:
Copy/save your current code changes in a temp folder
Open VS/TeamExplorer and create/change your workspace to the location where you want your sources on C:
Do a "Get Latest Version" on your workspace, to download the sources from TFS and to update the workspace in TFS
Checkout all files in your workspace (checkout root folder with recursive option)
Copy your saved code from step 1 into your workspace
check in your changes (check in on root folder of workspace again with recursive option)
your sources are now linked to and stored in TFS
Under "Tools-> Options-> Source Control -> Environment -> Saving/Editing" set the value to check out automatically, so that VS will to the checkout for you automatically when changing a file in VS.
I have a seemingly common problem, but cannot find a common solution that will work for me. I recently had my computer re-imaged and am now in the process of redownloading a solution from TFS. One of the solution folders contains 2 folders that list "Not downloaded" in the "Latest" column of the Source Control Explorer. When trying to open the solution, I get the error "The project file could not be loaded. Could not find file x". I've tried the methods listed below, to no avail:
Get Specific Version, checking Overwrite options
Deleting, .suo file, restarting VS2010
tf get /force
Remove mapping, deleting local files, remapping entire TFS project to local folder
tfpt rollback /changeset where the last changeset for the .csproj listed a branch and a merge as pending changes by me
File -> Source Control -> Open from Source Control, Navigate to TFS project, try to open .csproj in undownloaded folder, receive error "The selected file cannot be opened. The project file has been moved, renamed or is not on your computer."
I may be missing other things I've tried, I'll be sure to update this list if I can think of anything.
Besides those listed above, is there any other way to get those 2 folders and their content from TFS?
Try browsing via visual studio command line to the directory and do a:
tf get . /force /recursive
This should forcibly recurse down from the current directory.
You have tried most of the things that I would suggest. A force-get-latest should work if it's a simple case of TFS being confused about what is on your pc.
Are the "folders" in tfs, or in your solution explorer? Folders in the solution explorer typically mirror the real disk structure, but it is possible to get files and folders in a different location in the SE than on disk. This coild mean that the files the solution explorer is referencing are not mapped into your tfs workspace.
I would check the workspace mapping is as simple as possible (no branches or extra unneeded folders etc), close the solution, force-get the latest version of the disk structure from the source control view, and then load the .csproj file in a text editor to check exactly what the project is referencing to be sure that all the files exist and are in sensible places on disk.
I found the problem. I recently added a certain domain group to the TFSProject/Readers TFS group, then explicitly denied access to all rights in those two folders. It seems that although I am in the Contributor TFS group, I'm also a "Reader", so I denied access to myself.
2 projects under TFS Source Control.
DependancyProject.sln
AppProject.sln
With AppProject referencing DependancyProject.
-
The issue I have is with an Installer project in the AppProject.
It has DependancyProject.dll as a 'reference'(?) where it tries to include it in the GAC.
When I try to build this project, to create an MSI to install the App, I get the error
The item $/Assemblues/DependancyProject/bin/debug/DependancyProject.dll is locked for check-out by USER in workspace HIS-PC-NAME.
(The PC in question is not dead and not used)
The dll is not (as far as I can see) checked into Source Control.
The path it references anyway does not exist when I browse through it (no bin folder).
The DependancyProject is refernced by pretty much every project in Source Control, and i've never had any issues with it.
It builds, all the other projects build.
It's just this one Installer Project which doesn't.
And I can't see why it would need to try and modify it anyway.
All it needs to do (I'm assuming) is make a copy of it.
Any ideas here?
Some files are configured as "non-mergeable" in TFS, which means that they'll be locked when changes are pended on them. The default list includes a variety of binary files, including .dll files. Note that this lock applies to all pending changes - including adds.
It's likely that the other developer in question accidentally pended adds for his bin directory - and any binary files in that directory (ie, most of them) would have been locked as well due to being in that unmergeable list.
You will not be able to pend other changes (including an add in a different workspace) while these items are locked. To break this lock, the other developer can do this by undoing the pending changes, or a server administrator can do it using the Find in Source Control functionality in the Team Foundation Server Power Tools.
That said, I don't know why your build process is trying to pend an add on that file.
I had the same problem, and this guide solved all my problems.
The file was actually locked by me, but in a different work space (old computer).
Had to use the tf undo command to unlock the files.
If you are not going to use that workspace again, you can delete it by going to workspace pull down, selecting workspaces, and enabling the check box "Show remote workspaces". you can then select it and remove it.