Gated Check-In

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.

birds-in-a-nest

Oh happy days. Then one day, you see this.

C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Microsoft.Common.targets (1605): The primary reference "\bin\Library.dll" could not be resolved because it has an indirect dependency on the assembly "NLog, Version=4.0.0.0, Culture=neutral, PublicKeyToken=5120e14c03d0593c" which was built against the ".NETFramework,Version=v4.5" framework. This is a higher version than the currently targeted framework ".NETFramework,Version=v4.0". C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Microsoft.Common.targets (1605): The primary reference "\bin\Efile1Library.dll" could not be resolved because it has an indirect dependency on the framework assembly "System.IO.Compression, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" which could not be resolved in the currently targeted framework. ".NETFramework,Version=v4.0". To resolve this problem, either remove the reference "\bin\Efile1Library.dll" or retarget your application to a framework version which contains "System.IO.Compression, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089".

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.
Install-Package_NLog
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.

 

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s