Open LegacyNsfw opened 5 months ago
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
).
Thanks!
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...
@ab-tools We understand the issue, and we have no fix this at this time, as I mentioned above.
Current behavior
Repro steps:
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?