I've created a new iteration in TFS 2010 and wan't to use it in a new story and query.
However, the iteration won't show up in the new story window, refreshing VS, restarting VS, switching to other project, nothing helps.
I'm a project administrator in the team project, and created the iteration with the same user that i'm trying to use it with. Permissions are not changed from default.
Tested on other workstation with other user with sufficient permissions also doesn't help.
Could I be doing something wrong?
Make sure "Team Foundation Background Job Agent" is running on the server hosting your TFS instance and it is running under a service account. See http://msdn.microsoft.com/en-us/library/ms252450.aspx for more information.
A little bit late but we encountered the same problem.
I tried to restart the "Team Foundation Backgroud Job Agent", without any effect.
But I found a solution, although I am not sure if it is a bug or not.
We are using the Scrum Template for this project, and I have not checked this with any regular Project Template but I quess it is the same. First add the desired new iteration by right clicking on the TFS project and selecting the "Team Project Settings" -> "Areas and Iterations...".
On the Iteration Tab, we have now 2 iterations (at least in our case) with multiple sprints within these iterations. You can add a sample Iteration if you have only one Iteration
After moving the new Iteration downwards, so its new position is beneath the existing Iteration, I was able to see and select the new Iteration in my Team Query. If the new Iteration is already beneath another Iteration, simply move up the new Iteration
This may be a bug, or the use of the Scrum template might interfere with any sync process but the above method worked for us.
In my situation this was caused by an alphabetization issue. In my Iteration Setup I added '2.11' at the bottom of the iterations and then looked in a Work Item and couldn't see the new iteration.
Turns out the work item template was sorting alphabetically and not obeying the Iteration setup. So my iteration was always there, it was just between '2.1' and '2.2' instead of where I expected to see it.
Related
So, new to .NET Core and going slow. Followed a standard tutorial for ASP.NET Core MVC app using Entity Framework to connect to MSSQLLocalDB - this went well.
Converted the application to connect to MySql, and went equally well,
Changed the name of a table on MySql to Interests from Interest, and after a bit of fiddling around this to was put to bed, that is it was working as expected.
Went to run the application today and I get:
There were Build Errors Would you like to continue and run the last successfull build.
Code has reverted to Interest, from Interests in several places in Obj files,
for instance "Create.cshtml.g.cs"
Corrected the code and went to run, the same build error pops up, and all corrections are undone.
I make the changes again, save the files, exit VS, reload, the changes are as they should be, run and it reverts all changes, failing again.
I thought this might be some sort of cache issue so deleted the obj folder, again corrected the entries, but again run the build and the corrections reverted!
I solved this issue on my machine by changing the cshtml file properties. Right click the chstml file in the Solution Explorer window, click on Properties in the context menu.Then in the Properties window, change the "Copy to Output Directory" to "Copy if newer". Then make sure "Build Action" is set to "Content".
I have written a Sharepoint workflow that starts automatically when an item is created. It has two stages. The first stage sets a yes/no field to yes. then transitions to stage 3(Got rid of stage 2). The workflow gets stuck in stage 1. Any ideas?
The workflow might require the item to be checked out before it can update the yes/no field.
It would helpful to know what version of SharePoint you are running, along with how the workflow was created, (e.g. Designer or Visual Studio)
I don't want to use only Tasks in TFS Some times a Bug or a backlog Item are so small that there is no need to create tasks underneath it. HOw do i automatically make it Mark the Item as done in tfs when i check it in.
There is no way for me to make it relative in this case. Because it is a backlog Item as opposed to a Task.
Does anyone have a way to make this work?
If you use visual studio to checkin then it asks for a comment and a work item to associate with the checkin. There is a area where you can provide the state of workitem as Resolve or Associate after this checkin happens you can put the state to resolve it would mark the item as done.
Why would my VS solution lose its TFS bindings suddenly? I have been working on a project for six months and this never happened. As soon as I opened a VS project/solution, I could check in/out, view history by right clicking on any given file. But suddenly, I dont see those options to checkin checkout etc any more when I right click on a file in VS studio solution explorer.
The team explorer window still brings up the source folder structure and I can get latest or get specific from there but did any one see this kind of behavior? Please let me know what I can do to avoid these situations in future.
Did you lose connection to the TFS server any time recently? I've had this happen in the past on unreliable network connections when working via TFS remotely. The solution and all projects therein would "go offline" and would appear to lose their bindings. This made it particularly unintuitive when the connection was re-established because changes made while "offline" weren't always found.
If you right-click on the solution or the projects, is there an option to "go online"? You might check the various menus for such an option as well.
Did you move the source files to a different location on your harddrive, or change your workspace mappings?
Try opening the solution/project by double-clicking the .sln file in Source Control Explorer instead of opening it from windows explorer.
You can also try bringing up the Bindings dialog by going File -> Source Control -> Change Source Control
I recently had a very similar experience. I had made several changes which I thought may have influenced my connection resilience. After reversing out of 2 of them and the problem persisted, I finally clocked what it was.
One of the new extensions I am using is NuGet (http://nuget.codeplex.com/). Every time I attempt to add a library my TFS connection fails and is unrecoverable till a restart of VS 2010.
See: http://nuget.codeplex.com/workitem/725
There is a work around that has been reported and working which may help you even if this is not your problem.
see http://blog.rthand.com/post/2011/08/26/Fixing-combination-of-NuGet-and-Team-Foundation-in-workgroup-configuration-401-Unauthorized.aspx
Happened to me also. I was removing a whole bunch of mappings for old releases under the local workspace. It was taking over 40 minutes so I killed it. The mapping has been removed to the older branches but the branch left behind had been disconnected from TFS.
Is there a way to Link a WorkItem to a Label. Under "All Links" when I create a new WorkItem in Visual Studio I can select many diffrent Link Types, like Changeset, VersionedItem, etc, but theres no type for Label.
The reason why I want to do it is, that I label my releases (like Version 1.0, Version 1.1) and I want to associate a Bug to a specific version of my software.
Isn´t it support to link a WorkItem to a Label or how should I associate a Bug to a version of my software?
Update:
I´m following the Single Team Branching Model (one Dev and one Main branch) documented in the Visual Studio TFS Branching Guide 2010.
You cannot link to a label. However you can achieve your goal in other ways.
First of all, I suggest to use branching instead of labelling to keep track of multiple released versions. In my opninion using branches is a better mechanism then labelling. See also the branching guidance on codeplex
To link your bug to a version of your software, use the Iteration Path in the work item. This field is exactly for that purpose.
Using iteration path field is one option and it gives you the ability to track a work item between versions.
But if you want higher resolution, there is another way:
Team Build marks source code with a label before every build. The bug item type in CMMI project template contains fields called "Found In" and "Fixed In". In these fields you can select from build labels.
Use of these fields allow you to mark any work item with two specific builds. One for when it was found and one for when it was fixed.
Additionally Team Build updates "Fixed In" field of every work item with the label of the build, after the build completes successfully and all tests are ran without a problem.
If you don't have these fields on your work item type, you can always add them using the work item template editor that comes with TFS Power Tools.