sdk: The .NET 5 return Platform Not Supported if you try to use .NET 5 as a Windows Service application.

Hello. Recently, i wanted to upgrade my websites from .net core 3.1 to .net 5, but i notice the visual studio return an warning (CA1416) on the host.RunAsService().

Describe the bug

The .NET 5 return Platform Not Supported if you try to use .NET 5 as a Windows Service application. Even if the OperatingSystem.IsWindows return true, the application return errors when i try to start on services.msc. This does not happen in .net core 3.1.

To Reproduce

See @eerhardt’s notes in https://github.com/dotnet/sdk/issues/16049#issuecomment-785189111 for simplified set of repro steps

To Reproduce Original

Windows Services via IHostBuilder

Create a normal .net 5 project.
Add this refences to allow Windows Services:

Microsoft.AspNetCore.Hosting.WindowsServices
Microsoft.AspNetCore
Microsoft.Extensions.Hosting.WindowsServices

On Host.CreateDefaultBuilder add .UseWindowsService()
Main Program looks like this

public static void Main(string[] args)
        {
            CreateHostBuilder(args).Build().Run();
        }

        public static IHostBuilder CreateHostBuilder(string[] args)
        {
            return Host.CreateDefaultBuilder(args)
                .UseWindowsService()
                .ConfigureWebHostDefaults(webBuilder =>
                {
                    webBuilder.UseStartup<Startup>();
                });
        }

Create service on cmd via sc create

Windows Services via IWebHostBuilder

The process is identical up to point 2, inclusive.

Use this code via WebHost to create Windows Service Run.

public static void Main(string[] args)
        {
            CreateWebHostBuilder(args).Build().RunAsService();
       }
public static IWebHostBuilder CreateWebHostBuilder(string[] args)
        {
            return WebHost.CreateDefaultBuilder(args)
                .ConfigureAppConfiguration((context, config) =>
                {
                })
                .UseStartup<Startup>();
        }

Create service on cmd via sc create

The application will return Exception Info: System.PlatformNotSupportedException: ServiceController enables manipulating and accessing Windows services and it is not applicable for other operating systems.

Further technical details

Visual Studio 16.8.5

.NET SDK (reflecting any global.json):
 Version:   5.0.103
 Commit:    72dec52dbd

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.17763
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\5.0.103\

Host (useful for support):
  Version: 5.0.3
  Commit:  c636bbdc8a

.NET SDKs installed:
  3.1.111 [C:\Program Files\dotnet\sdk]
  3.1.406 [C:\Program Files\dotnet\sdk]
  5.0.103 [C:\Program Files\dotnet\sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.All 2.1.25 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.App 2.1.25 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.1.11 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.1.12 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 5.0.3 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 2.1.25 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 3.1.11 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 3.1.12 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 5.0.3 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.WindowsDesktop.App 3.1.11 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 3.1.12 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 5.0.3 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

About this issue

Original URL
State: closed
Created 3 years ago
Comments: 35 (21 by maintainers)

Most upvoted comments

Thanks for the .zip of your publish directory. It definitely makes it easier to understand what is happening.

Using your instructions, I now understand the difference and am able to reproduce the problem myself.

Using .csproj:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net5.0</TargetFramework>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="System.ServiceProcess.ServiceController" Version="5.0.0" />
  </ItemGroup>
</Project>

and Program.cs:

using System;
using System.ServiceProcess;

namespace Repro48620
{
    class Program
    {
        public static void Main(string[] args)
        {
            Console.WriteLine(new Service());
        }

        class Service : ServiceBase
        {
        }
    }
}

“Folder” Publish with the default settings:

Now change “Target runtime” to win-x64, leave 'Framework-dependent` the same, and publish again

Run the published app, and you get:

Unhandled exception. System.PlatformNotSupportedException: ServiceController enables manipulating and accessing Windows services and it is not applicable for other operating systems.
   at System.ServiceProcess.ServiceBase..ctor()
   at Repro48620.Program.Service..ctor()
   at Repro48620.Program.Main(String[] args) in C:\Users\eerhardt\source\repos\Repro48620\Repro48620\Program.cs:line 10

Notice that if you delete the bin and obj folders and just publish directly for win-x64, and run the published app, it works just fine. So for now, my suggestion is to ensure your publish directory is cleaned before publishing. That will help you avoid the problem.

The issue is that the first “portable” Publish is laying down the PNSE version of System.ServiceProcess.ServiceController.dll directly in the publish directory, which is correct because this is a “portable” app. The windows-specific version is going into runtimes\win\lib\netstandard2.0, where it is getting picked up correctly at runtime.

However, the 2nd framework-dependent / win-x64 publish is not overwriting the PNSE version of the file. But it should be, because this is no longer a “portable” publish. It is windows specific. So the windows specific assembly should be going directly to the publish folder, and not into a runtimes\... folder. I’m not exactly sure why publish isn’t working correctly.

Since this is a “publish” bug, and not a runtime bug, I’m moving it to dotnet/sdk.

cc @dsplaisted

eerhardt on Feb 24, 2021

@marcpopMSFT - Based on the above response, I think some one from the sdk needs to take a look. This issue is not specific to VS. May be ‘dotnet publish’ should always overwrite all files. /cc @dsplaisted

vijayrkn on Feb 26, 2021