Skip to main content

Windows 8 application returns “Unable to connect to the remote server” when sending requests to an internal test server

After weeks of testing, we were finally ready to release a first version of our Windows 8 app to our key user. So I created a package and copied all the files on an USB stick to ‘side load’ the application on his machine.  After running the Powershell installation script, installing the developer certificate,  the moment was finally there. The application started and the main hub was shown.

However the moment, the user started to click around and HttpWebRequests were send out to our backend services, the application failed with the following error message:

Unable to connect to the remote server

System.Exception {System.Net.WebException}

An attempt was made to access a socket in a way forbidden by its access permissions

We were clueless why it failed. We tested the application for weeks without any issue. The only difference is that we hosted the backend API somewhere else. Could this cause the issue? We were using a DNS that was mapped differently depending if you connect internally or externally.

The first thing we tried to do, was to add Fiddler into the mix to see what was going on. This made the experience even stranger because suddenly all web calls started to succeed?!            

In a desperate attempt, I opened up the Windows 8 manifest and added the capability for Private Networks:

PrivateNetworksWin8

The Private Networks (Client & Server capability provides inbound and outbound access to home and work networks through the firewall. This capability is typically used for games that communicate across the local area network (LAN), and for apps that share data across a variety of local devices. If your app specifies musicLibrary, picturesLibrary, or videosLibrary, you don't need to use this capability to access the corresponding library in a Home Group. Inbound access to critical ports is always blocked. The capability is written in the AppxManifest.xml file as the following code shows:

Afterwards the application worked fine.

Anyone with more insight who can explain why this solved the issue? I’m guessing this is required because the DNS is resolved to an internal network address…

Remark: To validate if my guess was correct, I removed the capability again and this time connected from outside our company network. I started the application and everything was working as expected.

Popular posts from this blog

Podman– Command execution failed with exit code 125

After updating WSL on one of the developer machines, Podman failed to work. When we took a look through Podman Desktop, we noticed that Podman had stopped running and returned the following error message: Error: Command execution failed with exit code 125 Here are the steps we tried to fix the issue: We started by running podman info to get some extra details on what could be wrong: >podman info OS: windows/amd64 provider: wsl version: 5.3.1 Cannot connect to Podman. Please verify your connection to the Linux system using `podman system connection list`, or try `podman machine init` and `podman machine start` to manage a new Linux VM Error: unable to connect to Podman socket: failed to connect: dial tcp 127.0.0.1:2655: connectex: No connection could be made because the target machine actively refused it. That makes sense as the podman VM was not running. Let’s check the VM: >podman machine list NAME         ...

Azure DevOps/ GitHub emoji

I’m really bad at remembering emoji’s. So here is cheat sheet with all emoji’s that can be used in tools that support the github emoji markdown markup: All credits go to rcaviers who created this list.

VS Code Planning mode

After the introduction of Plan mode in Visual Studio , it now also found its way into VS Code. Planning mode, or as I like to call it 'Hannibal mode', extends GitHub Copilot's Agent Mode capabilities to handle larger, multi-step coding tasks with a structured approach. Instead of jumping straight into code generation, Planning mode creates a detailed execution plan. If you want more details, have a look at my previous post . Putting plan mode into action VS Code takes a different approach compared to Visual Studio when using plan mode. Instead of a configuration setting that you can activate but have limited control over, planning is available as a separate chat mode/agent: I like this approach better than how Visual Studio does it as you have explicit control when plan mode is activated. Instead of immediately diving into execution, the plan agent creates a plan and asks some follow up questions: You can further edit the plan by clicking on ‘Open in Editor’: ...