views:

56

answers:

1

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

I have been successfully utilitising 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.

Does anyone know if this problem has been addressed?

A: 

Hi, Is there some setting in Windows Firewall that restricts this? We have thousands of customers all over the world, and haven't had any problems with it letting the deployment through. Is your deployment signed with a trusted certificate -- not the one from Visual Studio, but one from Verisign or some other trusted certificate authority? If you are working in an enterprise, the IT support guys can generate a certificate that chains back to them as a trusted publisher.

Is the enterprise hosting the ClickOnce application? Is the domain not trusted? I know we have had a few cases where our customers inside firewalled companies have had to set up our company domain as a trusted domain in Internet Explorer.

RobinDotNet
Deployment is working well, the problems only happen once the application starts. My application is using .NET remoting over HTTP and trying to accept incoming messages. It turns out that I'm not the first to try this and have firewall issues: http://social.msdn.microsoft.com/Forums/en-US/netfxremoting/thread/c8aae289-35e3-40cd-a020-7c8a89df007a. My current plan is to convert the callback part (and just the callback part) to WCF using netTcp binding.
Andrew Shepherd
I'll be interested to see how that works for you. We were looking at hosting a WCF service over TCP in a Worker Role running on Microsoft Azure, and calling it from our ClickOnce app, but we were worried out customers' firewalls would catch the TCP (to a particular port) and stop it. We're going to use HTTPS instead.
RobinDotNet
Switching the callback part to WCF worked. The clients and server are all within the same intranet, so my issue was only with the firewall on each client machine. Your deployment might have complications with the enterprise's external firewall, but that will happen whether you use ClickOnce or not. Does it use callbacks? If you don't have callbacks, then wsHttpBinding would be the most fire-wall friendly binding.
Andrew Shepherd