WinUI 3: AppCenter includes dependency to UniversalWindowsPlatform about appcenter-sdk-dotnet HOT 12 OPEN

So I realize that this is not really helpful, but I created a fork here: https://github.com/Marv51/appcenter-sdk-dotnet

I ripped out anything that is not needed for Crashes & Analytics for a modern packaged WinUI app.

As soon as the UWP target is removed from the nuget package this issue is resolved.

I would contribute some stuff from my fork to this repo, but I think the support for various dotnet versions makes this difficult.

from appcenter-sdk-dotnet.

I have removed the UAP platform support from the nuget packages locally and removed any dependencies for the UAP platform using Nuget Package Explorer.
When I use these packages the problem is gone. A clean restore of the solution is way fast and requires 2GB less downloads.

Maybe there is a better solution than just removing all traces of UAP/UWP, but that certainly fixes the problem for me.

from appcenter-sdk-dotnet.

Hi @Marv51 and thank you for reaching out to us. I would like to clarify whether you were able to completely solve your problem?

from appcenter-sdk-dotnet.

When I produce my own nuget packages without any UWP/UAP content that resolves the problem.
However, that is, of course, not really a solution that is very sustainable.

from appcenter-sdk-dotnet.

Sorry for the delay, but I was unable to reproduce this issue, could you please provide us with a small demo project on which this error will be reproduced?

from appcenter-sdk-dotnet.

Hi @MikhailSuendukov
Thank you for looking into this issue.

I produced this repro:
AppCenterSDKRepro.zip

Go to your .nuget/packages folder. Delete all content. The nuget folder is usually in your C:/Users/YourName profile folder (maybe going to %NUGET_PACKAGES% works too).

When you unzip this project, and open the solution in Visual Studio 2022, make sure the "AppSDKRepro (Package)" is selected as "Set as Startup Project". I select "x64" and click "Run". Wait for the sample window with a test button to appear.

Observe that the project first restores about 1.5GB. But when you run the project, until a Window with a button appears the packages folder contains 4.1GB.

from appcenter-sdk-dotnet.

I apologize for the delay, I was able to reproduce this behavior, but when checking the size of the microsoft.netcore.universalwindowsplatform folder, it turned out that its size no more than 30 megabytes. Is this critical for you?

from appcenter-sdk-dotnet.

The microsoft.netcore.universalwindowsplatform folder may be the only direct dependency and it is pretty small. However, it pulls in many more dependencies. The size of these dependencies on disk is about 2.5GB. I find the packages.lock.json help me understand the dependencies a lot better.

And I think I mentioned it above, on a dev-machine that is not optimal, but acceptable.
However, this significantly slows down our CI builds. Meaning money and flexibility is lost. It makes caching of nuget dependencies in GitHub-Actions almost impossible, because the cache is only 5GB.

Look at this small extract from the top of tree that AppCenter pulls in:

      "Microsoft.AppCenter": {
        "type": "Transitive",
        "resolved": "5.0.3",
        "contentHash": "[...]",
        "dependencies": {
          "Microsoft.NETCore.UniversalWindowsPlatform": "6.2.8",
          "Newtonsoft.Json": "13.0.2",
          "SQLitePCLRaw.bundle_green": "2.1.5"
        },
},
      "Microsoft.NETCore.UniversalWindowsPlatform": {
        "type": "Transitive",
        "resolved": "6.2.8",
        "contentHash": "[...]",
        "dependencies": {
          "Microsoft.NETCore.Platforms": "2.1.0",
          "Microsoft.Net.Native.Compiler": "2.2.3",
          "Microsoft.Net.UWPCoreRuntimeSdk": "2.2.8",
          "NETStandard.Library": "2.0.3"
        },
},
"Microsoft.Net.Native.Compiler": {
        "type": "Transitive",
        "resolved": "2.2.3",
        "contentHash": "[...]",
        "dependencies": {
          "runtime.win10-arm.Microsoft.Net.Native.Compiler": "2.2.3",
          "runtime.win10-arm64.Microsoft.Net.Native.Compiler": "2.2.3",
          "runtime.win10-x64.Microsoft.Net.Native.Compiler": "2.2.3",
          "runtime.win10-x86.Microsoft.Net.Native.Compiler": "2.2.3"
        }
      },
"Microsoft.Net.UWPCoreRuntimeSdk": {
        "type": "Transitive",
        "resolved": "2.2.8",
        "contentHash": "[...]",
        "dependencies": {
          "runtime.win10-arm.Microsoft.Net.UWPCoreRuntimeSdk": "2.2.8",
          "runtime.win10-x64.Microsoft.Net.UWPCoreRuntimeSdk": "2.2.8",
          "runtime.win10-x86.Microsoft.Net.UWPCoreRuntimeSdk": "2.2.8"
        }
      },

from appcenter-sdk-dotnet.

I apologize for the long delay. We looked at your problem and realized that apparently the problem lies in the WAP wrapper of the application. Because when running a WinUI application without a wrapper, the UWP transitive dependency does not appear in package.lock. Most likely, it is the WAP wrapper that pulls up these transitive dependencies, since it may require a UWP target for a reverse dependency or for implementing some functionality that relates to it. In our nuspec files, all transitive dependencies are divided into target frameworks, so the WinUI application should not use the UWP framework. If you have any ideas regarding this it would be very helpful.

from appcenter-sdk-dotnet.

I tried looking deeper into this with binlog and structured log viewer but did not find any new clues why this is happening.

The way I see most nuget packages handle this is that they have separate nuget packages for UWP and WinUI. I understand that might not be an option for you. Personally I think making a separate WinUI 3 AppCenter package would very interesting.

I think I might build my own packages for now, then I can only include the relevant platforms.

I guess this is likely something the WinUI team needs to fix. You might have more influence on them as an internal/partner request.

from appcenter-sdk-dotnet.

Thank you for sharing this idea with us. We will monitor to see if others encounter similar problems. In the meantime, we'd appreciate it if you could keep us updated on your progress with building the packages you mentioned.

from appcenter-sdk-dotnet.