I have a smallish utility library I made that I had created in TFS Beta 2 to test out TFS. I now have TFS rc1 installed(and Beta 2 uninstalled) and am trying to add my Solution to TFS.
I get an error saying that it is already bound to my old TFS, which was on a different system then this one. Strangely, when I go into Source Control and look at the bindings it says there aren't any. Also, I manually deleted the .vss and .vsc files and it still does it.
Ideas? I looked through the numerous other SO topics related to this but unless I missed one none of them are dealing with my issue.
Ideas?
Grab the TFS Sidekicks from Attrice. They have a workspace sidekick, you can pretty quickly find your old machine and unbind/delete that workspace from TFS.
Once you install:
VS Menu Bar
Tools
Team Foundation Sidekicks
Workspace Sidekick
Owner will defult to you, just clear machine name
Search
Select old workspace, click the red X to delete
I had old server entries too and I fixed it by using the workspace sidekick mentioned here and then using the command line to get the rest that the tool couldn't find.
Related
I have VS 2017 Pro and have a number of projects in the default path C:\Users\jjacobs\Documents\Visual Studio 2017\Projects\
I just started Team Source from my company MSDN subscription. I chose Team Services rather then GitHub. My last version control system was Visual Source Safe. VSTS is totally alien to me.
I have a worthless project in VSTS called MyFirstProject. How do I remove it?
Thank you.
You need to go to https://{your-domain}.visualstudio.com/_settings/projects, hover over the project you would like to delete, click the three dots that appear, then select delete.
I had deleted a project from VSTS and would like to use the same name again for my project but when I try to create the project, I get this error:
All of the desktops that this message is referring to are gone e.g. old employees, virtual desktops, etc.
How do I get past this error? I'd hate to retire a project name because of old desktops or ex-employees that will never access this project again.
UPDATE:
When you know what you're doing, everything is easy and questions like mine are frowned upon, so much so that someone suggested this post should be closed. Very nice!
So, I'm told both TFS and VSTS work the same way and I should go learn what I need to learn from the other post. According to the linked post, I need to go run TF command which according to the answers is located in Visual Studio 20xx/Common7/IDE folder. I go there and TF.exe is NOT there. I then start searching my computer to locate this executable and my computer can't find it. I then Google it and here's what I see on Microsoft's documentation. What gives?????
Regarding VS2017, the Tf.exe is in C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\CommonExtensions\Microsoft\TeamFoundation\Team Explorer, you also can call TF command in Developer Command Prompt for VS 2017.
On the other hand, you also can remove workspaces through Visual Studio directly (Manage workspaces and check Show remote workspaces option)
I have an ASP.NET MVC 4 application. I used NuGet to update all of the NuGet packages that were installed when I created the application. One of the packages was Microsoft.Bcl.Build.
After updating these, NuGet displayed the following message at the bottom of its window:
I have since restarted Visual Studio several times, but the message still exists. When I checked the installed packages, it did appear that the updated version (1.0.8) of the package was present.
How can I fix this?
Instead of deleting all of ~/packages, see if there are any *.deleteme files in ~/packages and delete them. Then restart Visual Studio.
I believe this problem is caused by the packages being read-only or otherwise inaccessible at the file system level.
Packages under source control
Temporary work-around (untested)
Check out the entire packages folder prior to telling NuGet to restart Visual Studio to delete the packages.
Permanent work-around
I found that this could be permanently resolved by removing the packages from source control and instead using NuGet Package Restore.
Packages not under source control
Temporary Work-Around
I worked around this by deleting from the solution's packages folder all of the files that referenced the package in question. Specifically, these were:
Folder: Microsoft.Bcl.Build.1.0.7
File: Microsoft.Bcl.Build.1.0.7.deleteme
In my case, the relevant package folders remained in ~\packages, although they were empty. I deleted the folders and restarted Visual Studio, and this warning went away.
I've just deleted the folders of each package that had error in the Packages folder in my solution folder and also deleted the .deleteme files and everything works fine!
1) Delete the entire ~\packagesfolder.
2) Restart VS.
3) Go to Manage NuGet Packages and Restore
I'll agree that this can happen when your packages folder is under source control. If you like to have it there, instead of removing the bindings you can check it all out, remove the package with the NuGet Package Manager, and then check in after wards.
In my experience, I found my answer on this thread, but using a combination of a couple of different answers above so I thought I would share what I found.
I had the exact same issue with "Microsoft.Bcl.Build" as the original poster. I had been trying to update references for other functionality using NuGet and had issues with some of the updates (compatibility then rollbacks). After this NuGet failure, I started getting this error.
I initially used the selected answer and Jedidja's answer and was able to get this to work, but it only partially solved my problem. It did fix the VS restart error, but it caused a downstream issue with TFS as I could no longer check in the project as it was expecting that "*.deleteme" file. This got me thinking, so I did some testing. When I restored the file from recycle bin, I started getting the restart error again.
Here is where I deviated from the posted answers and got my full resolution to my version of the problem.
When I checked into TFS this time, the project checked everything in (after I got the projects all updated using NuGet while the "*.deleteme" file was deleted). Once it checked everything in, I noticed that file was still pending check-in so I checked the solution in again and TFS accepted that file, but it was as a deletion....assuming it checked in the first time and then VS auto deleted it which required the second check-in. Anyway....after the last pending change check-in, the file was gone and VS no longer complained about needing to be restarted. I can't say for sure because the problem is gone, but I get the feeling if I had checked the code in before deleting the file in the first place it might have solved the problem without manual file manipulation.
** Hi, everybody.**
i resolve this problem this ways.
If you have source control run the vs as administrator ( it is important )
in the solution packages -> delete thing about packages.
sample -> i deleted all entity framework version folders.
restart the vs
open solution and solution right click -> manage nuget packages for this solution.
you will see restore button :) restore
that is all.
If you are using Entity Framework 6, then you can install the NuGet package "EntityFramework.SqlServerCompact".
This enabled me to use the standard ASP.NET Identity tooling that comes with the project templates for 2013 and MVC5.
I'm using Vim on a Mac for front-end development and was recently hired at the company that uses Team Foundation Server as their version control system.
I would hate to have to switch to using Visual Studio on Windows because I'm so used to Vim and the Mac.
I found this and was hoping that would be a possible solution. I would still like to avoid editing code in Eclipse. However I wouldn't mind opening Eclipse to do version control stuff.
I'm very unfamiliar with Eclipse and Team Foundation Server (not VCS in general) and I need some advice on how to actually use it.
I'm able to connect to the server and find the project I have to work on, but from here I'm lost. This is the window I'm stuck at.
Anyone who are in a similar situation and could offer some help?
You've done the hard bit I think, firstly you should be able to safely ignore the Work Item and Build "folders" unless someone explicity tells you to use work items, at which point they can show you what you need to know as it works exactly the same as in Visual Studio.
If you double click on the Source Control folder it will open a new window which will show you the source "tree". To be able to Get, Checkout and add source files to the tree you'll need to set up a workspace. Once you've done this then you can get the code and check out.
With Team Explorer Everywhere You also have the option of using the tf command line in the Mac terminal. This would eliminate the need for eclipse. (I'm assuming that as a Vim user you're not afraid to use the terminal)
Another option might be svnBridge however I think you need the server version if you're using a Mac, and this requires a site to be installed in the TFS application server which might not be an option.
Finally TFS now offers support for integration with GIT.
Someone left the organisation but before leaving, he locked all the files for an unknown reason.
How do you unlock them all so that the other developers can work?
For the following operation, you will need to be either a project administrator for the project you want to undo the check-in on or a Team Foundation Administrator if you want to do this across all projects.
If you still have the username of the person, you can simply do something like this:
Open up Visual Studio command prompt (Start -> Programs -> Microsoft Visual Studio 200X -> Visual Studio Tools -> Visual Studio 200X Command Prompt)
Run the following command:
tf lock /lock:none
/workspace:WorkspaceName;USERNAME
/recursive $/
To get the list of workspaces for a user, just run the following command from the same prompt:
tf workspaces /owner:username
For more commands, check tf /?
If the developer has left the organization, then the best thing to do is to delete their workspaces. This will unlock the files for you but also free up some resources on the server.
See the following blog post I did on the topic when it happened to me a few years ago.
http://www.woodwardweb.com/vsts/unlocking_files.html
You can either delete the workspace using the command line (tf.exe) or you can use the excellent TFS Sidekicks from Attrice.
This was the only way I resolved this, which involved deleting the user's workspace.
If the error message says "The item $/... is locked for check-out by someUser:1 in workspace someMachine123." then I use the command:
tf workspace /delete /server:http://machinename:8080/tfs/DefaultCollection someMachine123;someUser:1
There is just a single space between the collection URL and someMachine123;someUser:1.
Note that I payed attention to the fact that the error message mentioned the user as someUser:1, so I mimicked that in the command. It was not enough to just run the command with someUser only. I'm not sure what the :1 is all about but point being, mimick the error message.
Note the server has to be the fully qualified collection path, which you can find by going to Team Foundation Server Administration Console->Application Tier->Team Project Collections, the bottom pane will show a URL for the collection that is selected in the upper pane.
I also had a problem because I accidentally tried to use plural workspaces instead of just workspace because there is a similar command that is plural.
first you need to have the right to do this. If you have that the easiest is to use TFS sidekicks from attrice http://www.attrice.info/cm/tfs/
Here's an explanation of using TFS permissions.
Having the "Unlock other user's changes"
permission set to Allow is required to
remove a lock held by another user.
I needed to add /collection:collectionURL otherwise the workspace could not be found:
List item
tf loc /lock:none /workspace:WorkspaceName;UserName /collection:collectionURL
Have a system administrator reset that users password, log on as that user, unlock all files...
I would think this is the solution to almost all 'someone who is no longer at this organization' questions...
It is better to delete the workspace of that user from the server. example
tf workspace /delete /server:your_tfs_server workspace;username
Sometimes this is masking an different problem with a completely different application is locked by another user, but you cannot even create a New Folder for the new project you wish to merge into ( target won't allow the creation and incorrectly stating that someone has a file locked in their name) but then you dig deeper and another project is the culprit.
So a completely different project can be the problem with it having files locked by someone else.
Method that worked for me, my account has administrator permission on TFS and project :
In Visual studio 2015:
Go to Team Explorer
Click right on your solution and choose Open in source control
exporer
On left side click right on your solution
Choose Advanced
Choose Lock...
On left side click right on your solution
Choose Advanced
Choose Unlock (Now you can choose unlock)
Right now, every dev can easily commit his changes :)
by using TFS permissions,
Open up Visual Studio command prompt,Run the following command:
tf undo /workspace:workspaceName;DomainName\UserName $/file path in your solution
Use this solution as the very last resort.
I’m using TFS 2012. I went to the TFS database and ran the following queries. And it worked! Of course be very careful when messing with the database, take backups, etc.
The database is called Tfs_<<your_TFS_collection_name>>. Ignore the Tfs_Configuration MSSQL database. I'm not sure but if you don't have a Tfs_<<your_TFS_collection_name>> database, settings might be in the Tfs_DefaultCollection database. Locks are stored in tbl_PendingChange.LockStatus.
/*Find correct row*/
SELECT LockStatus, PendingChangeId, *
FROM tbl_PendingChange
WHERE TargetServerItem like '%<<fileName>>%'
/*Set lock status to NULL (mine was set to 2 initially)*/
UPDATE tbl_PendingChange SET LockStatus = NULL WHERE
TargetServerItem like '%<fileName>>%'
AND PendingChangeId = <<PendingChangeId from above>>