Platform Sample does not run on OSX

[hazel-bohon]

Describe the bug

Description

When running the platform sample from the getting started > quick start page, I was unable to get the Platform project to run. I encountered the following error:

➜  Platform dotnet run
/usr/local/share/dotnet/sdk/8.0.403/Microsoft.Common.CurrentVersion.targets(5321,5): error MSB3024: Could not copy the file "/Users/hazel/dev/tutorials-quickstart/Platform/obj/Debug/net8.0/apphost" to the destination file "bin/Debug/net8.0/Platform", because the destination is a folder instead of a file. To copy the source file into a folder, consider using the DestinationFolder parameter instead of DestinationFiles. [/Users/hazel/dev/tutorials-quickstart/Platform/Platform.csproj]

The build failed. Fix the build errors and run again.

Expected behavior

We expect the application to run on OS X.

Actual behavior

There is an error. Other parts of the sln work without issue.

Versions

3.2.3

Please list the version of the relevant packages or applications in which the bug exists.

Steps to reproduce

1. On OSX, download the quick start zip project.
2. Unzip the project and navigate to the Platform directory
3. run dotnet run

Relevant log output

/usr/local/share/dotnet/sdk/8.0.403/Microsoft.Common.CurrentVersion.targets(5321,5): error MSB3024: Could not copy the file "/Users/hazel/dev/tutorials-quickstart/Platform/obj/Debug/net8.0/apphost" to the destination file "bin/Debug/net8.0/Platform", because the destination is a folder instead of a file. To copy the source file into a folder, consider using the DestinationFolder parameter instead of DestinationFiles. [/Users/hazel/dev/tutorials-quickstart/Platform/Platform.csproj]

The build failed. Fix the build errors and run again.

Additional Information

Workarounds

No known work arounds.

Possible solutions

🤷🏻‍♀️

Additional information

[DavidBoike]

So, this was a neat one. It was only because the project was called Platform.csproj.

The build system tries to copy the "entry gate" executable from the SDK into the project so there's something to double-click on. On Windows you get Platform.exe, on Linux and MacOS you get Platform.

Except there's already a directory platform that contains the ServiceControl and ServicePulse code.

On Windows, the presence of .exe means you'll never get a collision. Linux is case-sensitive so platform and Platform are different. But MacOS is (normally) case-insensitive so that's a collision and the file can't be copied.

You'd have the same problem on Linux if the project was platform.csproj.

I'm fixing it in Particular/docs.particular.net#6887 by renaming the Platform.csproj to PlatformLauncher.csproj to match (almost) every other project that uses the platform launcher.

I'll leave this open because at some point we could try to actually fix this, but it would require both:

1. Some build target to detect that the project the code is hosted in is named Platform and to therefore rename the folder platform with the ServiceControl/Pulse bits to something else.
2. Code in the package itself to look first for the platform folder to launch the apps, and if the filesystem object at that location isn't a directory (because it's the executable) to then search in the location with the secondary name.

But for now it's definitely easier to just not name a project Platform.csproj.