Visual Studio 2008 SP1 and upgrading a BizTalk 2006 R2 project to BizTalk 2009 Project - Failing - visual-studio

Greetings all,
I have posted this on the MSDN managed news groups as well as a BizTalk site, but I am not sure they get enough traffic that as I don't seem to be getting a response.
Help me StackOverflow, your my only hope.
I am in the process of upgrading our Visual Studio BizTalk projects from BizTalk 2006 R2 to BizTalk 2009.
I start VS 2008 SP1, load up the VS 2005 solution with all our VS 2005 artifacts in it, and the Visual Studio Conversion Wizard starts. All good to here.
The wizard properly reports that the projects which will be updated. These look good. I press Finish and the conversion tool goes and does its conversion thing. The wizard reports that all projects have been converted successfully, However when I view the conversion log, it says that none of the BizTalk projects were converted. If I expand the node on of the non-converted projects, there is no error information as to why it didn't convert.
The two biztalk projects in the solution (the others are c# projects) are both greyed out and VS.Net 2008 says they are unavailable.
If I then right click on the project and select "Reload" the conversion wizard comes up again, this time it asks to create a backup before converting. I select yes to the default location and hit Next. It tells me it's ready to convert, when I hit Finish I get the nice little dialog window:
The operation could not be completed. Unspecified error.
If I look at the conversion log this time, I see the error: Conversion Issues - your.project\your.project.btproj: Error converting project file. Child element <BIZTALK> of element <VisualStudioProject> is not valid.
There are a couple of posts on the net about this issue but no concrete resolutions:
http://dennismulder.net/cs/blogs/dennism/archive/2009/04/25/trouble-migrating-from-biztalk-2006-r2-to-2009.aspx#comments
http://msdn.microsoft.com/en-us/library/dd257156.aspx
The msdn article mentions the project needing a solution file, so I can't see how that applies as the project is already part of an existing VS 2005 solution.
Does anyone have some ideas/thoughts on this? If I have to, I can resort to just creating new BizTalk projects and re-adding the BizTalk artifacts to them, but we have a number of solutions which will need to be converted and if there is a simple fix to get the conversion wizard to work, I would rather go down that route.
Thanks in advance all.
cmb..
** Update - 20090806 **
After some cutting and pasting of .btproj files I have determined the upgrade wizard does not like the fact that I renamed my project build name from Development to Debug

Greetings,
Ok, I openned an incident with Microsoft about this.
Basically the issue in my case came down to the fact that I renamed the build configurations from Development and Deployment to Debug and Release (to match what every other Visual Studio project calls their build configurations). Apparently, the upgrade wizard for BizTalk, doesn't like this very much.
Anyways, Below is the summary email I received from the support engineer at Microsoft about what the problem is and how to fix it. It comes down to hand tinkering with the .sln and .btproj files. Alas..
The default configuration names
(Development and Deployment) for
BizTalk project should not be
modified. Up to BizTalk 2006 R2 it was
not a “true” integration of BizTalk
project systems with the visual studio
in many ways. For that matter, from
supportability point of view, changing
the default configurations is not
recommended. However, you can add your
own configurations without altering
the default configurations. Also it is
not supported modifying the BizTalk
Project template files for Visual
Studio.
In your case, you have re-named the
default configuration names to some
other values. Because of this change
entries for those configuration were
not appearing in the metadata under
various VS files. I tried playing
around with those setting and
eventually with following steps got
the project upgrade working for the
sample project that you provided.
For solution file under GlobalSection(SolutionConfigurationPlatforms)
= preSolution section I did not see entry for default Development
configuration. Added following entry
there Development|.NET =
Development|.NET (here we need default
entries for deployment and
development)
For solution file under GlobalSection(ProjectConfigurationPlatforms)
= postSolution I did not see entry for default Development configuration.
Added following entries there
{3B54116C-9D09-4DAF-9AFD-62EDA64AC12A}.Development|.NET.ActiveCfg
= Development|.NET {3B54116C-9D09-4DAF-9AFD-62EDA64AC12A}.Development|.NET.Build.0
= Development|.NET (here we need default entries for deployment and
development)
For project file under section did not see section
for default Development configuration
Added following entry there (here we need default entries for deployment and
development)
Delete user options file (as it is not needed for the upgrade process –
VS will create the one when you open
the project)
Opened the project on BizTalk 2009 VS 2008 box. Upgrade process is
successful.
The GUIDs are specific to BizTalk
project files. If there are multiple
BizTalk project as a part of the
solution, you have to add the entries
for default configuration for each and
every project in the solution.

can you confirm whether or not you have checked the readonly attributes on all files in the project.
i had the same problem because it was trying to convert a file that was under source control, exactly as laid out in that one link u provided.
after removing the source control bindings i ran the conversion again and it worked

Found this issue when I searched for the current problem I have with BTS09/VS2008 which is I can't add BizTalk projects to a solution, what is going on anybody know about this one
I have been wittering on about the conversion problem since the launch of BTS09/VS2008 nobody seems to have taken me seriously I believe Dennis Mulder was going to raise the issue with Microsoft but haven't heard anything back. As you have found the Microsoft response is just not worth bothering about, if you are converting from BTS06 to 09 then it's a fair chance you will have a sln file, also removing the source control elements didn't work for me either, I actually opened a solution in vs2005 removed all the source control elements and save the solution, then did a conversion to vs2008 didn't work. One very interesting point one of the solutions I tried converting, some of the BizTalk projects did get converted some didn't, spent hours trying to see where the differences once again to no avail. You obviously can create new solutions/projects and add the in the relevant artefacts to these projects BUT WHY should we need to do this, this to me could be a potential showstopper in organisations that have many or large solutions to convert.
Microsoft needs to take this problem seriously and come up with a solution.
My take on this is that it really highlights how many people have moved to BTS09 NOT A LOT if so then I am sure there would have been a resolve to this by now.

Jim,
There are few things. From Dennis Mulder blog post and comments, it looks like Dennis problem is sorted by removing the source control bindings. He is not going to raise a support ticket with MS, he suggested you to open one if required.
In the MSDN page http://msdn.microsoft.com/en-us/library/dd257156(BTS.10).aspx it clearly states the supported migration path is only from BizTalk 2006 R2 to 2009. There is no support from BizTalk 2006 to 2009.
To address your very first line "I can't add BizTalk projects to a solution", Are you able to create new simple BizTalk projects in VS 2008 without any issues?The reason I'm asking this is, there is a chance you might have installed BizTalk and VS in wrong order. It may be worth reinstalling just the developer components of BizTalk Server.

This problem exists in 2010 also when migrating 2006R2 solutions to BizTalk 2010.
I have found a method that works with the least amount of effort possible. It does not require two environments (old and new) but does require the original, unconverted solution-files to work.
http://justbizzie.blogspot.com/2010/10/migrating-biztalk-2006r2-sources-to.html
Let me know if this is also good when migrating to 2009. I expect it to be :)

Related

Can open MVC4 solution in VS2010, but not in VS2012

Looked through some similar questions, could not find one that fits my case.
I have a solution that I created some time ago in VS 2010 (maybe originally in MVC2), and eventually upgraded to MVC4.
The solution works properly when opened with VS 2010, builds and runs - everything as expected.
To confirm that I use MVC4, I checked the properties of my System.Web.Mvc.dll. It appears to be 4.0.0.0
From this I assume that I have MVC4 successfully installed on the machine.
However, when I try to open the solution with VS 2012 I get the following infamous error
Full text:
Unsupported This version of Visual Studio does not have the following
project types installed or does not support them. You can still open
these projects in the version of Visual Studio in which they were
originally created.
- Recipes, "C:\ ... Copy\Recipes\Recipes.csproj"
I can also create a new MVC4 project using VS 2012, so I'm assuming I don't lack any tools VS 2012 needs.
What else could be the problem?
There's probably an entry in the <ProjectTypeGuids> element of the .csproj file that VS2012 doesn't recognize. I have a vague recollection there was some tooling identifier change but I can't recall specifically.
My suggestion would be to create a new project from scratch and then compare the <ProjectTypeGuids> elements in each .csproj file to try to figure out which one from the VS2010 project it doesn't like in VS2012. It's likely going to require some trial-and-error tweaking of the list so make a backup of the file first so you don't get yourself into a situation where you can't open it at all.
If you don't want to take that approach another option would be to create a new empty project and then import the individual files from the old project into the new, but that could obviously be quite time-consuming if it's a large project.

the application for project is not installed

I'm opening a solution that was apparently built on Visual Studio 2003 (not sure, I don't know anything about it) and trying to migrate to 2010. When trying to migrate I get the message:
the application for project '' is not installed make sure the application for the project type (.csproj) is installed.
If I open each one of the single projects of the solution they migrate fine but not the solution itself.
Right-click on the project file, then "Reload"
If your solution opens, but your project is showing as "incompatible", it may need to just reload. This worked for me when running an update from VS, and it did not recognize my njsproj
I know this is an old question, but it is still occurring in VS 2013.
I had an old VS 2003 web application. I opened it in VS 2013 (Ultimate) and had the error message:
Could not find the server on the local machine.
Creating a virtual directory is only supported on the local IIS server
along with
The application for project is not installed.
Yes, I am upgrading, and yes, I don't have some other elements ready. Giving me errors is fine - but why are you not completing the migration/load of the project. I can't fix the other issues if you don't LOAD ANYTHING! You loaded the subprojects, and then you told me that I should choose a later .NET Framework. Great, I did that. So why didn't you just finish loading the main project and let me fix the errors?
Lots of attempts to fix this failed. My final solution, just to get the project loaded was {arrow pierces chest, dies with Arghhhhhh on his lips}...
I located the {project}.csproj file. I found the <Reference> sections. The paths to the .NET Framework components were no longer valid and referred to old versions no longer installed (yeah, upgrading, remember?). I manually changed the paths to refer to .NET Framework 4.5 components. The project still didn't load.
Then I located the {project}.csproj.webinfo file. It referred to http://localhost/{stuff}/{project}.csproj, so I just set it to {project}.csproj. No luck. Then I just renamed the webinfo file to hide it. Eureka, the project was hot!
The project loaded, I got the "You have completed the first step in converting your Visual Studio .NET 2003 web project. To complete the conversion, please select your project in the Solution Explorer and choose the 'Convert to Web Application' context menu item." Which, of course, is not present, but is present as the very last item in the Project menu. Then I got the "This action will add designer and code behind files required for converting Web site projects to Web application projects. Do you want to continue?" You bet your posterior I want to continue! And now I have a project I can actually start to fix. Thanks, Microsoft, for the informative error messages.
If your projects individually migrate fine, then create a new blank visual studio 2010 solution, and add new projects individually (right click on solution->add->existing project)
But I'm not sure that your projects will load fine individually. There are project types that require some additional software to be installed in order to be supported. The most frequent problems I face are old projects built with old versions of asp.net mvc (1 or 2) and I have asp.net mvc 3 installed...or really old projects built with asp.net ajax...In those cases, you have to install that additional software and then import project, or find a tool to upgrade that project type to a newer version.
I found a solution that worked for Visual Studio 2017.
In Visual Studio, go to Tools > Extensions and updates. At the upper-right search box, search for "integration". It should come up with Analysis or Diagnostic Tools (or similar). Click Disable, then Enable. Exit the dialog, and close Visual Studio. Relaunch and open your solution again. Your projects will still complain they can't be loaded because of incompatibilities, but now you can right-click them individually and select "Reload Project" and they should load fine.
Credit goes to Paul Potter and Paul Shaughnessy at https://developercommunity.visualstudio.com/content/problem/216061/project-incompatible-application-not-installed.html - I just did the verification work, condensing the information, and delivery :)
Adding this answer as reference for people who landed here for missing ".smproj" file.
This issue can arise due to various project files missing. For me, it was because of ".smproj" file missing which is Project file for SQL Server Analysis Services(SSAS). I re-installed SQL Server Data Tools (SSDT) and restarted the Visual studio.
Originally Answered here
Sometimes the SSIS or SSAS Extension in "Manage Extension" is disabled in the settings and must be Enabled manually. And then restart Visual Studio
It happened to me as wel.
You usualy do really need only to reload project in the solution. But in some cases you maybe:
didn't install SQL Server Data Tools (SSDT) for VS
have to enable SQL Server Data Tools manualy in the Extensions
If you have both things settled then try to reload project again. This happened to me when I moved from VS2019 to VS2022 and extension was somehow disabled.
I am using visual studio 2019 and I was faced with this issue when I reopened my ASP.Net webform App in visual studio after modifying for install SSDT.
this problem happens when Visual studio packages will modify (Especially when SSDT will be installed).
To solve this problem you have to go to you project folder and looking for the folder that named '.vs', this folder is hidden.
Deleting these folder will solve the problem because after that when you will open your project with visual studio, it will create the folder again.
Adding this for those who face issues for SSRS projects in VS2017 from earlier version as this comes up in google search.
In Visual Studio, go to Tools > Extensions and updates. Download the below :
Microsoft Reporting Services Projects
Microsoft RDLC Report Designer
In SSIS 2017, t the upper-right search box, search Microsoft Integration Services Projects.
go to Tools > Extensions and updates.
Enable -"Microsoft Integration Services Projects"
This will help to resolve the issue re-launch the SSIS
For my case, I disabled this extension and turns out, it is needed.
Enabling it resolved my problem.
In VS2019 Before you try any of the above right click the solution and click "Resolve Errors" no kidding that made my tabular model solution being available again.
For me what worked was a variation of #vapcguy solution.
Go to #vapcguy link for Paul Potter and Paul Shaughnessy solution: https://developercommunity.visualstudio.com/content/problem/216061/project-incompatible-application-not-installed.html - I
Follow comment on Paul Potter's post by Albert Romeo
Integration Services Plugin was disabled(as explained before: Goto Tools > Extensions and updates > and search for integration/analysis/reporting and enable application
I had to enable integration services, then reload project. I don't know why since I've been using the same SSIS project several times a week for months.

How can I move/copy a TFS Build Definition to a new Team Project?

We recently migrated to TFS 2010, and have created a new Team Project. (The old one was created in 2005, and seems to be missing key metadata to allow full functionality in 2010). We've copied all our source, and have figured out how to copy our work items to the new team project, but we can't figure out how to migrate our build definitions.
Is there a way to do this, or will we have to re-create them manually?
Thanks!
[EDIT]
Jeff-thank you for the reply! After reading it, and more deeply considering my situation, I realize that my description (and probably my entire question) was flawed.
We originally upgraded our 2008 team project to 2010. It had previously been upgraded from 2005. Up to this point, we've been using CruiseControl.Net to manage our builds. One of our team noticed that our upgraded project was missing some key metadata, and theorized that stuff had not been added in the migration process, so he created a new 2010 team project and imported our source as a test. Now we have two 2010 team projects: the originally migrated one (that we're all using), and the "from-scratch" one.
In the meantime, I was experimenting with TFS Build on the originally migrated project. I created a dozen or so builds, and was refining them, but we haven't moved off of CC.Net yet.
The decision was made to start using the "from-scratch" project, so I was hoping to somehow copy the builds from one project to the other. I don't see a way to do that... there is no build proj file to copy (TFS seems to keep the build definitions internal in 2010).
Normally, when you upgrade to TFS 2010, any build definitions you previously had will be automatically upgraded with the associated Team Project. It sounds like, at least in your case, that your Team Project did not upgrade completely/correctly so you had to start over with a new Team Project.
To copy your build definition, you will need to:
Copy the TFSBuild.proj file(s) from your old Team Project to the new Team Project - under whatever version control folder makes sense.
Create a new TFS 2010 build and select the Upgrade Template (in the Process tab).
Set the Configuration Folder Path property to the location of the copied TFSBuild.proj file copied in step 1 above.
Fill in the remaining required settings.
Hope this helps.
There's been significant changes to how builds are done from TFS 2008 to TFS 2010. One of the reason's why it appears that 'stuff has not been added to the migration process' is because it just does not exist. Even upgrading from TFS 2005 to TFS 2008 had a bit desired in it's completeness.
Jeff provided some good guidance to use the Upgrade Template, this will actually call the tfsbuild.proj file that was carried over from TFS 2008.
As a good practice, you'll want to create a copy of the DefaultTemplate when a new build definition is created for a corresponding relationship. Do this while creating the build definition in the process part of setup. There is a detail expansion arrow that will allow you to create a new, which is a copy of the default, and name it whatever you like. Unless of course there will be absolutely no customization done to the build definition or all of the builds in that project will be following exactly the same steps. i.e.: dev_sso_ci (build definition) corresponds to dev_sso_ci.xaml in the BuildProcessTemplates folder.
Hope this helps too.

Why ought I not to install Visual Studio on my CI server?

A lot of people new to CI (Continuous Integration) install VS (Visual Studio) on their CI server "because it is required to compile the code". MSTest is a common reference brought up here.
Why should I not install VS (or generally speaking, any software not out-of-the-box) on my CI server?
(This question has not been asked before apparently, so I'm adding it for reference. If it already exists, sorry, I missed it, please merge. If no answer is provided to this question within some time I can add one myself)
Because you don't need to. A Visual Studio license is pretty expensive, so having one just lying around on a server where no one's using it is just a waste.There are a couple of arguments why you would still need to install a full blown Visual Studio instance on your Continuous Integration server - but here are their counter arguments:
Reason 1: I need it to compile.
Reality: No, you don't. You need MSBuild to compile, but that is available for free, in the Windows SDK. Note that there are several versions for different operative systems and .NET versions, so be careful to download the correct one.
Reason 2: I need it to make quick fixes on the server.
Reality: No, you don't. You shouldn't make quick fixes on the server - you should check out from your version control system, make the fix, build and run tests locally until it works, check in, and have the CI system do the rest for you. That's why you have a CI system.
Reason 3: Without Visual Studio, I can't run MSTest no my CI server.
Reality: Wrong. AFAIK, the MSTest runner is also part of the SDK (at least that's what it seems like on our CI server here - although I can't verify it since we don't have any tests at the moment...). However, a quick googling found this blog post which explains how to do it without the SDK as well. I haven't read through it in detail, so I can't promise that it works, or that it's legal. You have been warned.
Feel free to add more reasons in comments, and I'll counter them.
You might need to install Visual Studio anyway, out of practicality
I was going to try and refute the accepted answer, posted by #TomasLycken, in the comments, but found I needed more space to talk. Even though I technically agree with what #TomasLycken has asserted, here, I'll list some of the dependencies that I found difficult to install on my CI server - and leave it to you to decide how right the accepted answer is...
1 - 'mshtml' primary interop assembly
You can see the problem I was getting in my build output at this S.O. question I created and answered. Mind you, I spent several hours figuring out how get the desired PIA registered - and it was a result of running some .exe's on the server that came from my V.Studio installation - hmmmmmm
CONTEXT: I had a win forms project that used the Web Browser control.. and in the 'WebDocumentCompleted' event, I was casting the DomDocument to hshtml.IHTMLDocument2 .. and that's why I had a reference to Microsoft.mshtml in my project.
RESULT: Now #TomasLycken suggests I deal with this by fixing my code. At first, I wanted to bawk at this suggestion. My code is deployed and working! But, when I do a web search, I see that Microsoft doesn't really recommend using their mshtml PIA outside of the Visual Studio environment they developed it for.
The offending 10 lines of code was effectively doing a little screen-scraping of data on behalf of our users who do research on technical topics in several well-known web portals. But, when I tested this code, written in 2009, it appears that the DOM it once manipulated has now changed in 2016. I know shocking. Probably not my smartest bit of code. Probably time to retire this function - in other words, fix the code and recommit it.
#TomasLyken I think is right on this one.
2 - Win Forms Project post-build script
CONTEXT: So I had come across this cool post-build technique on S.O. that allows my app.config file in my WinForms project to undergo an XDT transform similar to the way my web projects' web.config files are transformed. Well, it just works OOTB, so-to-speak, if you copy from S.O. and into the .csproj or .vbproj source file. But, once you put all this onto a build server with no Visual Studio, the critical piece fails due to a dependency on:
$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.targets
Now this is straightfoward enough to rectify.. I just copied over to the CI server my C:\Program Files (x86)\MSBuild\Microsoft directory. But, should I? Since I've kinda went off the reservation of what Visual Studio normally would support.. one could argue that #TomasLycken's accepted answer is still right on this point, too.
3 - Just getting all the .NET Frameworks and Multi-Targeting Packs in place
Points 1 and 2 above, were actually the last things I conquered in my attempt to get my first build job to run. And my first build job is for a solution stack that I've created and maintained over the past 8 years.. so it has weathered a few frameworks and would have some non-trivial texture to it. I knew it wouldn't be easy. In fact, I hoped by making a CI server that could build this .sln, that it would in fact be ready to build most any other solution we threw at it.
When I first received my clean "Windows 2012 R2" server, it simply had a lot of things missing.. and I'm wondering if I had installed Visual Studio first, if it would have rectified some of these things straight off?
Below is my synopsis of what I had to do - but it doesn't show the pain and suffering involved figuring it all out and the false starts. Maybe it'll help someone else, though.
> First, uninstalled 4.6.1 framework
-- (find Update for Microsoft Windows (KB3102467) and click Uninstall.)
-- also uninstalled anything from MS labeled with C++ redistributable (a later step will restore these)
> Then, install Windows 7 SDK (installs critical "reference assemblies" and a proper baseline 4.0 framework)
-- Then, install Multi-Targeting Pack for Framework 4.0.1 (netfx_401mtpack.exe)
-- Then, install Multi-Targeting Pack for Framework 4.0.3 (netfx_403mtpack.exe)
> Then, reinstalled 4.6.1 framework for 2012 R2 (KB3102467)
> Then, installed Microsoft .NET Framework 4.6.1 Developer Pack (DP461-DevPack-KB3105179-ENU.exe)
> Then, installed "Visual Studio 2015 Build Tools" (BuildTools_Full.exe)
> Downloaded a copy of nuget.exe and put it in the C:\Windows directory
4 - Getting rid of 'missing ruleset' warning MSB3884
From #kevinbosman's post on this GitHub issues thread
If you don't want to edit your Microsoft.CodeAnalysis.Targets file, please note that it is not enough to merely copy the folder C:\Program Files (x86)\Microsoft Visual Studio 14.0\Team Tools\Static Analysis Tools\Rule Sets\ to the build server.
You also need to create the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\VisualStudio\14.0\Setup\EDev and add the string value StanDir = C:\Program Files (x86)\Microsoft Visual Studio 14.0\Team Tools\Static Analysis Tools\
5 - Getting MSTest to run correctly
Need dlls copied into your build machine, some must register w/GAC more info here specifically:
Microsoft.VisualStudio.QualityTools.Resource.dll
Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll
Need a hive out of your dev machine's registry copied into build server
some warnings, if you want them to go away, according to this Microsoft visual studio help forum require a VS 2010 and feature pack 2 installation.

TFS 2008 with VS 2010 (Beta 2)

My experience with TFS is limited. We run Team Foundation Server off a build server I will denote as 'Alice.' Alice has been working great until we ugraded to VS 2010; and with the urgency of a build coming up in the next few weeks, my question is how do we get a successful build? I followed the instructions listed here: http://richardsbraindump.blogspot.com/2009/11/how-to-build-vs2010-solutions-using.html, however the build fails. My pathway towards the solution: had me put VS 2010 on Alice, instead of turning off the build service and turning it back on, I simply restarted the server*, modified a pathway as it was listed (previously "" and Norton Ghost 2003 gave me a problem with that in the beginning).
*denotes possible problem
What happens: CI_X.1 - Failed -
Any help (including something as simple as analyzing the summary to own experience with the two environments would be much appreciated)
Update: found this error:
C:\Program Files\MSBuild\Microsoft\VisualStudio\TeamBuild\Microsoft.TeamFoundation.Build.targets(373,7): error MSB4131: The "Reason" parameter is not supported by the "GetBuildProperties" task. Verify the parameter exists on the task, and it is a gettable public instance property.
We are using VS2010 RC connecting to TFS 2008.
The solution we've done for now is to modify the Microsoft.TeamFoundation.Build.targets file that was located in C:\Program Files\MSBuild\Microsoft\VisualStudio\TeamBuild folder.
Remove the line <Output TaskParameter="Reason" PropertyName="Reason" />
This appears to be an issue where its a new feature on TFS2010 that was added to the build.targets file. Since the feature doesn't appear to be in TFS2008 and the Microsoft Connect has closed the ticket, it seems to be the best option for now.
This of course leads to another bug that raises the error: MSB4131: The "AssociatedChangesets" parameter is not supported by the "GenCheckinNotesUpdateWorkItems" task.
From the Microsoft Connect, this will be fixed in the RTM. The workaround is to add <SkipGetChangesetsAndUpdateWorkItems>true</SkipGetChangesetsAndUpdateWorkItems> to your TFSBuild.proj file.
And then I was finally able to build .NET 4.0 solution under TFS2008.

Resources