Dependent Projects

[melston]

I have a project with the NUnit unit tests in a subdirectory (UnitTests). I am trying to create a multiproject build where the root solution gets built first and the UnitTest solution gets built and run second. I tried creating a settings.gradle with a single "include 'UnitTests'" and then adding the following to the root build.gradle:

evaluationDependsOn(':UnitTests')

allprojects{
    id 'com.ullink.msbuild' version '2.9'
}

apply plugin:'msbuild'

msbuild {
 ...
}

In my UnitTests build.gradle I have the following:

plugins {
  id 'com.ullink.nunit' version '1.0'
}

dependencies {
    compile project(':')
}

apply plugin:'msbuild'

msbuild {
    ...
}

The problem is the dependencies in the UnitTests gradle file. This gives me the error:

    Could not find method compile() for arguments [root project 'QCoreTest'] on project ':UnitTests'.

I tried using 'msbuild' and 'build' (just trying anything really) but nothing works. How do I get the unit test project to build after the root project?

Mark

[gluck]

Hi Mark,

I'm not very familiar with gradle multiprojects, but I'll give it a guess anyway :) AFAICT there's no "compile" configuration defined when using msbuild, hence you can't use dependencies this way. Also this plugin simply wraps msbuild, so you need to define dependencies in your csproj, not in your build.gradle.

That being said, what's your goal from using multiproject build for UTs of a project ? usually in java-world those are in the same build file, and this plugin has been successully this way in many occasions, e.g. you can look at ILRepack build, which uses both msbuild/nunit.

[melston]

Thanks for getting back to me Francois.

This is an artifact of how we have the projects set up already. We have a single Core solution made up of (mostly) DLL projects. Inside the Core project tree we also have a UnitTests folder with a separate solution file for it. In that folder tree are NUnit test projects to test each of the DLLs in the Core.

We set it up this way before looking at Gradle because we wanted to keep the unit tests 'close' to the projects they test (they are in the same subversion repo) but didn't want to put them all in the same solution since we had a problem with the NUnit plugin in Visual Studio 'hanging on' to the build products and preventing a rebuild when you make a change. This allowed us to build and execute the unit tests separately from the projects they test.

Anyway, we have decided to go a different direction after all. We were going to use Gradle in our nightly build and test but have, instead, installed Jenkins on our build system to do this.

I do want to study the ILRepack gradle file as it has some interesting elements to it. I wasn't aware you also had a NuGet and NUnit plugin available. I will keep this in mind as it may still be useful for command-line building or providing a common build infrastructure for developers to use on their machines even if we don't make use of it in the nightly build environment.

Thanks for the feedback.

Mark

On Tue, Aug 11, 2015 at 11:37 PM, Francois Valdy notifications@github.com wrote:

Hi Mark,

I'm not very familiar with gradle multiprojects, but I'll give it a guess anyway :) AFAICT there's no "compile" configuration defined when using msbuild, hence you can't use dependencies this way. Also this plugin simply wraps msbuild, so you need to define dependencies in your csproj, not in your build.gradle.

That being said, what's your goal from using multiproject build for UTs of a project ? usually in java-world those are in the same build file, and this plugin has been successully this way in many occasions, e.g. you can look at ILRepack https://github.com/gluck/il-repack/blob/master/build.gradle build, which uses both msbuild/nunit.

— Reply to this email directly or view it on GitHub https://github.com/Ullink/gradle-msbuild-plugin/issues/41#issuecomment-130186613 .

[gluck]

You're welcome, note that at work we're using gradle together with jenkins for continuous integration / nightly builds, it's fairly easy with the gradle wrapper comitted on the repository.