Breaking change inside v7.0.200 - MSBuild Preview version used !?

[WernerMairl]

Describe the bug

"dotnet build -o " feature (output folder for entire solution build)

To Reproduce

use "dotnet build -o " with sdk 7.0.200 from today

Exceptions (if any)

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

Further technical details

You can see in the screenshot that a preview version of MSBuild is used/delivered (7.5.0-preview....".
Maybe this is the root cause of the issue!
Because with the SDK from last week (7.0.100) i can workaround the exception!

I hope that helps - assuming this issue may cause a lot of problems...

BR
Werner

[KalleOlaviNiemitalo]

The NETSDK1194 error was intentionally added in #29065, to fix #15607.

[WernerMairl]

@KalleOlaviNiemitalo
Nice fix. but following semantic versioning policy, this may be the wrong delivery :-(

[PeterLehmann]

still a breaking change you have not write in the release note

[KalleOlaviNiemitalo]

I'm not sure whether there even are any release notes for differences between .NET SDK feature bands.

If this breaking change were listed in https://github.com/dotnet/core/blob/main/release-notes/7.0/7.0.3/7.0.3.md#notable-changes, developers might notice it from there. But you can also target .NET 7.0.3 using .NET SDK 7.0.103, which does not include this breaking change.

[WernerMairl]

Sorry Kalle,

dotnet 7.0 is a released product.

Yes: you CAN implement breaking changes, but then they must be:

a) documented (release notes)
b) more important: the major version number part must be increased (assuming we are doing semver.

We can bet, that this change may be reverted ASAP a soon as Microsoft recognizes the mistake ;-)

This fix can be a nice improvement on .Net 8

[KalleOlaviNiemitalo]

.NET SDK is not doing semver -- see https://learn.microsoft.com/en-us/dotnet/core/versions/#versioning-details.

[dave-yotta]

No Semver? That's crazy! Do I have to pin to a patch version and avoid security patches just so that I can avoid breaking the build?

All the heat the sdk team are going to get for this, and it's only been out for a few hours, is a direct consequence of all consumers of the SDK (for me it is my reference to 7.0 of the dotnet docker image: mcr.microsoft.com/dotnet/sdk:7.0) expecting the patch version to not indicate any breaking change.

SemVer aside: which versioning system actually specifies a breaking change as the most minor possible change?

[WernerMairl]

all in all...
not a good idea to deliver this in this way....

we will see how many build pipelines worldwide are broken...

🍿 🍿 🍿

[dave-yotta]

So if my runtime is dotnet/aspnet:7.0 I need to somehow mirror that in an sdk version dotnet/sdk:7.0.1**?? There are no valid version strings for this supported in any tools I can think of!

[GregorLamche]

So if my runtime is dotnet/aspnet:7.0 I need to somehow mirror that in an sdk version dotnet/sdk:7.0.1**?? There are no valid version strings for this supported in any tools I can think of!

One reason why my team stopped using Microsoft docker images (MS is too slow to role out security updates of the base image).

As a work around you can switch to a OS base image, and install the sdk/runtime using its package manager.
With Ubuntu it would look like this:

FROM ubuntu:22.04 as base
RUN apt-get update \
    && apt-get install -y dotnet-sdk-7.0=7.0.102-1

[dave-yotta]

As a work around you can switch to a OS base image, and install the sdk/runtime using its package manager. With Ubuntu it would look like this:

I was thinking about sdk security patches, not OS, but that's a new sadness. Pinning dotnet-sdk-7.0=7.0.102-1 means I won't get any critical patches from 7.0; there's no way around this if breaking changes are released on the patch version - I guess this is because the sdk team want maj/min to match the .NET version.

If the sdk and runtime are truly a monorepo, then breaking changes should update the minor version for both of them.