none
[UWP] Can't connect to localhost service RRS feed

  • Question

  • Hi,

    I'm doing all my development on a laptop for a little while and for some reason my UWP app won't connect to my localhost service api.   It's connecting fine to the 'live' service on Azure.

    Allow local Network Loopback is checked.

    I can navigate to the service api http://localhost:52143/api/app/test in Chrome and IE  (and see the results of a test method) , but strangely not in Edge. which tells me it can't reach this page.

    Any suggestions gratefully received.

    Thanks,
    Russ

     

     

    Monday, November 23, 2015 7:00 AM

All replies

  • Hello,

    Have you checked Private Networks (Client & Server) capability in Package.appxmanifest  in you UWP app solution 

    Monday, November 23, 2015 8:07 AM
  • Hello Rusty,

    >> I can navigate to the service api http://localhost:52143/api/app/test in Chrome and IE  (and see the results of a test method) , but strangely not in Edge. which tells me it can't reach this page.

    1. Have you checked the Edge about:flags and see if the AllowLocalHostLoopBack is enabled?

    2. Could you please check this similar discussion about accessing localhost in edge browser?

    https://social.technet.microsoft.com/Forums/en-US/0face535-3c7a-4658-be34-6c376322ca34/microsoft-edge-cant-open-local-domains

    3. I tested this on my side and it works

    	args.setPromise(WinJS.UI.processAll().then(function () {
    				WinJS.xhr({
    					url: "http://localhost:8080/api/values",
    					responseType: "json"
    				}).then(function (data) {
    					console.log(data.response);
    				})
    			}));

    With Regards,

    Krunal Parekh


    Thanks MSDN Community Support Please remember to Mark as Answer the responses that resolved your issue. It is a common way to recognize those who have helped you, and makes it easier for other visitors to find the resolution later.

    • Proposed as answer by Krunal Parekh Tuesday, December 1, 2015 2:29 AM
    Tuesday, November 24, 2015 3:39 AM
  • I've got the exact same problem. All our winRT and UWP Apps are no longer able to communicate with local webservices (for e.g. for testing reasons with something like xampp or uwamp). There's seems to be a possible solution with using fiddler (http://www.telerik.com/fiddler), but thats a) needless overcomplicated and b) it should be unnecessary.

    Checklist:

    • Edge loopback checked in about:flags
      Yes
    • Private Network, Internet etc. in App Manifest enabled
      Yes
    • Debug Properties for Solution set to "allow network loopback"?
      Yes

    Still no joy... nothing at all. Since I it's obvious UWP (and WinRT on Win10)is using Edge internally it will fail, because Edge itself is failing to. Chrome, Firefox and IE as mentioned by Russty is working fine.


    • Edited by SW_Andy Thursday, November 26, 2015 12:12 PM
    Thursday, November 26, 2015 12:11 PM
  • Yes I empathize - I've tried exactly the same things and still can't get it working.

    Any further suggestions anyone?

    Thanks,
    Russ

    Friday, November 27, 2015 6:00 AM
  • Hello Rusty,

    This seems more like environment issue rather than developing issue. because I tried the same and it is working fine on my end. I suspect that something in edge settings (or perhaps firewall? how about checking it fiddle to see what server response you get when called from fiddler?).

    With Regards,

    Krunal Parekh


    Thanks MSDN Community Support Please remember to Mark as Answer the responses that resolved your issue. It is a common way to recognize those who have helped you, and makes it easier for other visitors to find the resolution later.

    Sunday, November 29, 2015 2:37 AM
  • Thanks Krunal.

    Yes, I had it working on another laptop just prior to Win 10 RTM, but I've scoured the web and can't find anything I haven't tried.   If I just point my MVC project at Microsoft Edge using IIS Express it can't reach the page.   All the other browsers work fine, so I'm assuming (and it's only a guess) that this is the reason my UWP app can't also see localhost.

    When I run my app, Fiddler isn't showing an attempt to connect.   I've set the AppContainer loopback exemption and even completely disabled the firewall.   If I select Microsoft Edge and press play in my MVC project, again nothing appears in Fiddler.   If I switch to Chrome or IE, I can see the requests fine in Fiddler and the default page appears in the browsers.

     I have no clue what to try next. 

    Thanks
    Russ

    Sunday, November 29, 2015 3:29 PM
  • hello Russty,

    >>If I just point my MVC project at Microsoft Edge using IIS Express it can't reach the page.

    I didn't use IIS Express but I published it to local IIS and it was working. could you try that?

    You can publish your site to your local iis so you don't need to debug your api and run it on IIS Express. Doing this it works for me.

    With Regards,

    Krunal Parekh


    Thanks MSDN Community Support Please remember to Mark as Answer the responses that resolved your issue. It is a common way to recognize those who have helped you, and makes it easier for other visitors to find the resolution later.

    • Proposed as answer by Krunal Parekh Tuesday, December 1, 2015 2:29 AM
    Monday, November 30, 2015 1:57 AM
  • Thanks for this Krunal.

    I'm not seeing how installing IIS on my laptop will resolve the fact my UWP can't see localhost.   I've had this working previously without IIS so it's obviously some setting/config I'm missing.

    My goal here isn't to get Edge to see localhost, just my app - though I'm guessing the two might be linked.

    Tuesday, December 1, 2015 5:29 AM
  • Hello Russty,

    >> My goal here isn't to get Edge to see localhost, just my app - though I'm guessing the two might be linked.

    Yes perhaps. but as it is working on my side I suspect that it is because of difference IIS Express and Local IIS. Did you try using local IIS?

    With Regards,

    Krunal Parekh


    Thanks MSDN Community Support Please remember to Mark as Answer the responses that resolved your issue. It is a common way to recognize those who have helped you, and makes it easier for other visitors to find the resolution later.

    Wednesday, December 2, 2015 2:11 AM