search

microsoft / dotnet

This repo is the official home of .NET on GitHub. It's a great starting point to find many .NET OSS projects from Microsoft and the community, including many that are part of the .NET Foundation.
https://devblogs.microsoft.com/dotnet/
MIT License
14.33k stars 2.21k forks source link

UWP Release Build requires Dependancy Microsoft.NET.CoreFramework.Debug.2.2.appx #1078

Open cdm22 opened 5 years ago

cdm22 commented 5 years ago

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 commented 5 years ago

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

cubed-it commented 5 years ago

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

EzraWard commented 5 years ago

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 commented 5 years ago

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

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

seankanderson commented 4 years ago

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

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

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

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

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.

appxbundle_csproj_diff-bad-left-good right appxbundle_csproj_diff-bad-left-good right-appx-contents
jtorjo commented 4 years ago

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

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

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

jtorjo commented 4 years ago

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

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

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

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

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

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

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

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

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 commented 3 years ago

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 commented 3 years ago

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

keithnicholson commented 3 years ago

@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

RuddyOne commented 2 years ago

Keeping this issue alive... Any news? Also having the same issue.

RemVas commented 2 years ago

I do not know if this is the right way to solve the "Debug" dependency when building a release version, but what worked for me was to edit the files "runtime.win10-??????.Microsoft.Net.UWPCoreRuntimeSdk.targets" found in "C:\Users\CurrentUser\.nuget\packages\...\...\build".

  1. Go to C:\Users\CurrentUser\.nuget\packages
  2. Search for files named "*.Microsoft.Net.UWPCoreRuntimeSdk.targets"
  3. Edit ALL found files and remove ".Debug" from the references to "Microsoft.NET.CoreFramework.Debug.2.2.appx" (anyway, why is the Debug version referenced there!?!?) -- important to edit ALL files, if you will build for "Any CPU", or you want to be on the safe side and make sure that the problem does not remain to haunt some CPU configuration
  4. Rebuild your project -- the dependency to Microsoft.NET.CoreFramework.Debug.2.2.appx should be gone now.

It is important to note that this hack will work only for a Release compilation, and compiling for Debug (without .NET Native tool chain) will not work properly any more. Just deleting ".Debug" from the build target files is a bit too "unsophisticated'. To make them work with both Release and Debug a more conditional editing would be necessary!

RemVas commented 1 year ago

It seems that using the option "Compile with .NET Native tool chain" is more or less a requirement for a UWP app these days, so using the hack I mentioned previously to edit the "targets" files will not really create a usable app, even if the dependency problem is "solved". In the end, I had to restructure my application (and remove some valuable functionality from it) in order to be able to compile it with .NET Native tool chain.

This is a little bit sad, because mine is a multiplatform app and the limitations imposed by compiling with .NET Native tool chain only exist for the UWP project. On all the other platforms (iOS, Android, macOS) the application works fine with dependencies, and there is no need to limit any app functionality.

FrancyAngy commented 1 year ago

the file you need for the 64 bit version is in C:\Program Files (x86)\Microsoft SDKs\UWPNuGetPackages\runtime.win10-x64.microsoft.net.uwpcoreruntimesdk\2.2.14\tools\Appx, and the 32 bit is in C:\Program Files (x86)\Microsoft SDKs\UWPNuGetPackages\runtime.win10-x86.microsoft.net.uwpcoreruntimesdk\2.2.14\tools\Appx but if you don't find them, i attached a version of each file found files.zip files (x86).zip