As I looked forward to my weekend, Team Foundation Server(TFS) 2013 devised other plans. I chugged along making changes in the code, and then hit issues when I tried to queue new builds.
The error included the following message. You can view a screenshot below.
This took me on a wild goose chase to here, here and here. None of these touched the issue in any meaningful way. A coworker of mine mentioned that it might be a space issue on the TFS server machine. I logged in to find the infamous blue pie of disk space.
TFS 2013 leverages IIS to communicate with the client, check in code and queue builds. With developers whacking at TFS day and night, it didn’t take much time for the IIS logs to grow to
The size allocated for the drives never took this into account. In this case, the machine had a whopping
50 GB C drive. The IIS logs gobbled up the extra space until no one could write to the C drive.
To put out the fire, I deleted the IIS logs and watched TFS spring back to life. I came up with the following preventive measures going forward.
- Increase the drive size to
- Configure IIS to put the logs on a different drive
- Disable IIS logging for the time being
- Create alerts to track the space on all drives for that machine
Automating deployments can save you a great deal of headaches and even trauma in some cases. However I found it disappointing when I actually tried to put the best practice of automating deployments into practice.
I needed to make a backup copy of the production folder and then overwrite the live copy with the tested copy from the QA environment. Much to my dismay, I couldn’t find any publicly available and publicly licensed PowerShell scripts to do this job.
I created the below module to do just that.
- Backup folder is datetime stamped in a consistent manner
- Makes troubleshooting simpler
- More straight forward rollbacks
- Different domains necessitated the use of
New-PSDrive. It does still work on the same domain though.
- Excluding the web.config to preserve environmental configuration/differences.
- Delete backups older than 7 days so your infrastructure team doesn’t have to ask you why the drive is full.
Disclaimer: I don’t recommend a solution that contains projects targeting different versions of the .NET framework. However there are legitimate cases (e.g. inherited code), that demand solutions rather than a rewrite. You may decide to use a later version of the .NET framework than some of the existing code. If you mix these projects in the same solution and use the same nuget packages in different projects, you will get the following error.
MSBuild builds your solution in an order that determines dependencies but leaves the rest to chance. When nuget package references are resolved, they include the .NET version. By default MSBuild builds the solution into a single output directory. This means that if project A references package X and targets .NET 4.0 and project B references package X and targets .NET 4.5 then the last one to be built will overwrite the previous one’s package X dll. This will cause the build to fail.
But fear not, there is a solution.
Update the Output Location
- Edit the build definition
- Navigate to
4. Output Location from to
Yay! Our build works again, but our unit tests won’t be run as part of the build.
Update our Test Run Settings
- Edit the build definition
- Navigate to
- Go to
1. Automated Tests
1. Test Source
- Click the ellipse on
- Add ..\src\*\bin\*\*test*.dll to the default
Test assembly file specification which is
This important step instructs msbuild to look for unit tests in the source directories bin folders in addition to the standard single bin for the solution.
Now your tests will actually get run as part of your build.
- StackOverflow: Using AsConfigured and still be able to get UnitTest results in TFS
- Override the TFS Team Build OutDir property in TFS 2013
QA and Development
departments team members coordinate at many points along the software development life cycle (SDLC). Part of this communication revolves around deployments, which often take the form of an e-mail that includes information from Team Foundation Server(TFS). To achieve success, multiple points need to be communicated.
- When – It needs to be clear when a deployment is finished and the environment is ready for testing
- What – The stories/Product Backlog Items (PBI’s)/Bugs that are included in the build
- Where – The environments that will be changed and/or updated as a result of the release
The below script will lookup the provided items in TFS, update them and send relevant information in an email. I highly recommend using distribution lists for emails like this. It facilitates people subscribing and unsubscribing without updating the script.
In this example, the person executing the script would need to enter the PBI’s that are going to be deployed. Then the script will query TFS to retrieve the relevant information to include in the e-mail (Id, Title, Type, Iteration, Assigned To). In our case, part of the deployment included assigning the stories/PBI’s/Bugs to a QA user for clarity and historical record. To prevent mismatches between the e-mail and assignment, the script updates the AssignedTo for each provided item.
The output of the query comes in a tab separated vector (tsv) format. The TsvToHtmlTable function converts the output from tsv to something (aka html) that looks decent within an email. The endpoints listed in the e-mail remove guesswork about where to find the environment and perform testing.
For me, investing the time and energy into these communications helped foster trust and collaboration between Dev and QA. I hope it helps you achieve the same, if not more.
You might have heard that it’s a
good idea best practice to use gated check-ins. It seems like a no-brainer to make sure that your code at least builds and passes the unit tests. TFS 2012 has the ability to setup gated check-ins, what luck. You set it up and the sun and shining and birds are singing.
Oh happy days. Then one day, you see this.
Short Term Fix Alert
More than likely your Product Owner (PO) didn’t select anything for the sprint that included debugging gated check-in issues. However you committed to finishing the work that you can’t now check-in. If your build fails with a similar error, do yourself a favor and try cleaning out the local(on the build agent) nuget cache.
This will actually solve the issue….for a bit. The birds sing but appear kind of nervous.
Swing and a Miss
Then the issue returns. You think hey “Maybe there’s something to all that stuff about different versions.“. Then you look at your solution and notice different versions of the same Nuget reference. For me, it was Newtonsoft.Json. All the projects are referencing the same version of the .NET framework (note: Client Profile vs regular is a significant difference).
Project A had Newtonsoft.Json.6.0.8 and Project B had Newtonsoft.Json.7.0.1. I upgraded both to reference Newtonsoft.Json.8.0.2. While I recommend consolidating your nuget package versions, it did nothing to actually solve the problem that I was having.
Dealing with the Real Issue
This zombie error just won’t stay down. When you really need to commit a changeset, you will be revisited by this error.
The root cause of the error was the Library.Test project that referenced the Library project. I inspected their references and noticed that while Library had a reference to NLog (which I highly recommend) but the test project did not. This gave me an idea. The solution was to add NLog to the Library.Test project.
It would’ve been greatly appreciated if that were mentioned anywhere in the error or better yet if a compiler error were generated before even running the unit test. Now the birds can sing carefree once again.
Thank you to Nova Southeastern University(NSU), all sponsors, speakers and volunteers for putting on a great SQL Saturday #379. Met lots of passionate people that showed how much of a community we have in Broward County. I attended the following sessions and talked to lots of people about Code for Fort Lauderdale.
DH2i & DxEnterprise Stand-Alone to Clustered in Minutes
This was a vendor session for DH2iworks across multiple SQL versions and OSes. It was a very interesting session, particularly for a developer less familiar with virtual environments (at least standing them up, configuring, updating, feeding, watering, etc.). I know that for me, it introduced the following new and/or less familiar terms.
- quorum – the minimum number of members of a deliberative assembly. In the context of Clustering and High Availability, it is minimum number of nodes that must be in a cluster for it to be viable.
- InstanceMobility – The ability to move an instance of a virtual machine across physical machine boundaries
- SAN – Consolidated block level storage (as opposed to file level storage). Only block level operations are supported.
- Internet Small Computer System Interface(iSCSI) SAN – Allows for the emulation of a SAN over IP networks
The DH2i & DxEnterprise works across multiple SQL versions and OSes. Microsoft Clustering is not designed for Quality of Service(QoS). I was impressed by the demo given showing how to build out a 2 node cluster. You can see the steps below.
- Create individual nodes
- Add the disks
- Create a vhost
- Set the two nodes to be active on this vhost
In the demonstration, one node was running Windows Server 2008 R2 and the other node was running Windows Server 2012. He explained how this simplifies implementing a non-traditional cluster(different OS/SQL versions). As an added benefit, it provides a way to perform a consistent install on each node.
- Wikipedia: Storage area network
- Wikipedia: iSCSI
PowerShell and Python – The Clash Part Deux
Below is a comparison between Python and PowerShell.
- Powershell is installed by default.
- Politically correct to use PowerShell
- Can instantiate .NET classes
- “Steal from the Best, And Create the Rest”. Chad Miller is better than you, see for yourself on CodePlex.
- PowerGUI Script Editor
- Easy to learn
- Very good support for windows
- has modules for everything
- has “batteries included” philosophy
JetBrains makes an outstanding Python editor called PyCharm. In python, indentation is equivalent to brackets. You can use python to call sqlcmd.
There is a great video from Jeff Snover, PowerShell Creator, that you can watch. You can find the presentation here.
PowerShell with Visual Studio SQL Data Tools
Florida PowerShell User Group
Max demonstrated how to debug PowerShell with Visual Studio and use many of the data tools available. There were big changes between versions of powershell (2-5).
- SAPIEN is editor of choice.
- PowerShell Studio 2012
“I can do it. You can do it!” -Max
Let me start off by stating that Nuget, FluentValidation and Identity Manager are all great tools. Unfortunately their mutual greatness doesn’t prevent issues from arising.
Having a beta version of one nuget package (e.g. Identity Manager) and trying to update an independent package (e.g. FluentValidation). You run the Update-Package command only to be greeted with the following
You can view a screenshot of this below.
The solution is to use the -pre flag in addition to update-package. However I still don’t understand why updating one package depends on an unrelated one.
To Nuget’s credit, they have this issue and it should be included in an upcoming release.
I needed to automate a full deployment of all my services, databases and the client that consumed them frequently.
I am using an on premise installation of Team Foundation Server (TFS) 2012 and Visual Studio 2015. I needed to leverage multiple builds since msbuild arguments (the ones that you use to automatically publish/deploy) apply to every project/solution being built. This can potentially lead to multiple different builds.
Fortunately, this can be accomplished using PowerShell. TFS provides a good useful well-documented interface.
Below are some helpful references that I found on my way to the above solution.
I recently started working with a different TFS instance and version only to discover the script produced the below error. I have updated it accordingly.
- TFS Build API by Example #1: Queue a build.
- Queuing TFS Build from Powershell Script Which is Called from TFS Build
- Queuing a build in PowerShell
- relative path in Import-Module
- Powershell import-module doesn’t find modules
- How to set a custom tfs build parameter using powershell
I had the following peculiar bug with the way Model Errors were presented in the view for my ASP.NET MVC 2 website. The code for the view is below.
You can see the ordering of the fields is First Name, Last Name, Name and Phone. As you can imagine, the validation messages should reflect this ordering. However I was getting the following output instead.
This isn’t a show stopper issue, but it is the kind of things that customers notice (and good QA people). After registering, users add more information at this screen. For this reason, it should be as elegant as possible to keep them coming back. I assumed this would be an easy fix. I’d just go to the validation code and fix the ordering of the errors.
You can see from the code that it is yielding the validation errors the same way that I would like them to be presented. As it turns out, this didn’t make a whole lot of difference. Then I realized that the validation code was not the issue at all.
The errors are displayed in the order that the properties are listed in the mode.
I’ll give you a moment to allow that to sink in. It’s an issue that is difficult to diagnose but easy to rectify. The original model property ordering below outputs the incorrect ordering.
The model should appear like below to achieve the desired user experience.
Once you make that change, the errors display like below.