(Solved) Unity Web Request doesn't work in UWP builds (cannot resolve destination host Curl error 6)

Unity Web Request doesn't work in UWP builds (cannot resolve destination host Curl error 6 according to the UnityPlayer.log file), but works just fine in the Editor and also when I hit play on Visual Studio (either in Debug/Master mode).

That's pretty much the issue. I have described it here too https://forum.unity.com/threads/201...ens-pc-but-system-net-webrequest-does.780449/.

It is beyond me why the exact same app would work when hitting play on Visual Studio, but not when downloading the build from the Microsoft Store. I've also tested such same app on Android devices and it works just fine.

- So far, the issue has persisted both in Unity 2019.3.3f1 and Unity 2020.1.0f1.
- I'm using Visual Studio 2019.
- I've tested the UWP build in two different Windows PCs and two different networks (my home's network and my Android device as a mobile hotspot).
- I do have all internet capabilities enabled (internet client, internet client server, private network client server).
- I'm building the VS Solution from Unity with .NET Standard 2.0.
- My build settings are this:


For obvious reasons, it takes hours to iterate on this issue. In some way, I wished the problem also happened either in the editor or on the Visual Studio solution, because then I would be able to debug closely. Instead, I must wait for several hours or even a day to try and test a different thing. It's so frustrating and nonsense. Please, help.

 

Hi @Tautvydas-Zilys ,

We're still developing the app, so it's available only to a private audience. If you could give me an email address (hotmail/outlook) for me to add you to the internal test group that would work.

Here's attached the AppXManifest.xml from where Windows Store installs the app at any case.

P.S. Yes, this issue only happens when I download the app from the Microsoft Store. It works just fine with the Visual Studio project (when hitting play in either Debug/Master/Release mode) that generates the .appxupload packages for submission.

 

Hi @Tautvydas-Zilys ,

I do have them enabled. I do it from Unity in Player Settings, and I can also see them in Visual Studio. See the screenshots.






But you know, it really took me by surprise to realize that I couldn't see the capabilities enabled in the appxmanifest. So I thought to myself that maybe these aren't supposed to show in this file -- are you sure these are supposed to show in the appxmanifest.xml where the Windows App gets installed? (I'm not an expert)

If that's the case, this would be a very weird issue. Basically, it would mean that the capabilities are enabled in the project but they somehow get cutoff during deployment...

 

I'm so sorry. I have messed up in the store submission. (I still will explain with detail in case it happens to someone else.)

A submission has many parts (e.g., "store listings" and "packages").


The version that I was working with was 4.0... On this version, I was 100% sure that the internet capabilities were enabled.


I also decided early on to always keep track of which version I was seeing in the store by modifying the "store listing" with a short note (submission 5 ... 6... 7 ... etc.).


But after taking a closer look into the appxmanifest.xml that I shared earlier on this thread, I realized that the version installed was 1.0.... How was this possible, given that the store listing clearly said submission 7 (the latest version that corresponded to 4.0)?

It turns out the Microsoft Store gives priority to the last Package Flight you uploaded among the accounts that are added to the corresponding internal test group. That is, I have an internal test group that is configured in the normal submission track, but is also connected to the package flight.

This was the source of the very confusing behavior. On the one hand, I was able to see the short note that said "submission 7", that come from the Store Listing section of... well... Submission 7. But the package that the Microsoft Store listing was serving was not that one of Submission 7 (version 4.0...), but the one of Package Flight 2!!! (version 1.0).


If I'm correct, the rank is the decisive factor here for the packages being served. Remember package Flights only takes packages (it's not a complete submission). Internet capabilities were a problem at first, then I fixed it in the non-flighted submision track, but forgot (and didn't understand) that the package flight would always override the non-flighted submission (but only the packages, not all the other parts of the submission) as long as the rank was higher.

This completely explains why it seemed to work just fine right before submitting to the Microsoft Store.

Apologies for the inconvenience @Tautvydas-Zilys . I'm really grateful for all your help. Hadn't you suggested to take a look at the appxmanifest.xml installed, I wouldn't have noticed the inconsistency.

 

I meet the same error too.It happened when I debug it in VS,it works ferfect,but but not when building packages.I set the capability correctly too.