error NETSDK1194: The "--output" option isn't supported when building a solution.

2/19/2023
5 minute read

Did you see the following error in recent days in your build-pipeline:

error NETSDK1194: The "--output" option isn't supported when building a solution.

If so - that is not necessarily your fault at all! Microsoft released a new SDK version, which breaks your builds. Let's see why and what we can do to tackle that.

error NETSDK1194

You might wonder why you have the error in the first place. You might not use dotnet cli directly. I have projects where I only publish something to Azure via dotnet publish -c Release and it breaks, beautiful isn't it? Especially if you did not change anything!

So why is this even triggering? I will quote the official documentation:

If you specify the --output option when running this command on a solution, the CLI will emit an error due to the unclear semantics of the output path. The --output option is disallowed because all outputs of all built projects would be copied into the specified directory, which isn't compatible with multi-targeted projects, as well as projects that have different versions of direct and transitive dependencies.

If you look above that message, you can see .NET 7.0.200 SDK and later. So we can see that is a recent change with the February patch release of the .NET SDKMore to that later.

What the whole part means is that if you have, for example, a multi-targeting project (.net60, .net70) and put all the output in one directory, the outcome might not be what you expect. Also, if you have multiple assemblies that reference different versions of a library, what should happen then? So the newly introduced error should force you into using different toggles on different levelsAlso more to that later.

Preview versions

My problem I do have here is that this feature was rolled out (remember that is a breaking change) with a patch release of .NET SDK. Not only that, it even hits you when you are not using .NET 7 directly. I have the following, now failing, project:

      - name: Set up dotnet
        uses: actions/setup-dotnet@v3
        with:
          dotnet-version: 6.0.x

And in my failing GitHub Action log, I will find the following:

MSBuild version 17.5.0-preview-23061-01+040e2a90e for .NET
  Determining projects to restore...
  All projects are up-to-date for restore.
Error: /usr/share/dotnet/sdk/7.0.200/Current/SolutionFile/ImportAfter/Microsoft.NET.Sdk.Solution.targets(36,5): error NETSDK1194: The "--output" option isn't supported when building a solution. [/home/runner/work/cool-folder/MySolution.sln]

Come again? Why do I have a preview version of MSBuild with .NET 6? Why is it anyway using SDK version 7.0.200?

I also had this issue in bUnit where we are using dotnet pack that shouldn't be impacted by that as it creates subfolders for every target framework and assembly. So you can't run into the issues described above.

The aftermath

Microsoft acknowledged the issue already. The resolution will be to indicate it as a warning and not as an error. But the solution or the fix will be rolled out with next month's (March 2023) SDK patch version. So you might end up having failing builds for a month now. So any way you will have to find a solution if you use the --output switch in a dangerous fashion.

Fix 1: Use an older SDK version

The simplest fix would be to use an older SDK version:

      - name: Set up .NET
        uses: actions/setup-dotnet@v3
        with:
          dotnet-version: '7.0.103'

Here the issue should not pop up - but that also doesn't work all the time. I did have this issue even with projects that target .NET 6 and .NET 6 only. So that doesn't guarantee a working build pipeline.

So even if you're using .NET do the following to get back one release version

      - name: Set up .NET
        uses: actions/setup-dotnet@v3
        with:
          dotnet-version: '6.0.405'

Fix 2: Use --output on project level, not on the solution level

If you are suffering from that problem you might want to solve the issue and set --output switch on a project level. That can significantly increase your build time.

Fix 3: Use the correct toggle for the appropriate task

I will quote here a response from @baronfel

... a) We'll downgrade the error to a warning - we think this usage pattern is harmful and can lead to builds that are harder to debug, especially when projects are multi-targeted or have differing sets of PackageReference versions.

  1. We'll skip the logic for the pack command entirely - pack has stable and correct semantics when the -o flag is specified (because it sets PackageOutputPath instead of OutputPath directly)

Taken from here

With the following toggles to be used (instead of --output):

Command Property Example
build OutputPath dotnet build --property:OutputPath=DESIRED_PATH
clean OutputPath dotnet clean --property:OutputPath=DESIRED_PATH
pack PackageOutputPath dotnet pack --property:PackageOutputPath=DESIRED_PATH
publish PublishDir dotnet publish --property:PublishDir=DESIRED_PATH
store OutputPath dotnet store --property:OutputPath=DESIRED_PATH
test TestResultsDirectory dotnet test --property:OutputPath=DESIRED_PATH

This should fix your build pipeline in an instant.

Centralize your packages in .NET with NuGet

A feature that isn't really new but still didn't get my attention until recently is: "Central Package Management". So let's have a look at this in this blog post.

Getting git version information in your C# code

Did you ever need git-specific information like the latest tag or the current commit inside your C# code? Or even the semantic version number of your current build=

Well, there is an easy solution involving source generators.

Leverage 'is not' Operator for Exception Filtering!

Did you know you can use the 'is not' operator with exception filtering to simplify and improve your error handling in C#?

In this short blog post, I will show you how to use it.

An error has occurred. This application may no longer respond until reloaded. Reload x