search

unoplatform / uno

Open-source platform for building cross-platform native Mobile, Web, Desktop and Embedded apps quickly. Create rich, C#/XAML, single-codebase apps from any IDE. Hot Reload included! 90m+ NuGet Downloads!!
https://platform.uno
Apache License 2.0
8.89k stars 720 forks source link

Use new csproj format #4172

Closed weitzhandler closed 4 years ago

weitzhandler commented 4 years ago

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

jeromelaban commented 4 years ago

Thanks, Which projects are you referring to ?

weitzhandler commented 4 years ago

Everything under SolutionTemplate. Can we have all Uno solution/projects in new csproj format, by using SdkExtras?

jeromelaban commented 4 years ago

Unfortunately no... UWP, and all Xamarin projects cannot use the SDK-style format, as Visual Studio does not support it yet.

weitzhandler commented 4 years ago

Would you consider using MSBuildSdkExtras?

jeromelaban commented 4 years ago

It's not a matter of msbuild extras, those only work for libraries, not head projects. You can vote on this issue.

weitzhandler commented 4 years ago

I think I understand now. Let me close this issue then. Thank you!

weitzhandler commented 4 years ago

Related:

weitzhandler commented 4 years ago

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?

weitzhandler commented 4 years ago

Well apparently there still issues with it (i.e. hot reload), so I guess it's not yet ready.

MelbourneDeveloper commented 4 years ago

@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.

weitzhandler commented 4 years ago

upgrade the logging system and use Generic Host and service registration altogether?

I'm referring to this.

nickrandolph commented 4 years ago

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 Travels
Improving Developer Experience with Multi-Targeted Visual Studio Projects - Nick's .NET Travels
In 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"
MelbourneDeveloper commented 4 years ago

@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.

weitzhandler commented 4 years ago

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.

MelbourneDeveloper commented 4 years ago

@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.

weitzhandler commented 4 years ago

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>
MelbourneDeveloper commented 4 years ago

@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.

nickrandolph commented 4 years ago

A couple of comments on XF v Uno and the use of shared projects

MelbourneDeveloper commented 4 years ago

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.

weitzhandler commented 4 years ago

@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.

weitzhandler commented 4 years ago

I opened https://github.com/microsoft/microsoft-ui-xaml/issues/3372.