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.
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 (
.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.
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
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.
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
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
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.
- 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
dotnet build --property:OutputPath=DESIRED_PATH
dotnet clean --property:OutputPath=DESIRED_PATH
dotnet pack --property:PackageOutputPath=DESIRED_PATH
dotnet publish --property:PublishDir=DESIRED_PATH
dotnet store --property:OutputPath=DESIRED_PATH
dotnet test --property:OutputPath=DESIRED_PATH
This should fix your build pipeline in an instant.