Closed weitzhandler closed 4 years ago
Thanks, Which projects are you referring to ?
Everything under SolutionTemplate
.
Can we have all Uno solution/projects in new csproj format, by using SdkExtras?
Unfortunately no... UWP, and all Xamarin projects cannot use the SDK-style format, as Visual Studio does not support it yet.
Would you consider using MSBuildSdkExtras?
It's not a matter of msbuild extras, those only work for libraries, not head projects. You can vote on this issue.
I think I understand now. Let me close this issue then. Thank you!
It's not a matter of msbuild extras, those only work for libraries, not head projects.
Would you be curious in having the shared project of the template as a multi-targetting external assembly, which then uses the new SDK style (See How to Move Uno Platform Pages to a Multi-Targeting Library by @MelbourneDeveloper), which we can then easily transport to .NET Core, and once there, upgrade the logging system and use Generic Host and service registration altogether?
Well apparently there still issues with it (i.e. hot reload), so I guess it's not yet ready.
@weitzhandler apparently, @nickrandolph was able to fix this, and he has instructions in his article. Unfortunately, I haven't gotten around to checking it out yet.
upgrade the logging system and use Generic Host and service registration altogether?
I'm referring to this.
The biggest issue with moving to multi-targeted solution is that the support in Visual Studio for multi-targeted apps is really bad at the moment. Unless you hack the project files (eg https://nicksnettravels.builttoroam.com/multi-targeted-productivity/) then visual studio will build for every platform, every time, which is really painful in a large project. I think it makes sense for reusuable libraries (eg mvvmcross) to use multi-targeting because at the end of the day you want to generate a single nuget package with all the targets in it. However, for cross platform apps I think the VS experience is better with shared projects and since you can't avoid having separate head projects, there's no real downside to having a shared project. This may all change with the fall out from .net5 and with Maui which will be a single multi-target project. Both of these are going to require VS to handle multi-targeted projects better
Nick's .NET TravelsIn my previous post on using multi-targeted cross platform projects I showed how you can add additional target frameworks to allow the addition of platform specific code to a library. One of the downsides of this approach (versus perhaps using a shared project) is that the library gets built once for every target framework that’s … Continue reading "Improving Developer Experience with Multi-Targeted Visual Studio Projects"
@nickrandolph actually, I'd say the Visual Studio experience with shared projects is almost as bad. Most of the refactoring tools are broken in shared projects. In solutions where I use shared projects, I'm constantly battling issues.
Yes, Visual Studio support for multi-targeting has issues, but personally, I'd rather deal with those than the issues with shared projects.
Regardless of the tooling, from a project management and file locations perspective, I think dealing with shared projects is also more complicated. For example if you're looking at a GitHub or DevOps repo's code with shared projects, it's less straight forward than inline files. Also switching context has been an ultimate nightmare in VS, tho things have gotten better recently.
@weitzhandler the tooling is a big part of the issue. One problem I am facing is that the XAML designer doesn't work in the multi-targeted common library. Not sure why and it might be possible to fix it.
Ultimately, someone needs to get this feedback to the Visual Studio team because they've been ignoring these problems for years. I've tried to report things in the past but it just gets lost. They need to at least fix the experience for one of the options. I have a feeling that they don't want to maintain shared projects anymore and might drop them in the next version of Visual Studio. It would be nice if they'd tell us what there plans are. If they're planning on pushing on over the other, we should know about it.
Indeed! They're sometimes locking the issues for good not even allowing a discussion. Do you guys think it makes sense to open a new issue with an outline of the various aspects of both shared and multi-targeted projects put together and let them decide on the feasibility and priorities?
Interestingly, Xamarin.Forms core project only has to be .NET Standard, how is it compared to Uno in this aspect? BTW, this is what a XF app core csproj look like:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>netstandard2.0</TargetFramework>
<ProduceReferenceAssembly>true</ProduceReferenceAssembly>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Xamarin.Forms" Version="4.6.0.1141" />
<PackageReference Include="Xamarin.Essentials" Version="1.5.3.2" />
</ItemGroup>
</Project>
@weitzhandler I remember that a lot of old XF samples used to use shared projects, but gradually they started getting rid of those. I can't say what the best choice for Uno would be, but I can tell you that I'd definitely prefer to work with a single .NET 5 / .NET 6 project in the long run. That would make life a lot easier, but nobody knows when that will happen.
A couple of comments on XF v Uno and the use of shared projects
All good points @nickrandolph
Still, shared projects need a lot of work in Visual Studio. I wish the Visual Studio team would give us some options.
I've actually found that my multi-targeting libraries have the opposite behavior. they don't rebuild every time. I have to manually rebuild in many cases.
I don't think any of this is a reflection on Uno. The point is that we're talking about huge swathes of functionality in Visual Studio that are simply unfinished.
@nickrandolph here
- With Uno, my preference is ... I leave only UI related code in the multi-targeted
Yes that's the intention - rather than shared. Shared code feels much more vulnerable for some reason, and it's also harder to maintain.
What would you like to be added:
Have the VSIX/cli template generate new csproj-format projects. It should use MSBuildSdkExtras for the unsupported ones.
Why is this needed:
The old csproj is irritating and inconvenient.
For which Platform:
Related: #4173 Related: https://github.com/microsoft/microsoft-ui-xaml/issues/3372