Universal firewall settings for different application versions?

[1984]

Hi,

I am releasing different versions of my application fairly often and because the version number is the part of the actual exe filename all the different versions trigger the firewall dialog when the give version is executed the first time. This is quite annoying and confuses the operators.

The filenames I use are like:

- myAppV1.0.0.exe

- myAppV1.0.1.exe

- myAppV1.2.1.exe

etc etc

Is there a turn off the firewall to every application which has a filename like "myAppV*.exe"? Or maybe any other way to get rid of that popup? (Using the same filename for different versions, or completly turning of the firewall is not an option)

thanks!

[SanthoshJoel]

Hi ,

     The simple way is just enable signature to your exe files on build specification so that windows firewall wont block it or ask permission.

or one more thing you can try is right click on your exe in Pc you are going to run go to properties and set full control in permission

Kudos are Welcome 😄 

[mikeporter · Accepted solution]

...and stop including the version number in the executable name. The application builder will track version numbers and even autoincrement them for you, while signatures allow Windows to keep track of different versions of the same application.

Doing it the way you are is inherently unreliable, error-prone and insecure.

Mike...

[1984]

How is it unreliable, error-prone or insecure?

[Sam_Sharp]

You've said that using the same filename isn't an option - I'm curious as to why that is the case? I can't think of any other application I have on my machine that has the version number as part of the name? I'm sure you have your reasons, so I'm genuinely curious.

I do, however, agree with Mike that I would probably recommend removing the version number from the executable:

- If the two applications sit side-by-side, there's a chance that the operator could launch the wrong version. Also, if you update a dependency (e.g. an external DLL), those would get overwritten anyway to the latest version. I wouldn't want to give an operator the choice of which software to use.

- You have to update/keep track of any shortcuts - if the user of the software makes their own shortcuts, they'll all become invalid on a software update.

- The executable version number is visible from the file properties (or from the hover tooltip in windows explorer). Its also a good idea to have it visible inside the software itself.

- Having a different name means the properties set on the file are lost when updating (e.g. windows firewall exceptions, run as administrator settings etc.), as you have found out

- From a developer/configuration management point of view, I think it's best to keep track of built executables in your builds folder by building them into version folders (e.g. MyApp v1.0.0.1\App.exe), rather than renaming the executable itself.

[1984]

The reason I have is that I'd like to be super conservative. I include the version number to both the folder and the filename, so if somehow a file escapes from its original folder it can be detected easily. Also I mentioned that changing this policy is not an option because I have found at the ni forums in so many cases that if you are not super specific with your question then answers get sidetracked really fast not solving your problem. So basically I wanted to narrow down the possible solutions.

After thinking about this problem I must say no reason to be super conservative. Including the version number to the folder structure is enough and then I just need to add only one firewall entry.

So in this specific case narrowing down the options was not the best idea.

[1984]

oops... wait a second. If I use the version number in the folder name then I still have the same issue. Firewall allows me to define specific paths to an exe which I would like to go thru the firewall, but if the folder name changes the firewall dialog will pop up everytime I compile a new version, no matter that the exe name is still the same.

Leaving out the version number from the foldername is really something I can't do. Different stations use different version of the application and all them are stored in a network drive.

Am I missing something?

[Sam_Sharp]

---

@1984 wrote:

Am I missing something?

---

Use an installer/deployment so that the application gets installed to the same directory/path when you upgrade it? You keep the installers (in version number folders) on your network drive and then install the appropriate one on each station. (and actually, I would suggest this is more conservative as the operator cannot upgrade without admin rights and has no access to older/newer versions of the executables?)

Oh...the other (more obvious...given your limitations) option would be that rather than specifying the executable as an exception in the firewall, find out what ports/protocols the application uses and make exception rules to allow them instead.

[1984]

The first would be benefitial but impossible because of certain IT policies.

The second would be great but it seems my IT knowledge is not enough to do that. When I launch the exe I see two firewall entries. The difference between the two that one enables TCP the other UDP connections for the given application. I have changed these entries to "all programs meet the specific conditions" from a specific exe, but this doesnt solve the issue I have. My app for sure communicates via TCP and FTP, but I dont know how should I configure this in the firewall settings besides what I have tried already.

I ran out of ideas, it seems I need to live with the firewall dialogs 😞

[Sam_Sharp]

Yeah, the option that appears that basically whitelists an application in the firewall so it can communicate on any port/protocol that it wants. The other approach is to allow certain ports/protocols through the firewall, regardless of the application that making the connection. To do this, you'd need to know which ports on TCP or UDP that your application uses - e.g. the TCP ports/ranges you're using, some things like FTP tend to be on a 'standard' port (e.g. FTP is port 21) and there is a list of 'standard' ports that NI uses for it's own services.

For example, here's the page where you can configure these settings in Windows Firewall:

Some of these settings might be restricted by your IT policy - but I feel this is more of an IT question than a LabVIEW question. I hope this helps and good luck!