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.
Related
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 am using Roslyn for application scripting via Nuget Package Manager. Setup should be rather simple. Create new project and, in Nuget manager, add Microsoft.CodeAnalysis.Sripting package. After couple of confirmations you are ready to go.
Next step should be checking for installed packages update. Currently, there are 5 updates that are shown after initial installation. Again, it is pretty straightforward to do this.
However, immediately after the update, two of those packages show yellow triangle in Reference node of the project.
I have tried to resolve this following SO and other hints but nothing helped me so far.
At the end, I have installed new VM with Windows 10 Pro (with all updates) and VS2017 Community Edition. After that new Windows Forms project (.net 4.6.1. based for x64) was created and scripting package is added. Unfortunately, yellow triangles are still there (after update).
Problematic packages are System.ValueTuple and System.Security.Cryptography. X509Certificates.
Also, after cleaning and rebuilding the solution, a number of warnings (MSB3836) - explicit binding redirect on "System..." conflicts with autogenerated binding redirect.
Solution to this problem might shed a light on problem with more complex solution that I stumbled upon after migration to VS 2017.
So, what is the reason for such behavior? Remember, this happens on new installation of OS and VS with simplest project possible.
Visual Studio 2017 Communnity Incorrectly Updates Roslyn Scripting
I got the same result with you steps. This issue only occurred on the Visual Studio 2017 not Visual Studio 2015. That should have some issue with package Microsoft.CodeAnalysis.
To resolve this issue, I would like provide you a workaround:
Update packages "System.ValueTuple" and "System.Security.Cryptography. X509Certificates" first, then update other packages.
It works fine on my side, you can check if it works for you.
In order to track this issue, I have create a new issue on GitHub:
https://github.com/dotnet/roslyn/issues/22290
If you have additional information to add, you can add comments below that issue. And you can check the feedback from this link.
We're running a German TFS 2013.4 on premise and want to move to Visual Studio Online. The OpsHub migration tool stops with a template mismatch.
I ran the TeamProjectManager tool (https://teamprojectmanager.codeplex.com/) and compared our template to the VSO template. The fields are there, but their names are different, one is German and one is English ("Fehler" vs "bug").
Would it be possible to convert our local TFS to English? It's a single-machine installation running in a VM, so we can take a snapshot and just try it. We don't have any customizations, but TFS was upgraded several times, all the way back from TFS 2008. I read somewhere that might leave behind some obsolete fields, which can also cause problems.
I'm not certain, but I believe you would still have to rename your Work Item types even if you changed your server to English.
Do you need the history in VSO? Would it suffice to export TFS Work Items to Excel, map the fields and import to VSO? Obviously version control history would not be carried over either but you would still have the on-premise archive.
The TFS Integration Tools would likely do the job but they are NOT fun to use.
https://visualstudiogallery.msdn.microsoft.com/eb77e739-c98c-4e36-9ead-fa115b27fefe
*Sorry, this would have been a comment rather than an answer but SO wouldn't let me add one.
I've installed the OpsHub VSO Migration Utilty and I'm trying to migrate one of our smallest projects as a test.
Having created a new matching project in VSO the migration validation fails on the template mis-match.
The existing TFS 2010 project is based on the MSF for Agile Software Development v5.0 template and the new VSO project is MSF for Agile Software Development 2013.3
As far as I'm aware, neither of these templates have been customised.
For each work item types the mismatched fields are:
RelatedLinkCount
AreaID
AttachedFileCount
HyperLinkCount
ExternalLinkCount
IterationID
Installed version of the utility is v1.1.0.005
Any help would be gratefully received.
Between TFS 2005/2008 to TFS 2010, the process templates were updated to add an additional space in the display name of each of the fields you mentioned. Since that's the case, you can take some easy steps for a workaround and then re-run the OpsHub Visual Studio Online Migration Utility.
You'll want to use the witadmin.exe tool and specifically the changefield option. Here are the steps you'll want to take to change the display names of each of the fields to include the spaces:
witadmin.exe changefield /collection:http://tfs.contoso.local:8080/tfs/DefaultCollection /n:System.RelatedLinkCount /name:"Related Link Count"
witadmin.exe changefield /collection:http://tfs.contoso.local:8080/tfs/DefaultCollection /n:System.AreaId /name:"Area ID"
witadmin.exe changefield /collection:http://tfs.contoso.local:8080/tfs/DefaultCollection /n:System.AttachedFileCount /name:"Attached File Count"
witadmin.exe changefield /collection:http://tfs.contoso.local:8080/tfs/DefaultCollection /n:System.HyperLinkCount /name:"Hyperlink Count"
witadmin.exe changefield /collection:http://tfs.contoso.local:8080/tfs/DefaultCollection /n:System.ExternalLinkCount /name:"External Link Count"
witadmin.exe changefield /collection:http://tfs.contoso.local:8080/tfs/DefaultCollection /n:System.IterationId /name:"Iteration ID"
Give those a try and I hope it works out for you as a workaround!
OpsHub unfortunately need to fix this, or you can use a different tool.
When you try to do a migration the OpsHub tool compares your Process Template between the two projects and throws its toys out of the pram if they are not the same. In your case your 2010 server once was either 2005 or 2008. In TFS versions prior to 2010 the fields that are conflicting did not have spaces, from 2010 on they do... Hence the mismatch.
There are other, less nanny state, ways to migrate but they are much more complex.
TFS Integration Tools - this tool is free, supported by Microsoft, but is increadably complex. It was built for consultants working with enterprises to move TFS data around. Not fun, but can be made to work.
Excel migration - you can just use excel to move the tip of work items and move the tip of TFVC source. Or move to Git in VSO and use Git-TFS to move with history for source.
Hire someone (admission / ALM Consultant talking) - Most of the ALM MVP's are consultants and have tools to move your stuff.
I would suggest that #1 and #3 are of similar cost at the end of the day, and #2 tends to be unpopular.
Check out the migration guidance from the ALM Rangers.
Because that is exactly our scenario (TFS2008 > TFS2010 > VSO) and we also got the error during migration of work items with OVSMU from TFS2010 to VSO I was willing to give the workaround described by Ed a try.
To have it more convenient I tried not from command line but with Visual Studio 2012 from the menu Tools: Process Editor: Work Item Types: Open WIT from Server.
First try was work item type Task. After change of all relevant names I was asked if I wanted to save changes to the item. After pressing Yes I have got the message window:
"Microsoft Visual Studio: Work Item Type: Task
TF26177: The field System.IterationId cannot be renamed from 'IterationID' to 'Iteration ID'.
There were validation errors. Continuing to save may cause the file to become unloadable, do you want to continue?"
Do you have some additional advice for me to bring it all to the point where I can migrate the work items?
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.