adamralph / bau-msbuild Goto Github PK

Hi,

In order to get MSBuild 14 (shipped with VS2015) the MSBuildVersion is semantically incorrect ie:(VS14 which doesn't exist).

.Do(msb =>
    {
        msb.ToolsVersion = "14.0";
        msb.MSBuildVersion = "VS14"; //Hack for MSBuild VS2015

        msb.Solution = Projects.SolutionFile.ToString();
        msb.Properties = new
            {
                Configuration = "Release",
                //OutDir = Folders.CompileOutput
            };
        msb.Targets = new[] {"Rebuild"};
    })

I am currently getting this error on my CI machine:

[Bau] ERROR: 'build' task failed. The system cannot find the file specified
ERROR: System.InvalidOperationException: 'build' task failed. The system cannot
find the file specified
   at BauCore.Bau.Execute(String task, IBauTask taskRef)
   at BauCore.Bau.Invoke(String task)
   at BauCore.Bau.Invoke(String task)
   at BauCore.Bau.Invoke(String task)
   at BauCore.Bau.Run()
   at Submission#0.<Factory>(Session session)
   at Roslyn.Scripting.Submission`1.Execute()
   at ScriptCs.Engine.Roslyn.RoslynScriptEngine.Execute(String code, Session ses
sion)

I am 75% positive that this is because MSBuild was not found. The machine does however have Visual Studio 2010 installed (I refuse to discuss why) so I am not sure why MSBuild was not located if that is the issue. Some extra details could help sort issues like this out.

Hey Adam,

I just figured if it wouldn't be nicer and much cleaner if we could introduce (flag) enums for most of the parameters you pass to the .MSBuild lambda function.

Before:

bau.MSBuild("build").Do(msb =>
{
    msb.MSBuildVersion = "net45";
    msb.MSBuildArchitecture = ProcessorArchitecture.X86;
    msb.Solution = solution;
    msb.Targets = new[] { "Clean", "Build", };
    msb.Properties = new { Configuration = "Release" };
});

After:

bau.MSBuild("build").Do(msb =>
{
    msb.MSBuildVersion = NetPlatform.Net45;
    msb.MSBuildArchitecture = ProcessorArchitecture.X86;
    msb.Solution = solution;
    msb.Targets = BuildTarget.Clean | BuildTarget.Build;
    msb.Properties = new { Configuration = "Release" };
});

We could either use the .ToString() method of those enums and then pass them in the existing pipeline with minimal changes or read the enum's DisplayMemberAttribute and then pass that in the existing pipeline. I suspect that only a few changes are required to make this work, which gives the library user a IMO much cleaner API.

So, what do you think?

Probe for the latest version present on machine.

Respect version specified in solution/project file?

Maintain the ability to specify which version to use.

E.g.

msb.Targets = new[] { "Build", };
msb.Properties = new { Configuration = "Release" };
msb.MaxCpuCount = -1;
msb.NodeReuse = false;
msb.Verbosity = BauMSBuild.Verbosity.Minimal;
msb.NoLogo = true;

MSBuildVersion should be defaulted via probing - see #18

I'm pretty sure bau-msbuild fails to work for me because VS2010 SP1 is not installed on a VS2010 system but maybe this will offer a fallback strategy for the case here:

https://github.com/bau-build/bau-msbuild/blob/master/src/Bau.MSBuild/MSBuild.GetPath.cs#L72

The following script is able to locate the 2.0 tools:

#r "Microsoft.Build.Utilities"

using Microsoft.Build.Utilities;

var location = ToolLocationHelper.GetPathToDotNetFrameworkFile("msbuild.exe", TargetDotNetFrameworkVersion.Version20);
Console.WriteLine(location);

I can't locate the 4.0 tools because: TargetDotNetFrameworkVersion' does not contain a definition for 'Version40'

I will install SP1 on Monday and see if that fixes my problem. If so I think this should be closed in favor of "HOLY CRAP Y U NO SP1?" .

moved from adamralph/bau#35

• set version and architecture and determine path
• set working directory
• non-logger switches
• dogfooding
• logger switches