The nightmare before Christmas … RESOLVED #ALM #TFS

I have to say, the last month and a half has been quite a challenge and I think I’ve never seen a project go in any direction like I’ve seen this one going… But I saved Christmas … once again (and the twitterverse won’t be so happy, cause now there’s time again for that: SORRY TWEEPS :-) )

The reason why there was radio silence is that I’ve been battling a ferocious dragon : a 2 headed language beast which consisted out of a 68 projects-large solution (C#and C++). Battling this on the field of both packages, dependencies, but most of all on the field of inconsistent environments and bad TFS installs. Unfortunately.

Why am I writing this down you say? Well there’s 2 reasons: first of all I just wanted to vent all my frustration on a product which I love so much, but this time I had no power of and second of all to give some tricks to people struggling with the same issues somehow (#sharingiscaring is still my motto! )

This entire project is based on a TFS 2010 implementation, for TFS 2012 I get to redo this next year … sigh :-)

Key takeaways from this project:

• when doing build automation on TFS for combined (or plain) C++ (unmanaged and managed :-( ) and C# solutions keep in mind following TFS system requirements:
  • install the build system in following order
    • TFS Build controller / agent with the lastest SP and fixes / patches
    • install Visual Studio 2010 with all languages (elseway C++ WILL NOT BUILD)
    • install the Windows SDK
    • install Visual Studio 2010 SP’s
    • NOTE : whenever having following issue :  “MSB4019: The imported project “(DRIVE)(PATH)Microsoft.Cl.Common.props” was not found.” when the drive and path are pointing to a different folder tahn the one where all .NET an VS stuff is installed –> abandon the server and redo your installation, for mostly things CPP are missing
  • Native building (C++)  : try to have a 32bit system only as a host when building for 32 bit systems, it simplifies life a lot (i know it’s ugly …)
  • when doing combined building, make sure you do a good amount of tweaking in your build configuration management)
    • have your C++ build with Win32
    • and have your C# build with x86
    • this applies when doing builds for unmanaged C++ only (my guess is that the managed part is still “managed well” by TFS
  • reason is that unmanaged C++ doesn’t cope to well with TFS hosted on x64 environments apparently (it can not differentiate 32bit sources from 64bit sources)

so with this done, i can go and enjoy the Holidays!

Merry Christmas and a APP-y New Year

TFS Building

Did you ever encounter build issues on TFS refering to an error like the one below and not inside your IDE:

sourcedir\codefile.cs (297): ‘namespace’ does not contain a definition for ‘X’ and no extension method ‘Y’ accepting a first argument of type ‘Z’ could be found

(are you missing a using directive or an assembly reference?)

If so, this has to do with the MSBUILD Target Engine , it’s not well documented at first and you get the impression that it is a permissions issue or related.

What you need to do to resolve this is, open the build definition, navigate to the process tab and change the MSBuild Platform to the X86 version. this occurs most of the time when assemblies are not able to compile toward x64 architecture.

TFS 2010 + SQL Server 2012 = a no go (for now)

I was setting up a demo environment with SQL Server 2012 , Sharepoint 2010 and TFS 2010 (not DEV11)     To my surprise there seems to be no support for SQL 2012 when it comes to SSAS and SSRS: so no Reporting integration part when doing an advanced setup. Unfortunately I was not able to find an official statement on the matter or even a solution.

So far the system requirements only state SQL 2008 R2 SP1 tops , so implicitely no SQL 2012 yet. http://msdn.microsoft.com/en-us/library/gg265786.aspx