Value was either too large or too small for a UInt32. TFS Error

I got this error in Visual Studio 2015 checking in to TFS.
“Value was either too large or too small for a UInt32.”

WTF? Turns out it is because I had an open sql query file that wasn’t saved and it get angry.

Really stupid error that should read :” You have an saved file, please save all files before checking in”

Wow. That would have taken the developer a small minute. Oh yeah, this is probably an unhandled exception, caught higher up and presented to us as an amazing insight into what was wrong.

Anyway, Save All before checking in and you will be fine.

Happy Coding!

How to unshelve a shelveset from one branch into another branch!

I was doing a lot of work in our Main branch for a new version of our software. Lo and behold, this iteration requires we work on both the future and current version at the same time. Only a few of us are on the new version, therefore the Main branch code branched into a future version branch. Ugh. All my work sitting in a shelveset for the Main branch.

Moving it sounds painful to me. Luckily there is a really cool automated method provided by TFS. You simply need to deal with playing with the command line.

This guy did a good job giving an overview:

This guy was easier for me to read:

tfpt unshelve - Unshelve into workspace with pending changes

Allows a shelveset to be unshelved into a workspace with pending changes.
Merges content between local and shelved changes. Allows migration of shelved
changes from one branch into another by rewriting server paths.

Usage: tfpt unshelve [shelvesetname[;username]] [/nobackup]
[/migrate /source:serverpath /target:serverpath]

shelvesetname The name of the shelveset to unshelve
/nobackup Skip the creation of a backup shelveset
/migrate Rewrite the server paths of the shelved items
(for example to unshelve into another branch)
/source:serverpath Source location for path rewrite (supply with /migrate)
/target:serverpath Target location for path rewrite (supply with /migrate)

Here is an example I used in action:

tfpt unshelve "Native Templates Work" /migrate /source:$/Source/Main /target:$/Source/Main-6.0

Happy coding!

Visual Studio 2010 Crashes/Disappears when getting latest from source control(TFS)

We use Visual Studio 2010 with Team Foundation Server for our projects. It seems that when I get latest after there were a large number of changes, VS just disappears.

No event log entry. No crash report. Just the handy feature of auto closing after getting latest.

Bizarre and annoying.

If you have any ideas on why this is happening, that would be great. Otherwise, this is just a rant.

Note: I am sure have 127+ projects in our solution doesn’t help with stability.

Happy Coding!

How to ignore whitespace formatting in merge conflicts in TFS in Visual Studio 2010.

Hate when you see all Blue because someone reformatted the code?

Fix it.

In Visual Studio, select Tools / Options / Source Control / Visual Studio Team Foundation System and click the Configure User Tools button.

In the dialog, Add an item with the following settings.

  • Extension : .*
  • Operation : Compare
  • Command : C:Program FilesMicrosoft Visual Studio 10.0Common7IDEdiffmerge.exe
  • Arguments : %1 %2 %6 %7 %5 /ignorespace

If you are 64 bit,

C:Program Files (x86)Microsoft Visual Studio 10.0Common7IDEdiffmerge.exe




Happy Coding!

TFS Corrupt Cache: Team Foundation Server just won’t let go of stale data

Does your Team Foundation Server work items get a little stale and not want to refresh? Your queries stop working right?

Your manager wondering why you aren’t taking on the new critical tasks assigned to you?

Well, you may be a victim of the TFS corrupt cache.

Simple fix:

Run the following after shutting down all Visual Studio instances.

del /S /F %userprofile%local settingsapplication datamicrosoftTeam Foundation*.*

Hopefully this gets you out of seeing the same old thing over and over.

Happy Coding!

The cost of a code freeze and maybe a better way of doing it.

The cost of a code freeze

So you’re thinking about doing a code freeze in your company, or maybe you already are. This article discusses the pros and cons and potential solutions to the common pitfalls.

A “code freeze” is general the period of time in which developers of a team based software development project are barred from the check-in of code into the source code control repository. Code freezes are used as a way of obtaining a clean version of code for preparation of a release. A lot of companies use these for internal build releases as well that are generally provided for the Quality Assurance department.

Is a code freeze a good thing? Well, maybe. Conceptually it sounds like a great idea; tell all developers to hold off on the check-in of code for a set period of time while a build is prepared off of the active development branch of the source control system. Proponents of the standard code freeze argue that the lock down period of time is necessary in order to properly create a build that is functional. The issue that arises is really around the length of time the code freeze is truly in effect. If the standard build and assurance process lasts a few hours, the impact is relatively negligible. If in turn the process takes a day or longer, then the impact to the development cycle is truly felt.

The impact of the denial of code checkins on an active project is dependent on a number of factors; the size of the team, the lack of source code isolation of the distributed tasks, and the velocity of the tasks.  These variables interact in a non-definitive but potentially exponential way. The higher any of the values are, the more the value of the other variables affects the cost. For example, the more developers there are on a project the greater the impact of higher velocity and lack of source code isolation on the tasks.

Say you have X developers, they work on code with an isolation level that has a probability of interaction of Y (likelihood a developer is working on a section of code another developer is also working on), and they are working on tasks at a velocity of Z. Let us also assume the code freeze occurs for H hours. The variable interaction would be similar to H * ((X2 *  Z) * Y. While the math on this particular equation is very loose and up for debate, the potential impact is obvious. We can determine the true impact if we were to take on an actual experimental situation (or really put a lot more thought to it than I did) to find the actual impact.

What the above is basically showing is that the cost of the code freeze increases the longer it lasts and is dramatically more when a larger number of potential interactions (developer activities) are introduced.

What can be done about this?

The code freeze employed by some companies is the hold all code and wait until a valid build is created from the development/active branch of the source control system. The implied benefit is that developers can check in code ONLY to fix the actual build process and get the initial assurance verification tests to complete successfully. The cost of this particular method is generally not worth its benefit.

An alternative to this particular cycle is to use a form of the Branch by Purpose pattern (“The Importance of Branching Models in SCM.” IEEE Computing Practices. 0018-9162/02.) recommended by Walrad and Strom which dictates that you create source branches when the code in the branch will be used for a particular purpose; a bit self explanatory in nature. This method allows you to have a code freeze for only the period of time it takes to snapshot the branch. You can then build your releases of the branch. The developers will encounter minimal impact due to the brevity of the code freeze and defects can easily be fixed in the secondary branch and merged back into the main branch if necessary.

The utilization of my interpretation of this pattern is quite simple. The source control is created with a main/active development folder to house the current iteration of source code. You then create a quality assurance branch which you use to send copies of the main/active branch when you need to create builds to send off to the quality assurance team. This format allows the development team to continue on with work while the build team uses the QA branch to produce the QA builds. Any code changes to fix the process would be made in this branch and merged back to the main branch.