ClickOnce applications and Windows Firewall

Question

It appears to me that ClickOnce applications will not work smoothly with Windows Firewall.

I have been successfully using ClickOnce deployments for two years. This has hit a stumbling block now the enterprise has upgraded to Windows 7. Each user's configuration has changed:

• Windows Firewall is enabled on each user's machines
• Users do not have administrator privileges on their machines.

Here's how ClickOnce works: Every time a ClickOnce application is updated, the executable file is copied to a new directory. This directory has a machine generated name. (For example it might deploy to "C:\Users\andrew.shepherd\AppData\Local\Apps\2.0\GTTG5EJB.AVG\jc69hir.e45\watershedclient.exe").

Windows Firewall, by default, blocks applications from accepting incoming calls. However, when the application first attempts this, Windows Firewall pops up a dialog that allows an administrator to make an exception for the application, giving it the privileges it needs.

The problem is, Windows Firewall stores the application record as the full file path. Each time a ClickOnce application is updated, it installs to a different directory. Therefore, Windows Firewall sees it as a whole new application. An administrator now has to configure the firewall for this update for every machine that it's updated on. This effectively defeats the whole reason why we use ClickOnce technology.

This was flagged as an issue in 2005, and Microsoft acknowledged the problem and admitted there was no solution.

Has this problem been addressed?

Scorpaenoid

I'm currently reviewing ClickOnce capabilities and this seems like a major issue weighing against me recommending it, since our application communicates with a HTTP server using SOAP/XML Service calls on port 80. – Exact

Also see Clickonce applications being allowed through firewall and ClickOnce Installation / Firewall Settings – Exact

@locster I'm not sure what circularly linking unanswered questions on the same topic is doing to help users find an answer to this question. – Byars

@redcalx: incidentally, hardwiring port 80 is a REALLY bad idea ... – Unintelligible

Answer 1

The problem is, Windows Firewall stores the application record as the full file path. Each time a ClickOnce application is updated, it installs to a different directory. Therefore, Windows Firewall sees it as a whole new application.

One approach here is to edit the rule name so that it specifies the name of the EXE only and not the full path. E.g. my locally deployed 'Hello World' application was installed at this path by ClickOnce:

C:\Users\jdoe\AppData\Local\Apps\2.0\BNYJV8NM.JT8\DGEMYJV2.ZN7\hell..tion_32be098505965508_0001.0000_ad51d60d7593998b\HelloWorld.exe

And a firewall rule that applies to only "HelloWorld.exe" can be used. However that creates a security hole in that the rule applies to any application with that name. We can refine the rule a little further by specifying some of the path:

%LOCALAPPDATA%\Apps\2.0\BNYJV8NM.JT8\DGEMYJV2.ZN7\*\HelloWorld.exe

Note that I also used an environment variable, which apparently is expanded for the purposes of testing the firewall rule.

Exact

Good idea, you could take a step further an automate this by programmatically checking/adding rules on application start up too, here is how: codeproject.com/Articles/14906/… – Cheryllches

I tried this for both the .exe without any path and with the correct path below %LOCALAPPDATA%. Both did not work (Windows 8.1). – Fonz

@HennoVermeulen Does it work if you disable the firewall completely? i.e. is it definitely the firewall that is the problem? – Exact

@Exact unfortunately this is not possible due to group policy, but I'm almost sure it does. I have put this rule in the group policy and I can see the correct rule is in the firewall. Still Windows pops up a firewall warning on my application. I need administrator rights to accept this and then the application works. If I press cancel the application is blocked. Unfortunately this is the only thing normal users are allowed to do. – Fonz

By the way this is not a ClickOnce application but a Java application with a native .exe launcher, but the idea is the same! I wish to install per user and not per client so that I can replicate the same auto-update idea that ClickOnce/Java Web Start (which I'm replacing) uses. This bypasses problems with the application still being in use by another user when it needs to be updated and also doesn't require to push the application to online clients which is harder than pulling it when started. I will probably work around this issue by using Java directly instead of through the native launcher. – Fonz

Sounds like you need a Windows Firewall expert and/or some kind of debug tool for tracing what firewall rules are being invoked. Maybe the group policy causing your extra rule to be ignored(?) – Exact

Microsoft: "We currently only support rules created using the full path to the application(s)." (in the note at the end of the section) – Surprisal