If both project Alpha and project Beta are C# projects, we can set that Beta depends on Alpha and this results to following build order: 1) Alpha; 2) Beta
If project Alpha is C++ project, we cannot add reference from project Alpha to Beta because Visual Studio 2010 does not allow this. Actually we can hack csproj file with notepad, but it doesn't help. Bu we can right click on solution, choose Project Dependencies and say that Beta depends on Alpha.
Problem: MSBuild does not honor dependencies set in sln file and builds projects in wrong order - 1) Beta; 2) Alpha. Note, that Visual Studio honors build order.
How we can set build order for MSBuild between C# and C++ projects within same solution?
Try adding your C++ project reference to the C# project after cleaning the solution. This works for me, although I stumbled on this "workaround" by pure chance.
To me it looks as if Visual Studio is checking the build product of the referenced project, and when it notices the incompatibility it will refuse to add the reference. If, however, the build product is not around to check (because you cleaned the solution), Visual Studio happily adds the reference.
I tested the resulting solution both in Visual Studio and on our TFS build server (which AFAIK uses MSBuild) and build dependencies were evaluated correctly in both cases.
In your question you also mention that manually editing the .csproj file didn't help. I cannot confirm this. I was able to add the following reference and again got a positive build result:
<ProjectReference Include="..\Foo\Foo.vcxproj">
<Name>Foo</Name>
<ReferenceOutputAssembly>false</ReferenceOutputAssembly>
<Private>False</Private>
</ProjectReference>
I am adding the ReferenceOutputAssembly element because this blogs.msdn.com article suggests it. In my experience, though, the build also works without the element. The article is still worth reading because it explains why MSBuild does not honor dependencies defined in the solution.
For completeness sake: I am running Visual Studio 2010, Version 10.0.40219.1 SP1Rel.
Related
I am having a rough time figuring out how to setup cross-targeting inside a Visual Studio 2017 project and I have not been able to find any examples.
I started out with a .NET Standard 1.5 project and to keep it simple I am just trying to add .NET Standard 1.6. If I understand the documentation correctly, I should now be able to do all of this inside the csproj file without having to mess with a project.json or nuspec file.
I've tried all of these values but none seem to work:
<TargetFrameworks>netstandard15;netstandard16</TargetFrameworks>
<TargetFrameworks>netstandard1.5;netstandard1.6</TargetFrameworks>
<TargetFrameworks>.NETStandard,Version=v1.5;.NETStandard,Version=v1.6</TargetFrameworks>
This is the only source of documentation I can find on the feature and it doesn't contain a full example:
https://docs.nuget.org/ndocs/schema/msbuild-targets
https://docs.nuget.org/ndocs/create-packages/supporting-multiple-target-frameworks
I've gotten this to work on latest Visual Studio 2017. As described in this post https://blogs.msdn.microsoft.com/dotnet/2016/10/19/net-core-tooling-in-visual-studio-15/ it is the correct way to do it. My csproj file looks like this:
<PropertyGroup>
<TargetFrameworks>netstandard1.6;net452</TargetFrameworks>
</PropertyGroup>
Visual Studio 2017 RC release notes also has this listed as a feature (under .NET Core and Docker):
Cross-target multiple target frameworks in one project.
My mistake at the start was that when I first created the project the property was called TargetFramework, I tried to add multiple targets and VS did not like that at all. It just crashes then... So make sure to rename it to TargetFrameworks and it should work.
MSDN docs Visual Studio Integration (MSBuild) state:
Building Solutions
Within Visual Studio, the solution file and project build ordering are
controlled by Visual Studio itself. When building a solution with
msbuild.exe on the command line, MSBuild parses the solution file and
orders the project builds. In both cases the projects are built
individually in dependency order, and project to project references
are not traversed. In contrast, when individual projects are built
with msbuild.exe, project to project references are traversed.
With my Visual Studio 2010, when building a .sln file with MSBuild from the command line, project to project references are all built, regardless whether they occur in the solution.
What did I miss here? Or are the docs plain wrong?
You are correct that msbuild.exe will sort out all project references whether or not they are part of the solution in contrast to building within Visual Studio 2010/2012/2013/2015 (and possibly later versions) where you will get a build failure if a referenced project is not part of the solution or built beforehand.
In short, yes, the documentation seems a bit off.
You can ignore the build of project to project reference by running msbuild Solution.sln /t:ProjectName /p:BuildProjectReferences=false this explain the sentence in msdn.
I have a c++ project in VS2010 and a c# project that is to consume this c++ project output (it uses it for p/invoke). I was thinking that I could ensure that the c++ project was build before the c# project by editing the "Project dependencies..." in the solution but this does not seem to have any effect, the build on my buildserver does not respect this setting (I'm using TeamCity to bootstrap an MSBuild file that builds the entire solution file)
I think this used to work, has anything changed with VS2010? Or should I declare the dependency in another way?
SOLUTION: The trick was to hand-edit the csproj file outside VS2010 and add a section like this:
<ProjectReference Include="..\CobraLib\CobraLib.vcxproj">
<Project>{598506DA-91DA-4F25-948D-A14CB16ABEBA}</Project>
<Name>CobraLib</Name>
<ReferenceOutputAssembly>false</ReferenceOutputAssembly>
</ProjectReference>
That made the build server process my projects in the correct order. Only caveat is that VS2010 displays an error on the project reference ("not a .NET project") but otherwise things are working as I intended
I'm in the process of upgrading our VS 2008 solution to run on VS 2010
I managed to successfully build in VS 2010
My next step now is to configure a build machine running TFS 2008
Whenever I start a build it does my projects in alphabetical order with no regard for dependencies. I've googled a lot and I can't seem to find a solution to this.
The closest solution to my problem is found here: msdn link which links to this: dependency solution
However I'm dealing with 129 projects, so I would really rather not do this all manually in the xml.
Has anyone been able to effectively remap the dependencies in a way which msbuild recognizes without manipulating the xml for days...?
It turns out that the conversion to VS 2010 makes the build agent have to use the .NET 4.0 version of msbuild.
So I followed the steps outlined here and it worked: Building .NET 4.0 Applications Using Team Build 2008. Keep in mind that those instructions were written during the beta and the path is now v4.0.30319.
This was required even though all my projects are targeting 3.5
Basically I had to make a one line change and now everything is happy (still working on getting my build to pass but the order is good). It had nothing to do with dependencies not being preserved, simply that the way dependencies were being managed wasn't understood by msbuild 3.5
We also have a large number of projects. We wound up (programmatically) creating a MasterSolution.sln file that contained all of the projects. We also require our developers to only use project references in their code. This way, MSBuild always gets the correct order as it parses the .sln file.
I want to start the develop of a custom project type for Visual Studio that builds a BPR project with Visual Studio.
I need some hints to beginning with this project. Where can I find a template for this type of projects?
My target is to remove the Borland C++Builder's ugly and unstable interface from the development process and work enterely from Visual Studio.
Edit: Oops, I didn't really see that you're about to create a new project type for C++ Builder files. In that case, you have to build a language package. The Visual Studio Extensibility site should get you started. Also have a look at this more specific link.
I'll leave my old answer here for reference, because it might help people who just want to build C++Builder projects without creating a whole new project type :)
You didn't specify the version of Visual Studio, but I'll assume a recent one. In Visual Studio 8 and 9, most project files (all popular ones except Visual C++) are actually MSBuild files and can therefore be built by MSBuild. You can add a simple command line task (Exec) to build your bpr on the command line, or you can create a custom task for this (if you don't find one already available - the search terms should be MSBuild and custom task). This way, both Visual Studio and MSBuild can build anything you like. If you don't have an MSBuild file to start with or want to dive into developing a task, the MSBuild project template for Visual Studio will help you.
Oh, and other than that, if you don't actually need C++Builder things, you might as well export the BPR as a solution (or create a new solution and add the files).
Integrating C++Builder projects into a build process should be a lot easier with C++Builder 2007 or 2009 as both use MSBuild as build system. But then, I think that upgrading to a recent version of C++Builder solves your problem the other way :)