Enable Client Library Authors to Disable MSBuild Requirement For Downstream Consumers

[slang25]

With Refit 6 there is now a requirement that MSBuild 16.8 is present, this creates (possibly) unnessary friction in the following scenario:

• You use Refit 6 in am "API Client library" you want to share, basically an interferace with a Refit dependency.
• Another team use your library in their project with older tooling (i.e. lower than MSBuild 16.8)

The 16.8 require seems to only be required for the client library as it needs the source generator, however not for the consuming project.

Could there be a way to disable the tooling requirement of consumers, from the client project. i.e. could there be a way to declare Refit as a runtime dependency only, or add some behavior that could optionally achieve the same thing.

[clairernovotny]

So, theoretically we could add a property to bypass the check here: https://github.com/reactiveui/refit/blob/main/Refit/targets/refit.targets#L16

However what projects are using MSBuild < 16.8 at this point given that 16.10 is now GA (as of yesterday). There are secure supply chain considerations too where folks should be using 16.10 as soon as possible. Granted, that's unrelated to this, but how many users/what scenarios have people using < 16.8? 16.8 is about 7 months old at this point.

GitHub

reactiveui/refit

The automatic type-safe REST library for .NET Core, Xamarin and .NET. Heavily inspired by Square's Retrofit library, Refit turns your REST API into a live interface. - reactiveui/refit

[martincostello]

.NET Core 3.1 specific SDKs still ship for versions of MSBuild older than 16.8, which was what flushed this out for us in a specific application still targeting 3.1 LTS with a 3.1 SDK (rather than with a 5.0 SDK).

For example the 3.1.115 SDK is associated with VS 2019 16.4.22 and 3.1.409 with 16.7.15.

https://github.com/dotnet/core/blob/1d9c0f45e2d87c13ba262865f0c410d6e44ecaea/release-notes/3.1/releases.json#L25

GitHub

dotnet/core

Home repository for .NET Core. Contribute to dotnet/core development by creating an account on GitHub.

[clairernovotny]

The .NET 5 SDK can build/target apps that run on the 3.1 runtime, and also includes important compiler updates for securing the supply chain.

I understand targeting .NET Core 3.1, but what's the reason to use the .NET 3.1 SDK to build it as well?

[martincostello]

In this specific case it was still using the older SDK because it also installed the correct runtime for the tests to target (i.e. netcoreapp3.1) at runtime. The application is also not worked on often, so investments in newer SDK/runtime features are limited due to time constraints within the team that maintain it.

The team are now looking into updating the application to .NET 5 in preparation for .NET 6 later this year, and have also updated their build scripting to use the .NET 5 SDK and install the .NET 3.1 runtime.

However the need to do this has only come about via the dependency chain of Refit via another internal library into this application, which has then required the compilation chain to be updated due to the MSBuild version requirement.

The deterministic flags etc. now available in the SDK are good new features and improve build artifact integrity which is a good thing, but they're brand new capabilities that aren't in an LTS release. This means not all projects can ingest them even if they would be desirable.

We've got hundreds of separate .NET applications in use in our production environments, so even with all the will in the world, unfortunately not all teams have the luxury of being able to be on the bleeding edge of SDK versions for everything so keep things ticking over month-to-month on the latest secure/patched LTS version (which is often the one closest to when the application last had any major development work done).

There's individual cases we can update to get things moving along, like in this scenario, but we raised this issue more to highlight the fact that the frequent updates to minimum required versions in Refit sometimes create unexpected friction in projects that use it.

[clairernovotny]

It might be worth reviewing the release policies to see what LTS really means: https://github.com/dotnet/core/blob/main/release-policies.md

For LTS it pretty much security patch updates only, after the full support period (which is the same as Current). SDK's are "frozen in time".

The general recommendation is what you suggest: use the latest SDK and ensure that the build scripting installs the 3.1 runtime you need. That ensures that you get build-time feature updates, as well as security updates. There shouldn't be any breaking changes when targeting an existing/older TFM (if there are, that's genreally considered a bug that gets priority attention).

GitHub

dotnet/core

Home repository for .NET Core. Contribute to dotnet/core development by creating an account on GitHub.

[Dids]

As far as I can tell, Visual Studio for Mac still ships with msbuild version 16.6, unless using the Preview channel. Granted this will end up in the Stable channel eventually.

Curiously though, I've noticed that this only affects CLI and CI builds, but building through the IDE seems to work fine, which makes me wonder if there are multiple versions of msbuild at play here.

[jthegeman]

This would allow users that rely on Azure Pipelines and MacOS hosted client to use Refit 6.0.

Currently the only way I know to build on MAcOS hosted clients is to downgrade to Refit 5.x.