Auto-adjust LauncherPath in Duality solution template to match executable name

[ilexp]

Summary

As mentioned in this comment from PR #840, related to issue #847, the Duality solution template renames the launcher executable to match the project name. However, this leaves the editor without working run, debug and profile buttons. This should be fixed by providing an auto-adjusted EditorUserData.xml in the solution template.

Analysis

• There already is an embedded default EditorUserData.xml in the editor executable. This should remain where it is, as it will jump in when users delete the file, or not add it to version control in the first place.
• It can serve as a basis to copy-paste from when adding a default user data file to the solution template, with a LauncherPath item that can be auto-renamed by dotnet new. This would solve the issue.
  • However, this won't help in cases where editor user data isn't added to version control, which actually matches with recommendations, especially in team projects.
• An alternative solution would be to allow the editor to locate the launcher itself.
  • The launcher path getter would probably be a good place to provide a fallback in case the current path doesn't exist or is otherwise invalid.
  • Search all .exe files in the project / working directory (non-recursive) and pick the first one that...
  • ...isn't the editor executable that is currently running.
  • ...is named after the project?
  • ...is a valid .NET Assembly?
  • ...references Duality.dll?
  • It should be avoided to actually load the assembly, since that might have unforeseen consequences.

[Barsonax]

We can also add a EditorAppData.xml that has to be added to source control and which can contain settings that are not only for the current user such as this path. We should avoid creating another works on my machine situation.

[ilexp]

That would also be an option! And slightly increase scope of the issue, but we might have good use for that kind of data storage in the long run.

However, I'd propose to call it ProjectSettings.xml instead, as (in my head at least) it states its purpose more clearly and draws a useful parallel to what people know from Unity.

[Barsonax]

That would also be an option! And slightly increase scope of the issue, but we might have good use for that kind of data storage in the long run.

Yeah but I think its worth it as like you said there are good use cases for that kind of data storage

However, I'd propose to call it ProjectSettings.xml instead, as (in my head at least) it states its purpose more clearly and draws a useful parallel to what people know from Unity.

Sounds good