Paket VS ProjectReunion

I'm not sure if it will help in your scenario, but faced with a similar problem (~80 project solution, mixed c#/f#, with varying dependencies), I found success with Paket (https://github.com/fsprojects/Paket)

It is much more prevalent in the f# community (at this point `dotnet restore` is a perfectly fine default until you hit trouble), but isn't limited to just being applied there.

You can find the official docs here: https://fsprojects.github.io/Paket/

Another thing that might be worth considering for you is Paket. This is an alternative to using nuget, directly, and will take a little bit of setting up (follow their instructions), but once you have it, it will make sure that all dependencies and transitive dependencies for all your projects are the same. Not 100% sure if this would solve the issue for you, and it might be tricky if the realApplication has unknown shared dependencies with the other projects, but you can give it a try.

Check out https://fsprojects.github.io/Paket/ and https://fake.build/ and https://docs.microsoft.com/en-us/dotnet/fsharp/get-started/get-started-vscode for playing with F#.

So I am stuck again when I want to create a web app. Don't laugh. Once again, I come from *NIX environment and the way everything is started in WebSharper is quite confusing at first. I tried to go installation documentation but I don't use Visual Studio nor MonoDevelop. Using paket also doesn't solve my problem since they also seem to use Visual Studio or MonoDevelop.

a bit of follow up: this is because the init command you ran defaulted to those frameworks. it could be smarter, or it could default to something more recent. I opened this PR to update this default.

If this would be true, there would be no reason for something like Paket to exist.

I agree with the author about the slow inner loop experience. Recompiling the whole app to see browser changes gets tiring. The .NET team is planning a series of updates to address this in .NET 6. https://github.com/dotnet/core/issues/5510

I also dislike the default workflow for dealing with Nuget forks. I switched to Paket for dependency management which makes this much simpler. https://fsprojects.github.io/Paket/

Also, I stumbled on this ticket https://github.com/fsprojects/Paket/issues/3064 which seems to confirm my fear that Paket is limited to importing files from Github, not entire packages, but I'm still hoping.

The issue is described here: WebView2 does not support passing in a CoreWebView2Environment · Issue #1170 · microsoft/WindowsAppSDK (github.com)

.. and how many of the Microsoft applications actually use WinUI3? As far as I can tell they're doing their own thing (Office) or are Electron (Teams) or, at least in Windows 10, haven't actually been updated from WinForms.

The overhead of WinUI3 is pretty huge. The visual designer, a winning feature of Visual Studio for decades, is AWOL. Why? It's XAML, the same as the previous XAML designer! It's just .. broken?

The backward compatibility story is a disaster: you can get stuck in the UWP sandbox https://github.com/microsoft/WindowsAppSDK/issues/1780

What's the big Microsoft WinUI3 flagship app, then? Something people are actually using? Rather than just a few system dialogues. (How many Win11 settings pop up a Win32 dialogue box, still?)

Development for WinAppSdk and WinUI 3 is also very slow and Microsoft seems to not want to push it and invest more developers into it for some reason. They try to improve the framework, is just it's a small team. For example it was a headacke to apply the Mica backgrop and required unmanaged code, they made it simpler and reduced it to a line of code but it took months. I have 2 out of 7 issues fixed on WinAppSdk repository and 0 out of 8 issues fixed in the WinUI 3 repository (some of the older than a year). This are just my issues, there are many other opened by other developers. So yeah, it wasn't fun at all. PoweshellSDK had an issue with the Import-Module command and it wasn't fixed for more than a year and probably won't be ever fixed, but I'm glad I found a workaround, even more clean and more safe, otherwise I couldn't have added the posibility to uninstall and change Store apps.

As far as I know, there are still some issues with OIDC integration. See this, for example.

this I'm interested in. WinAppSDK is open source.

I think the issue is actually the sandboxing and other stuff. WinRT StorageProvider API is known to be extremely slow and NTFS / Windows IO subsystem is itself already quite slow compared to UNIX. The issue IIRC is that StorageProvider is designed for sandboxing and the way they implemented that involves doing RPCs to other processes. So there's probably some heavy context switching involved, but it's architectural, and so the voice recorder was never fixed.

https://github.com/microsoft/WindowsAppSDK/issues/8

Disclaimer: I work for Microsoft. I even work on WindowsAppSDK just not the WinUI parts. People far more graphically inclined and talented than I handle that 😀