transitive dependencies with msbuild and c++ projects

Question

We converted a significant code base from visual c 2003 and makefiles to vs2008 and solution/project files. 

When Visual Studio builds our executables, .h file dependencies are automatically used to determine which modules get recompiles and linked.  Yeay!

However, when msbuild builds our projects, .h file changes do not force the appropriate modules to be recompiled, causing execution failures.

I read in this blog under transitive dependencies are the issue here, and that perhaps someone is working on this for a future level. 

One work around I thought could be done is to use devenv from vs2008 to build the solutions rather than using msbuild directly. 

Is there something I am missing in the current msbuild that would resolve these dependencies without using devenv?  Or does anyone know the plan for supporting these dependencies in msbuild?

Thanks,


Larry Brooks
AmTote International

Answer 1

Hi Larry,

 

Thanks for your post. As you have noticed, MSBuild has some troubles about the “transitive dependency” in VC++ project.

I have confirmed with the product team that the next version of MSBuild (msbuild 4.0) has better support for it.  According to this article: Response to the Feature-Poll on the MSBuild Team Blog, “transitive dependency” has less request in the Feature-Poll.  

---

Regards,
Jialiang Ge
MSDN Subscriber Support in Forum
If you have any feedback of our support, please contact [e-mail].
Please remember to mark the replies as answers if they help and unmark them if they provide no help.
Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.

Answer 2

Hey Larry

It doesn't work so great in 3.5. This should definitely work in MSBuild 4.0. It uses a completely new patented :-) mechanism. If it misses your case we have a major bug. Do you have time to try in VS2010 beta 2? If we don't find out until final release, it will obvioiusly be hard to fix then.

We do have one known case where this doens't work in Beta 2 and it will be fixed. It requires: one or more files to be out of date due to timestamp AND one or more files to be out of date due to their commandlines not matching the last time they were run AND a list of .cpp files that was not in the project file in case-sensitive order.   So it's a pretty obscure case.

It's essential to us (MSBuild) that incremental build is 100% reliable so I'd be grateful if you'd verify. You can reach me below if it doesn't work right.

Thanks
Dan ([e-mail])

---

developer on msbuild

Answer 3

Thank you Jialiang and Dan.

We will review the beta for its sufficency to this problem.

A couple of questions:

Will the new MSBuild be compatible with building VS9 projects, or would we have to use VS2010 redistributables to support levels using MSBuild 4.0?  Hopefully we could use an older version of vcexpress to build our projects using MSBuild 4.0?  This would resolve our immediate problem without requiring us to switch to new VS2010 redistributables until sufficient time to determine "safeness" for our online system operations, while assuring ourselves that the right modules got recompiled when necessary.

Also, we have MSDN subscriptions, however I don't see VS2010 team edition posted.  We are using TFS for source and process control, and probably couldn't use this visual studio for development unless Team was integrated into the VS gui.

 

Thanks,

 

Larry

 

 

 

 

 

Answer 4

Hi Larry,

Sorry for late reply.
I think VC++ project in MSBuild 4.0 is not compatible with the VC9 proejct in MSBuild 3.5, because the VC++ project file in VS2010 has been transformed to MSBuild format, it will import some targets and .props only existed in MSBuild 4.0.

About the VSTS 2010, you could take a look at(public):
Visual Studio Team System 2010 Team Foundation Server Beta 1
Microsoft Visual Studio Team Foundation Server 2010 Beta 2 – ISO

I checked the MSDN subscription site, it's also downloadable, do you set the filter correctly?
You can also get more information about the VSTS2010 and MSbuild 4.0 by posting question at the:
Visual Studio 2010 & .NET Framework 4 Beta 2 Announcements,
Visual Studio Team System 2010 Beta2 and
Microsoft Visual Studio Team Foundation Server 2010 Beta 2 forums.

Sincerely,
Wesley

---

Please mark the replies as answers if they help and unmark them if they provide no help. Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.

Answer 5

Hi Larry,

How are you? Is your problem resolved? May I know whether the above suggestions helped you?

Thanks,
Wesley

---

Please mark the replies as answers if they help and unmark them if they provide no help. Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.

Answer 6

Hi Wesley,

Well, your answer was very informative, so I think it qualifies as an answer, however, it does not give us a much needed shorter term solution.

It does however  bring up interesting problems that we will face in the transition from VS2008 to VS2010.

Our development team uses VS2008 Team, and produce checkins to various deployed branches of code, where each branch would be using VS2008 currently. 

How would you recommend transitioning to VS2010?  Our normal approach is to convert some developer workstations to 2010.  This would involve I imagine a complete conversion of our solutions, project files, and props files to accomodate the new MSBUILD formats.  Our product is quite large, with over a thousand integrated projects, so the converted files couldn't be checked in until everyone had the new VS2010 developer software.

If these files have changed significantly to the point of not being backwards compatible to VS2008, that means that merges of changes into VS2008 branches will require significant effort, depending on the severity of the changes that were required to convert them.

So, how would you recommend transitioning workstations to 2010 when 2008 is the common development?  How drastic are the changes if .vcproj files would need merging from 2010 to 2008?

The other problem is that we can't possibly deploy into our real-time monetary transaction processing systems the latest Beta or new release software without significant test time, which can take up to a year.  Since MSBUILD 4.0 appears to require VS2010 converted files, and probably the new VS2010 compiler, this solution doesn't work for us for at least a year.  So, we're stuck with the problem for a year unless there is a fix to MSBUILD 3.5.  So, we got an answer, but no immediate solution.