8

I've a .NET Solution with a managed C++ assemlby Targeting .NET 3.5 created with VS2010. The command:

%windir%\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe MyProject.sln

compiles the solution on my dev machine.

On my BuildServer I get this error:

Build FAILED.

"F:\CruiseControl.NET\Projects\MyProject\MyProject.sln" (default target) (1) -> "F:\CruiseControl.NET\Projects\MyProject\MyProject\MyProject.csproj" (default target) (2) -> "F:\CruiseControl.NET\Projects\MyProject\MyProjectMAPIHelper\MyProjectMAPIHelper.vcxproj" (default target) (3) ->
F:\CruiseControl.NET\Projects\MyProject\MyProjectMAPIHelper\MyProjectMAPIHelper.vcxproj(23,3): error MSB4019: The imported project "C:\Program Files\MSBuild\Microsoft.Cpp\v4.0\Microsoft.Cpp.Default.props" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.

0 Warning(s)
1 Error(s)

On my dev machine the claimed file

"C:\Program Files\MSBuild\Microsoft.Cpp\v4.0\Microsoft.Cpp.Default.props"

exists. On my build server not.

When I try to copy this files (and all others in the same directory) other errors occurred. So this is the wrong way.

EDIT: other errors means: When I copy the file "Microsoft.Cpp.Default.props" on the build server, MSBuild is claiming other files. That shows me, that just doing a copy of missing files is not what the build environment is expecting. I am looking for an MSI/whatever package that I could install on my build server and any C++ Project will build. Installing the SDK did not the trick. Or I did something wrong during SDK installation. Or it is not possible to compile Managed C++ VS2010 Solutions just with the SDK.

I believe that "other errors" has nothing to do with my problem. My Problem is: "How do I setup my build environment correctly". /EDIT

What I've done till now:

  • I have installed the latest Win7 SDK (Link)
  • I am targeting .net 3.5
  • I've tried playing with the Platform Toolset Property - but it was just playing
  • In my solution there is a managed C++ Assembly (my Problem)
  • I am using MSBuild 4.0 because the new VS2010 project files cannot be compiled with MSBuild 3.5
  • I am using CC.NET. compilation fails in CC.NET and on the command line. So it should not be a CC.NET issue.

Are there any tips and tricks how to configure my project properly to compile on my dev machine with VS2010 and on my build server? Is there anything more to install (except VS2010)?

Thanks, Arthur

Glorfindel
  • 21,988
  • 13
  • 81
  • 109
Arthur
  • 7,939
  • 3
  • 29
  • 46
  • Question: Are you hardlocked into CC.Net, or do you have the ability to look at upgrading to something else? – Caladain Jun 25 '10 at 22:06
  • 2
    I don't think changing to another Continuous integration technology will change anything. As Arthur says, build fails using plain MSBuild. This seems to be a problem with .Net 4.0 more strongly tied to SDK 7.0A than it ought to be. – Samuel Jack Jun 26 '10 at 09:50
  • Yes, thats true. compiling fails on the command line with MSBuild. CC.NET is not involved yet. – Arthur Jun 26 '10 at 11:49

3 Answers3

4

For now, installing VS 2010 is your only safe option. The Windows SDK will be updated to enable your scenario, but I don't have a specific release date. Until then, you'll need to install VS 2010 with the C++ tools in order to build your 2010 solution with C++ projects. Make sure you let the C++ team know about how dissatisfaction with this situation via their team blog and/or MSDN Forum.

Even after installing VS 2010, you may need to invoke the appropriate vcvars*.bat file to setup your environment variables correctly.

Glorfindel
  • 21,988
  • 13
  • 81
  • 109
Jim Lamb
  • 25,355
  • 6
  • 42
  • 48
  • Sad news. If installing SDK does not do the trick, I'll have to install VS 2010 on my build machine. Sad, but obviously true. – Arthur Jun 26 '10 at 11:54
  • 1
    After much pain, I have discovered that the 7.1 SDK does install the necessary setup *if* you select the right options during install and don't try to outsmart yourself :). See the short answer to http://stackoverflow.com/questions/4742325/how-to-build-a-vs2010-makefile-project-vcxproj-with-tfs-build-no-vs-2010/4768328#4768328 – BlueMonkMN Jan 22 '11 at 14:20
  • How is this answer acceptable? The purpose of a build server is NOT to have to install Visual Studio... @BlueMonkMN: Are/were you running a machine with Windows 7 or a server version? – Brandon Jan 16 '14 at 18:32
  • @Brandon I believe we were running a Windows Server, although I doubt that would make much difference. With the more recent versions of Visual Studio, though, I have given up trying to set up a build environment without Visual Studio because Visual Studio Express is free and provides an adequate build environment without all this hassle. – BlueMonkMN Jan 16 '14 at 19:08
  • That's what I'm running: Server 2008. I can't understand how this process is this convoluted though. I've installed .NET 3.5, 4.0, 4.5, 4.5.1, MSBuild 12.0, Any VC Redist I can get my hands on, the Windows SDK for Server 2008 and Visual Studio 2010 Full (not express) and MSBuild is still failing every step of the way. – Brandon Jan 16 '14 at 19:43
1

Why don't you want to install VS2010 on your build server? If it's licencing, it's licenced per developer head not per install so I'm reasonably sure you are allowed to without buying another copy - or, at worst, you can install the express version which ought to at least install the config bits you're missing so you can use the platform SDK compiler.

If you're still having problems with msbuild you can then use devenv.com /build which exactly replicate the VS build env.

Rup
  • 33,765
  • 9
  • 83
  • 112
  • 2
    Installing VS2010 will be my last option. – Arthur Jun 21 '10 at 12:13
  • @Rup Installing VS on a build server is a terrible idea. It's exactly the opposite of what a build server is for - providing a clean, customer-like environment (existing DLLs etc.). If you think installing VS on the build server is no problem, then you also need to suggest installing VS on every customer box. – mafu Jan 24 '13 at 09:50
  • @mafutrct I see where you're coming from but there's no reason you have to host and test the application on your build server! Back when I wrote that our environment was a build server for unit tests and some integration tests but an automatic deployment to another server (which didn't have VS) for real testing. – Rup Jan 24 '13 at 10:33
  • @Rup The point is that installing VS makes the machine special. It produces binaries (specifically, client applications) that could depend on DLLs only available on machines with VS installed, so it will work on the build server and on the dev boxes, but fail for most end users. I've had that a lot, though admittedly 10 years ago. – mafu Jan 24 '13 at 13:41
  • @mafutrct OK, fair enough - I've only ever seen that problem with debug builds though not release. You're right that running on a machine with VS guarantees all the runtime library parts are installed though which you might have forgotten to put in your installer but I'd be surprised if it threw extra dependencies in a release build. – Rup Jan 25 '13 at 10:13
0

You may try those links:

http://social.msdn.microsoft.com/Forums/en-US/tfsbuild/thread/9055ca52-586b-459f-9dd1-a9d052d076b9/

or

http://msdn.microsoft.com/en-us/library/ee662426.aspx

David Schmitt
  • 58,259
  • 26
  • 121
  • 165
Leszek Wachowicz
  • 1,015
  • 1
  • 14
  • 24