Azure-pipelines-tasks: Visual Studio Build step should allow multiple paths

[rkeithhill]

Right now the VSBuild tasks allows you to specify either one SLN file (relative) path or a wildcard. That doesn't work for our team projects because we typically have two or three SLNs out of >10 that we build on a regular basis. So I really, really want to not have to duplicate VS Build steps to handle this. After looking at the VSBuild.ps1 1.0.16 version, I modified it pretty simply to support this. I replaced this:

# check for solution pattern
if ($solution.Contains("*") -or $solution.Contains("?"))
{
    Write-Verbose "Pattern found in solution parameter."
    Write-Verbose "Find-Files -SearchPattern $solution"
    $solutionFiles += Find-Files -SearchPattern $solution
    Write-Verbose "solutionFiles = $solutionFiles"
}
else
{
    Write-Verbose "No Pattern found in solution parameter."
    $solutionFiles = ,$solution
}

with this:

$solutionFiles = @()
foreach ($sln in ($solution -split '\|').Trim()) {
    # check for solution pattern
    if ($solution.Contains("*") -or $solution.Contains("?"))
    {
        Write-Verbose "Pattern found in solution parameter."
        Write-Verbose "Find-Files -SearchPattern $solution"
        $solutionFiles += Find-Files -SearchPattern $solution
        Write-Verbose "solutionFiles = $solutionFiles"
    }
    else
    {
        Write-Verbose "Solution path found in solution parameter."
        if (!([System.IO.Path]::IsPathRooted($sln))) {
            $sln = Join-Path $env:BUILD_SOURCESDIRECTORY $sln
        }
        $solutionFiles += $sln
    }
}

This allows me to specify multiple SLN paths like so:

Foo.sln | Samples\Samples.sln

I chose the | character as a separator as that is not a valid path char and does not interfere with wildcard paths. In fact, this change would allow for mixed combination of SLN paths and wildcard specs e.g.:

Foo.sln | Samples\**\*.sln

So I was thinking about contributing this back as a PR but I see that the VSBuild.ps1 script has been updated to use Get-SolutionFiles from the module $PSScriptRoot\ps_modules\MSBuildHelpers\MSBuildHelpers.psm1 which I can't find.

Is this something you might be interested in taking as a PR? If so, where can I find this mysterious MSBuildHelpers.psm1 module file?

[ericsciple]

It's supported today already. Unfortunately it's not well documented. Checkout the description for the LegacyPattern parameter of the underlying command

[rkeithhill]

Thanks for the reply. So we would use foo.sln ; samples\samples.sln? I tried that first thing and it didn't work. That said, we are still on update 1. Does this require >= update 2?

[ericsciple]

I think it works in Update 1 as well, you also might need to specify a wildcard so it defers to Find-Files. Albeit a hack, I'll fix.

[rkeithhill]

Thanks! That would be much appreciated.

[bryanmacfarlane]

It's designed to take a path even though wildcards can be in that single path spec. We won't support multiple paths - that's multiple tasks in the job.

[rkeithhill]

Why? You realize we had this capability in the XAML based build process parameters, right? Accepting a wildcard is already acknowledgement that the build step will build multiple solutions. I fail so see why specifying multiple paths vs a wildcard should make a difference? I just want to avoid unnecessary duplication in build step configuration (parameters, configuration, etc).

As it stands, we already have too much VS step duplication because we can't use the "multiple configuration" feature since it applies to every step and that doesn't work for 90% of our builds. We have build steps that package up results from multiple configurations (all combos of x86, x64, debug and release) and frankly we only need to build docs, nuget pkgs and MSI installers once - period. Not once per configuration.