ServiceController constructor throws exception with Nuget library 9.0 in .NET6

[vsfeedback]

This issue has been moved from a ticket on Developer Community.

---

[severity:It's more difficult to complete my work]
My .NET6 application works with the 8.1 ServiceController nuget library. I updated to the 9.0 library and the ServiceController constructor now throws a System.PlatformNotSupportedException.

public const string FriendlyServiceName = "Woodward File Collection Service";

Here is the line that throws the exception:
_serviceController = new ServiceController(FriendlyServiceName);

I reverted to the 8.1 ServiceController library. This works fine for now, but I'd like to know if there's a better solution.

---

Original Comments

Feedback Bot on 11/18/2024, 04:14 AM:

We have directed your feedback to the appropriate engineering team for further evaluation. The team will review the feedback and notify you about the next steps.

[ViktorHofer]

@ DougWatt,

This is expected as the minimum supported runtimes for the System.ServiceProcess.ServiceController package are .NET Framework 4.6.2 and .NET 8.0. You should see the following warning at build time already:

System.ServiceProcess.ServiceController 9.0.0 doesn't support net6.0 and has not been tested with it. Consider upgrading your TargetFramework to net8.0 or later. You may also set <SuppressTfmSupportBuildWarnings>true</SuppressTfmSupportBuildWarnings> in the project file to ignore this warning and attempt to run in this unsupported configuration at your own risk.

Please either downgrade the package back to 8.0.1 or update your TFM to an in-support version, i.e. net8.0. Note that .NET 6 is already out-of-support.

[Varorbc]

@ViktorHofer Hey, shouldn't we rethink which target frameworks we're aiming for? It would be better if users couldn't install it at all when their framework isn't supported, instead of letting them go through with the installation and then getting warnings. Chances are, some users won't pay attention to those warnings anyway.

[ViktorHofer]

@Varorbc as you know, we already had this in length discussion in #107081 and open-telemetry/opentelemetry-dotnet#3448. Yes, the current situation isn't great. As long as our packages support .NET Standard (so that class libraries which target .NET Standard can consume them) we need to rely on warnings. Note that initially the warning was even an error but we had to dial back on that. If we would want better UX around this, we would need a new tooling feature (NuGet packages indicating compatibility holes).