VS 2012 - Check-in, work item association type is not defaulted to Associate

Question

The registry entry used in vs 2010 to change the default work item association type on a check-in from resolve to associate doesn't seem to work in VS 2012 RTM.  Is there a new way to make Associate the default?

in VS 2010

[HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\10.0\TeamFoundation\SourceControl\Behavior]
"ResolveAsDefaultCheckinAction"="False"

Tried this in vs 2012

[HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\11.0\TeamFoundation\SourceControl\Behavior]
"ResolveAsDefaultCheckinAction"="False"

Answer 1

Hi David_Stanley,

Thanks for your post!

Please refer to this blog:http://blogs.msdn.com/b/mitrik/archive/2010/12/03/how-to-make-associate-the-default-action-for-work-items.aspx

In TFS 2012, It is fixed this experience so that you won’t need to hack the registry to change the behavior.

Hope it helps!

Best Regards,

---

Cathy Kong [MSFT]
MSDN Community Support | Feedback to us

Answer 2

Thank you for your response Cathy.  I have read that post before.  Unfortunately it doesn't seem to be reality.  In VS 2012 Pro RTM, my work item association still defaults to Resolve, just as it did with Beta and RC.

Answer 3

I guess I should have noted that this is VS 2012 connecting to TFS 2010.  I don't know if it matters because this should be a client option, but figured I should add it.

Answer 4

Hi David_Stanley,

Thanks for your feedback!

It doesn't matter with what version of TFS. I tried to connect to TFS 2010 with VS2012, under the Pending Changes in the Team Explorer in VS2012, the

The action that you want associated with the work item has changed default to the "Associate", please refer to the following picture:

Hope it helps!

Best Regards,

---

Cathy Kong [MSFT]
MSDN Community Support | Feedback to us

Answer 5

Hmmm...  seems like I may need to report as a bug.  I will reply again when I know more.  I wonder if this has to with the fact that I have installed Beta > RC > RTM.  I know it was "supported" but might still be the cause.

Answer 6

I performed a full uninstall of VS 2012, including a couple beta thing that appeared in the Uninstall Programs window.  I also deleted everything under the HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\ 11.* from the registry just to be sure.  I then reinstalled VS 2012 and tried the pending changes again.  It still defaulted to Resolve.  I then ventured back into the registry and found that the HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\11.0\TeamFoundation\SourceControl\Behavior\ResolveAsDefaultCheckinAction value was there and True.  I altered it to False and restarted VS.  I again tried the pending changes and again found Resolve was the default action.

This is VS 2012 Pro RTM, on Windows 7, connecting to TFS 2010 SP1 on a Windows 2008 R2 server.

The new Pending Changes window is painful enough that out of my coworkers that have installed VS 2012, I am the only one even trying to use VS 2012 to checkin.  The rest are still using VS 2010 to perform check-ins. 

I went over to one of them and had them associate a work item in their VS 2012 Pending Changes window and found that he too has it default to Resolve.  He didn't have the Beta or the RC installed, so it seems that is not the issue.

Answer 7

Hi David_Stanley,

Thanks for your feedback!

I test many times and I found that, if the work item state is "Active", no matter what edition of VS 2012 connect to TFS 2010 or TFS 2012, the checkin work item action is default as "Resolve". If the work item state is set to other type, such as "Colsed" or "New" or "Proposed"(In TFS 2012), the checkin work item action is default as "Associate".

Because the state of work item is "New" in my previous test, so the checkin work item is default as "Associate" in my second reply.

Hope it helps!

Best Regards,

---

Cathy Kong [MSFT]
MSDN Community Support | Feedback to us

Answer 8

This may answer some of the questions, but it still doesn't help.  If what you say is true, they have reduced functionality of VS from 2010 to 2012.  The ability to change the default from resolve to associate, even though it took a registry "hack" was a godsend.  Now that seems to not even be an option.

I honestly don't know how any TFS user could be happy with the changes for VS 2012.

I guess I still hope that someone is able to provide a work around. 

Answer 9

Hi David_Stanley,

Thanks for your feedback! 

I am trying to involve someone familiar with this topic to further look at this issue. There might be some time delay. Appreciate your patience.

Thank you for your understanding and support.

Best Regards,

---

Cathy Kong [MSFT]
MSDN Community Support | Feedback to us

Answer 10

Thanks for the update Cathy.

Answer 11

Checkout this link here http://msdn.microsoft.com/en-us/library/ms194965(v=vs.110).aspx

Basically whats it is saying on a given work item type there is an action on work item transitions called "Microsoft.VSTS.Actions.Checkin". When you checkin code the source control system looks at the current state of the workitem your associating with the checkin. If any tranition from this state has a checkin action associated then it will move to that given state as the default action.

The solution is to remove this action - this is then for all users of TFS

Regards

Gary Howlett

Answer 12

Also dont forget you need the Process editor to perform the above available in the power tools....

http://visualstudiogallery.msdn.microsoft.com/27832337-62ae-4b54-9b00-98bb4fb7041a

Answer 13

Thanks for your reply.  I have actually seen this suggested too, for 2010 before the registry change was well known.

That would mean modifying work item types in multiple team projects that have custom changes.  I don't find this an acceptable solution.

Everything to date so far in this thread points to Microsoft wanting to make Associate the default, but there being a bug.  I will continue waiting for Cathy to escalate the issue.

Answer 14

Hi David_Stanley,

Thanks for your feedback!

I have escalated this issue, there might be some time delay. Appreciate your patience.

Best Regards,

---

Cathy Kong [MSFT]
MSDN Community Support | Feedback to us

Answer 15

Hi David,

I checked into this and the idea of the change is to default to the last selection you made.  I think I am seeing the same behaviour you are seeing in that it is locked into one choice.  I will check again once everyone is back in the office after the holiday.

Thanks,

Brad

---

This posting is provided "AS IS" with no warranties, and confers no rights

Answer 16

Thanks.  Looking forward to hearing back.

Answer 17

I would also be interested in having this problem fixed.

Thanks

Answer 18

Cathy or Brad, Any update?  Thanks.

Answer 19

To clarify, the change they made in 2012 is simply to default to the last resolution chosen.  If within you workitemtype you have only one choice, this will not change that.

This talks more about changing this in the Scrum template:

http://blogs.msdn.com/b/aaronbjork/archive/2010/12/17/marking-tasks-and-bugs-as-done-during-a-check-in.aspx

Thanks,

Brad 

---

This posting is provided "AS IS" with no warranties, and confers no rights

Answer 20

Thanks for getting back to me Brad. We are using the TFS 2010 Agile 5.0 template.  The workflow has not been changed for the task, at least not for the active status.  If we select Associate and perform a check-in, the next time we add a task work item to the pending changes window the default is to Resolve.

Answer 21

Hi,

Any ideas for a workaround?

I have the same scenario as David: TFS2010 + Agile template + VS2010 preparing to migrate to VS2012 and the developers are heavily relying on the default action that is set to "associate" through the registry hack.

---

Daniel

Answer 22

No, no good solution found.  I got tired of messing around with it and team members complaining so I went into the work item template and removed the resolve check-in action.  It then started defaulting to Associate.  You can find info on how to do it in Howlett's post above. I modded it up as helpful, I am not going to flag it as the answer because this can't be working as intended. 

I wish MS would address this.

Answer 23

Hi All,

It turns out there is one "extra" step to set the default action to Associate. 

First set the registry key to False:

HKCU\Software\Microsoft\VisualStudio\11.0\TeamFoundation\SourceControl\Behavior\ResolveAsDefaultCheckinAction

Then close VS 2012 and from a VS 2012 command prompt run:

Devenv /setup

Restart VS 2012

Let us know if this helps!

George

Answer 24

Thanks, I will try this out using a non-modified team project and follow up.

Answer 25

This does not seem to resolve the issue.  I have the registry entry set to False.  I shut down VS 2012, ran the "Developer Command Prompt for VS2012", entered "devenv /setup".  I associated a work item in an upgraded 2010 > 2012 agile project.  The default was Resolve. I changed to associate and performed a check-in.  I performed another checkout and then check-in.  When associating the second time it the default was still Resolve.  I just did it the second time to rule out the "selecting last as default" thing that Cathy mentioned.

Answer 26

I was reading this interesting thread today.

Any further updates from MS on this?

---

j_bond

Answer 27

+1 Thanks David, I really enjoying reading your questions, that was very helpful one!

---

Visual Studio ALM MVP | ALM Consultant
Blog | MSDN | Stackoverflow | Twitter | YouTube | CodePlex | TFSEG | MEA-ALM| LinkedIn
 
 

Answer 28

I raised a visual studio user voice request to enable associate as a default option in VS 2012 team explorer. http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/3418758-in-the-team-explorer-change-default-state-value-o Please vote . Thanks. 

---

http://twitter.com/suresh2

Answer 29

Setting the registry key to false and running "Devenv /setup" works for me when the work item is set as "In Progress Work" under "My Work"; when I check in, the work item is set to Associate.

Does not work if just adding Related work item by ID, though.

Answer 30

The registry key update followed by the devenv /setup from the command shell has worked for me....

Thanks George!

As Geir notes you'll need to drag items into your "My Work" area first for this registry hack to do its magic, this seems like a bind to begin with, but it's actually "My Work" a really neat feature. It transitions the task to in progress, plus it gives you a one click "suspend" feature to shelve and retrieve work to date... very handy if you get interrupted from development to deal with a critical bug instead.

Lastly, by adding tasks to "My Work" - they all funnel across to the pending changes window ready for check in.

Neat.

 

---

Paul Dowman, CRM Developer

Answer 31

This is a bad design I think.

Sadly, until now they didn't fix this.

---

Take a look at WPF FlashMessage
About.me