search

microsoft / MSBuildLocator

An API to locate MSBuild assemblies from an installed Visual Studio location. Use this to ensure that calling the MSBuild API will use the same toolset that a build from Visual Studio or msbuild.exe would.
Other
220 stars 83 forks source link

Building on Bitrise #90

Closed matkoch closed 9 months ago

matkoch commented 4 years ago

I'd just like to confirm, whether what I'm doing is correct:

static ProjectModelTasks()
{
    try
    {
        MSBuildLocator.RegisterDefaults();
    }
    catch (Exception exception)
    {
        Logger.Warn(exception);

        var dotnet = ToolPathResolver.TryGetEnvironmentExecutable("DOTNET_EXE") ??
                     ToolPathResolver.GetPathExecutable("dotnet");
        var output = ProcessTasks.StartProcess(dotnet, "--info", logOutput: false).AssertZeroExitCode().Output;
        var basePath = (AbsolutePath) output
            .Select(x => x.Text.Trim())
            .Single(x => x.StartsWith("Base Path:"))
            .TrimStart("Base Path:").Trim();
        MSBuildLocator.RegisterMSBuildPath(basePath);
    }
}

The MSBuildLocator.RegisterDefaults works on AppVeyor. However, on Bitrise it throws with No instances of MSBuild could be detected. although I'm currently executing from a .NET Core 3.1.100 installation. Is that to be expected?

My current workaround is to use my previous implementation (before using MSBuildLocator), which calls dotnet --info and parses the Base Path property.

matkoch commented 4 years ago

On another note, executing this on my macOS system, the first call to MSBuildLocator.RegisterDefaults succeeds. Maybe I miss how the resolution process works. Is it described anywhere?

matkoch commented 4 years ago

Another weirdness: on Azure Pipelines and GitHub Actions (macOS + Ubuntu) I receive the error:

##[error]/home/vsts/work/1/s/source/Nuke.Common/Nuke.Common.csproj : error MSB4244: The SDK resolver assembly "/usr/share/dotnet/sdk/3.1.301/Microsoft.Build.NuGetSdkResolver.dll" could not be loaded. Could not load file or assembly 'Microsoft.Build.NuGetSdkResolver, Version=5.6.0.5, Culture=neutral, PublicKeyToken=31bf3856ad364e35'.

The same revision builds just perfectly fine on TravisCI with macOS and Ubuntu. Also, it actually hangs on Azure Pipelines and GitHub Actions, which never happened before, but can't say for sure if it's my infrastructure.

If you scroll a bit upwards, you can see environment variables and installed SDKs. The TravisCI has no preinstalled SDKs.

Here is the actual commit for reference. I think I did everything according to https://docs.microsoft.com/en-gb/visualstudio/msbuild/updating-an-existing-application

matkoch commented 4 years ago

@rainersigwald can you help?

YuliiaKovalova commented 9 months ago

Close the ticket as not relevant anymore. Feel free to reopen if you still need any input from our side. Thank you!