Dotnet: UWP Release Build requires Dependancy Microsoft.NET.CoreFramework.Debug.2.2.appx

[cdm22]

Visual Studio Professional 2017 15.9.6
Building a Release Version of the APP.
Why does it now add the Debug dependency?

Using Package Microsoft.NETCore.UniversalWindowsPlatform 6.1.9
Dependencies x64:
Microsoft.NET.CoreRuntime.2.1.appx
Microsoft.VCLibs.x64.14.00.appx

Upgrade to:
Microsoft.NETCore.UniversalWindowsPlatform 6.2.8
Dependencies x64:
Microsoft.NET.CoreFramework.Debug.2.2.appx
Microsoft.NET.CoreRuntime.2.1.appx
Microsoft.VCLibs.x64.14.00.appx

[danielleiszen]

I have the same problem during install, if I uncheck "Compile with .NET Native tool chain" on project properties.

[cubed-it]

This additional dependency with almost 10MB per plattfrom is not particularly a lightweight. So what is it for?

[EzraWard]

My team's UWP apps are seeing this added dependency too. We are unsure if the addition of this dependency is caused by something we've done or otherwise.

[cdm22]

I just went back to this version 6.1.12 that does not include that dependency.
Install-Package Microsoft.NETCore.UniversalWindowsPlatform -Version 6.1.12

Hope that helps until they get it resolved!

[jtorjo]

Any work on this?
This is still happening on latest 6.2 version - I simply can't release an app because of this!

[seankanderson]

Just had a beta tester report a failed app install due to this. What is the official work-around or fix? Should I downgrade the project to Microsoft.NETCore.UniversalWindowsPlatform version 6.1.12? Between this and all the breaking changes going to .NET Core 3.1 (for other dependencies) it has been hell trying to keep projects building and installing.

[jtorjo]

Apparently, MS doesn't quite give a flying f*ck.
I'ts been over 6 MONTHS, and there's no resolution to this.

What I do suggest is this: here's how to create an .appinstaller file that allows people to install your app. Not trivial at all, but I for one think it's the only thing that works
https://docs.microsoft.com/answers/questions/4027/uwp-cant-install-signed-application-non-ms-storeco.html

[seankanderson]

Creating the appinstaller file did not help me. I got it to install the app but if I try to link to the file it just pulls up the XML in the user's browser and they don't know how to deal with that. Total non-solution when trying to distribute to beta testers. What kills me is that this WAS working without issue. I was testing this appx on clean Windows 10 VMs and it was installing beautifully.

[jtorjo]

@seankanderson I've answered you on the other forum (https://docs.microsoft.com/answers/questions/4027/uwp-cant-install-signed-application-non-ms-storeco.html) Please let me know if it works

[seankanderson]

I resolved this by reducing the AppxBundlePlatforms property down to only x64.
The appxbundle with the missing dependencies was built/packaged with all of the of the platforms selected.
This, for some reason, results in the build not rolling all of the dependencies up into an app DLL. In my case, notice Nevitium.UWP.dll in the appx contents comparison picture below.

[jtorjo]

I resolved this by reducing the AppxBundlePlatforms property down to only x64.
The appxbundle with the missing dependencies was built/packaged with all of the of the platforms selected.
This, for some reason, results in the build not rolling all of the dependencies up into an app DLL. In my case, notice Nevitium.UWP.dll in the appx contents comparison picture below.

Awesome to hear! Yeah, I think I missed to mention that I was only building for x64 as well (notice that the Package dependencies are only x64 related). Building for all platforms (x86, x64, arm) is probably a lot more complicated, but I assume doable.

On my side, I really only need x64.

Best,
John

[simader]

Any news on this?

When I try to install my UWP Release App I get on some x86 devices:
App installation failed with error message: Deployment of package Microsoft.NET.CoreRuntime.2.2_2.2.27902.3_x86__8wekyb3d8bbwe was blocked because the provided package has the same identity as an already-installed package but the contents are different. Increment the version number of the package to be installed, or remove the old package for every user on the system before installing this package. (0x80073cfb)

[PrinceCharles23]

almost to the day one year ago this was posted and there is no actionable reply from microsoft on the issue - great!

[jtorjo]

@PrinceCharles23 Don't expect MS to do anything about. Ever. I've simply just learned to live with it. Found workarounds - that's all you can do.

[PrinceCharles23]

@PrinceCharles23 Don't expect MS to do anything about. Ever. I've simply just learned to live with it. Found workarounds - that's all you can do.

i am working with microsoft technologies for over 20 years now. so this is not news to me. makes me question my life decisions each time, tho.

anyways: do you have a workaround since you suggested that as a solution?

[simader]

What is your workaround?

For my case it seems that the unsigned package Microsoft.NET.CoreRuntime.2.2_2.2.27902.3_x86__8wekyb3d8bbwe is curropt, and i have to uninstall it on every PC where i want to install my UWP app.

[jtorjo]

You need to create an .appinstaller file, kinda' like shown here:

https://docs.microsoft.com/en-us/answers/questions/4027/uwp-cant-install-signed-application-non-ms-storeco.html
(note: for some reason, the link in there is broken)

The installer should look more or less like this
https://phot-awe.com/resources/test.appinstaller

[PrinceCharles23]

ok

You need to create an .appinstaller file, kinda' like shown here:

https://docs.microsoft.com/en-us/answers/questions/4027/uwp-cant-install-signed-application-non-ms-storeco.html
(note: for some reason, the link in there is broken)

The installer should look more or less like this
https://phot-awe.com/resources/test.appinstaller

ok, thx! still have no clue what to do with this installer-file (and/or what i will have to add to make my app work) but - as i understand it - this just adds the culprit to the package but does not remove the neccessity to have the dependency in the first place. in other words: it just installs the debug dependency on production!?!

[jtorjo]

ok, thx! still have no clue what to do with this installer-file (and/or what i will have to add to make my app work) but - as i understand it - this just adds the culprit to the package but does not remove the neccessity to have the dependency in the first place. in other words: it just installs the debug dependency on production!?!

Yes, that is entirely correct. I am not aware of anything else that truly works

LATER EDIT: To add a bit more context to this. I gave up A LONG TIME AGO to try to constrain myself to the joke that is MS Store. Thus, the above is 100% needed.

Just in case you're publishing to MS Store, I highly suggest you don't anymore. It will be a bit complicated to digitally sign your package at first (for one, you'll need to buy a digitally signing certificate), but once that is done, it'll be sooo much easier to do stuff.

For instance, you'll be able to use libs that WACK now disallows, and since the UWP is so full of open source libs (just kidding of course), you'll find a that lot of stuff is actually available but doesn't conform to WACK (you would need to port them to UWP, but that's a lot less work than recreating something from scratch). Case in point - naudio (an insanely awesome audio lib)

[EhsanJahoon]

Seems it is related to Microsoft.NETCore.UniversalWindowsPlatform version !
The issue appears in 6.2.10 but it works fine in 6.2.9

[jtorjo]

@EhsanJahoon No it doesn't . I've been using 6.2.9 for months and it's still the same. I think the issue dates back to 6.2.1 or something

[gsorensen]

I can confirm that whilst using 6.2.10 I also encountered this problem, and downgrading to 6.2.9 doesn't work either. Downgrading to the latest 6.1 release solves the issue in my case (The dependency is gone from the release build)

[devdeer-alex]

I want to add some strange stuff here: I have several releases named like "ReleaseTest", "ReleaseProd" and so on. All of them are without the DEBUG flag. If I deploy using the original "Release"-config it will not come with this error. It seams like MS is parsing for a magic string "Release" here and does generate this f....ing dependency whenever something is named differently.

[jtorjo]

@devdeer-alex That is very interesting, I will test this at some point.

[keithnicholson]

@jtorjo Any movement on this. It is affecting me as well on more than just the Debug dependency. It appears that an update, I'm guessing, to some other application has the same signature but different hash codes.

Microsoft.NET.CoreRuntime.2.2_2.2.27902.3_x64__8wekyb3d8bbwe was blocked because the provided package has the same identity
| as an already-installed package but the contents are different