Can't add a new Uno application project to an existing solution in VS2022

[LegacyNsfw]

Current behavior

Repro steps:

1. I have an existing Visual Studio solution that contains a couple of WinForms applications and a couple of .Net Standard libraries.
2. I would like to add an Uno application (which will eventually replace the WinForms applications).
3. I used uno-check to add the Uno dependences.
4. I downloaded and installed the Uno extension (vsix file).
5. I loaded the solution, right-clicked on the top root node of the solution, and picked Add, Add New Project...
6. I picked "Uno Platform App" from the list of project templates
7. I added a project name
8. I clicked "Create"

Expected results: an Uno application project is added to my solution.

Actual results: This dialog:

Note that there is no "same directory" checkbox on the previous screen. That option only exists when creating a new solution. I am not creating a new solution. I am adding a new project to an existing solution.

Expected behavior

After clicking "Create" there should be a new Uno Application project in my existing solution, alongside the existing projects.

How to reproduce it (as minimally and precisely as possible)

Unzip this file, open the solution inside it, try to add a new Uno Platform application as described above. UnoNewAppRepro.zip

Workaround

I don't know of one.

Works on UWP/WinUI

None

Environment

No response

NuGet package version(s)

No response

Affected platforms

Windows (WinAppSDK)

IDE

Visual Studio 2022

IDE version

17.9.6

Relevant plugins

No response

Anything else we need to know?

If someone can point me to where the code is, I'm willing to take a shot at fixing this. But first I'd like to know why (or whether) this requirement seemed like a good idea in the first place. Even for new solutions, unless the application is tiny, it's normal to have multiple projects in subdirectories beneath the directory that contains the solution file.

Is there any scenario in which this "same directory" requirement is truly required, by-design?

Is other work required, in order to properly support the not-same-directory scenario?

[jeromelaban]

Thanks for the report. We're currently hitting a limitation of Visual Studio, where VS does not allow for custom sln files provided by a nuget package. The code for this part is not public a this time.

The best way, for now, to add a new project in an existing solution is either by creating it from a separate visual studio instance, then copy the project to the appropriate location, or by using dotnet new (using https://new.platform.uno).

[LegacyNsfw]

Thanks!

[ab-tools]

Just ran into the same issue here - a pity that this cannot be fixed as it might block new users getting into the Uno Platform if they hit this issue at the very start...

[jeromelaban]

@ab-tools We understand the issue, and we have no fix this at this time, as I mentioned above.

[LegacyNsfw]

I'm having trouble with the suggested workaround...

1. Create a new Uno application project (Windows + Android + iOS + Linux, with XAML)
2. Build the app successfully
3. Copied the directory into an existing solution
4. Tell Visual Studio to build the project in that existing solution
5. Build fails due to fill file paths in obj/project.assets.json
6. Delete the obj directory
7. Tell VS to build the project again...

Expected result: it builds

Actual result: "1>C:\GitHub\PcmHammer\Apps\PcmHammer2\App.xaml.cs(70,32,70,57): error CS0103: The name 'ReactiveViewModelMappings' does not exist in the current context"

I saw this discussion about needing to install the Uno.Extensions.Reactive package:

https://github.com/unoplatform/uno/discussions/10214?sort=old

The package manager UI indicates that it's already installed as a transitive dependency. I hit the install button anyway, but still get the same compiler error.

What steps should I take to troubleshoot this problem?

[jeromelaban]

I'm having trouble with the suggested workaround...

It is likely that you have nuget restore issues. Uno apps depend on global.json, as well as the Directory.Build.props/.targets. Make sure to include the contents of those files in your existing solution.