Keep those Versions Straight!
I had been pulled away from the TFS project for a week to help out on another and finally was able to get back to TFS. My client has a Framework they wrote that is a mix of CSLA, Microsoft Enterprise Library and custom code. I have that building successfully so I had moved on to the Application itself. I made some extensive changes to how the referenced DLL's work (including the aforementioned Framework) - so I did that all manually after removing the bindings to source safe.
So I go ahead and add the solution to TFS Source Control and create a build type and BOOM I get a very bizarre error:
Target "CoreCompileSolution" in file "C:\Program Files\MSBuild\Microsoft\VisualStudio\TeamBuild\Microsoft.TeamFoundation.Build.targets" from project "c:\TFSBuild\5\BuildType\TFSBuild.proj":
Using "WriteLinesToFile" task from assembly "Microsoft.Build.Tasks.v3.5, Version=3.5.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a".
Task "WriteLinesToFile"
C:\Program Files\MSBuild\Microsoft\VisualStudio\TeamBuild\Microsoft.TeamFoundation.Build.targets(978,5): error MSB3491: Could not write lines to file "c:\TFSBuild\5\Sources\Steriworks\Main\Source\SteriWorks.sln.Debug.vsprops". Could not find a part of the path 'c:\TFSBuild\5\Sources\Steriworks\Main\Source\SteriWorks.sln.Debug.vsprops'.
Done executing task "WriteLinesToFile" -- FAILED.
Googleing the problem brought me to this blog post by our friendly neighborhood Magenic TFS guru Steve St Jean: which explained the error - but a symptom caused by different reason. What's going on here is that the Build was trying to create a vsprops file in the solution directory - but this directory is read-only (needless to say - coming straight from the Source Control) so it "blowed up real good". But the question was why?
Digging into the "C:\Program Files\MSBuild\Microsoft\VisualStudio\TeamBuild\Microsoft.TeamFoundation.Build.targets(978,5): " was even stranger. Here it is:
<!-- Generate the VCOverride file for C++ projects -->
<WriteLinesToFile
File="$(VsPropsFile)"
Lines="$(VCOverridesOpen) OutputDirectory=%22$(OutDir)%22%3E%0D%0A$(VCOverridesCodeAnalysis)$(AdditionalVCOverrides)$(VCOverridesClose)"
Overwrite="true" />
Well, my project isn't a C++ project and furthermore the variable there refers to Code Analysis which I'm not using (at the moment at least).
So I decide to branch the code (Ah such TFS goodness - that's something always to be avoided in VSS), start whacking parts of the Solution to find out what's causing it. I start to do that and then go to create a new build type when I realize:
I had created the build type in Visual Studio 2005!
My client is still using VSTS2005 for their development. Several of the developers are still on Windows 2000 (they skipped XP and are migrating from Win2K to Vista) and haven't decided when they want to take the plunge to 2008. But since we started the TFS project after Team System 2008 was RTM we decided to use the 2008 Version of TFS.
So when I am working on the source code in Visual Studio - I need to use VS2005 - but when I do some customization for TFS - I need to use 2008. However the Icons are the same - (I changed on my desktop - but on the Task bar - they are the same) - so it can be tricky keeping which one is straight. I knew that you couldn't "queue" a TFS2008 build from VS2005 - and I never intended to create the build type in VS2005 - but I did Obviously, this is another incomparability between 2005 and 2008 as far as creating Build Types are concerned.
So I deleted the Build Type, recreated in Visual Studio 2008 and presto! The error went away!
Now to get the build to work! (It's broken - but at least it's errors I expect to get at this point in the process)
What's going on here is that the Build was trying to create a vsprops file in the solution directory - but this directory is read-only (needless to say - coming straight from the Source Control) so it "blowed up real good". But the question was why?
Digging into the "C:\Program Files\MSBuild\Microsoft\VisualStudio\TeamBuild\Microsoft.TeamFoundation.Build.targets(978,5): " was even stranger. Here it is:
<!-- Generate the VCOverride file for C++ projects -->
<WriteLinesToFile
File="$(VsPropsFile)"
Lines="$(VCOverridesOpen) OutputDirectory=%22$(OutDir)%22%3E%0D%0A$(VCOverridesCodeAnalysis)$(AdditionalVCOverrides)$(VCOverridesClose)"
Overwrite="true" />
Well, my project isn't a C++ project and furthermore the variable there refers to Code Analysis which I'm not using (at the moment at least).
So I decide to branch the code (Ah such TFS goodness - that's something always to be avoided in VSS), start whacking parts of the Solution to find out what's causing it. I start to do that and then go to create a new build type when I realize:
I had created the build type in Visual Studio 2005!
My client is still using VSTS2005 for their development. Several of the developers are still on Windows 2000 (they skipped XP and are migrating from Win2K to Vista) and haven't decided when they want to take the plunge to 2008. But since we started the TFS project after Team System 2008 was RTM we decided to use the 2008 Version of TFS.
So when I am working on the source code in Visual Studio - I need to use VS2005 - but when I do some customization for TFS - I need to use 2008. However the Icons are the same - (I changed on my desktop - but on the Task bar - they are the same) - so it can be tricky keeping which one is straight. I knew that you couldn't "queue" a TFS2008 build from VS2005 - and I never intended to create the build type in VS2005 - but I did Obviously, this is another incomparability between 2005 and 2008 as far as creating Build Types are concerned.
So I deleted the Build Type, recreated in Visual Studio 2008 and presto! The error went away!
Now to get the build to work! (It's broken - but at least it's errors I expect to get at this point in the process)