Click-Once Apps

What are the challenges of repackaging a ClickOnce application?

ClickOnce shares some similarities with MSIX – the main one being that they are per-user applications.

Per-user applications are kind of difficult to repackage. In general, IT Pros are used to building MSI and EXE packages to be installed per-machine. That means that most of the applications that we find on the market today require administrative rights to be installed. So, most vendors prefer the per-machine method of deploying applications.

This comes as no surprise, since the per-machine approach makes it much easier to manage your applications in the infrastructure.

One mistake that we see happening very frequently is for IT Pros to convert ClickOnce applications (per-user) to per-machine applications without considering all the issues that could occur during the execution of that particular application.

Never change the installation type of an application unless you fully understand how it works.

Usually, you want an application to save some settings or running information in files. For per-user applications, most vendors consider placing those setting files near the executable.

The problem comes if you try to convert the application to per-machine. Why? Because users in an infrastructure will probably not have the necessary rights to write in a per-machine location.

Some might say that you can always give additional permissions when you build your package, but that is a security point that needs a deeper discussion.
For now, let’s consider that additional permissions are not allowed on per-machine installations. Check out the MSI Permissions Guide: Three Ways to Add Rights With your Installer

How to Repackage ClickOnce Applications?

As you will see, repackaging a ClickOnce application is not very different from capturing other types of installers.

1. Open Advanced Repackager and go through the standard process of repackaging an application. A full tutorial can be found here.
2. Once you repackaged your application, your AIP(Advanced Installer Project) should contain all the files in a per-user location:

Best practices for Per-user applications

There are two main golden rules for per-user applications:

1. Make sure the self-healing mechanism is working properly at all times
2. Don’t change an application installation behavior

Following the second rule, while using ClickOnce applications, we must place files exactly where the original installer places them. In our case, all the files are copied directly into %appdata%.

But, how do you address this situation when you have a multiple-user setup on a single machine?

When you deploy per-user applications within any infrastructure, it takes time before it reaches the user. It also uses up additional bandwidth for the actual installer to be downloaded into the user cache again. So, what do we do in this case?

We need to place all the files in a per-machine folder (e.g. C:\Program Files\My App) and copy them for each user when he/she logs into the machine with the Active Setup mechanism.

The challenge here is making sure we also follow golden rule number one: making sure that the self-healing mechanism works.

If you want to read more about it, we already touched on this subject in this article.

When it comes to MSI’s, if the MSI is not present in the original install location and files need to be copied, then the self-healing process fails. That is one of the reasons we are not leaving the files as they were captured (in %appdata) and we are moving them in a per-machine location (C:\Program FIles\My App) and then copying them using a Custom Action.

One other aspect we need to consider is the shortcut. In our example, the shortcut is placed under each user Start Menu folder, located in:

C:\Users\YOUR USER\AppData\Roaming\Microsoft\Windows\Start Menu

To make it easier, we will place the shortcut on a per-user machine, but the target of the shortcut will point to %appdata%, meaning it will open the executable from each user location.

How to adjust the package?

Knowing what we know now, we can adjust the package.

1. Let's first move all the files into the Application folder:

2. Now that the files are placed on a per-machine location (C:\Program Files (x86)\Caphyon\ClickOnce App Repackaged), it’s time to add the Custom Action that will copy the files during the Active Setup. To do this, navigate to the Custom Actions Page and add a new “Launch attached file” action. For this, we are using this simple VBScript:

Option Explicit
Dim fso, objWShell, appData
Set fso = CreateObject("Scripting.FileSystemObject")
Set objWShell = WScript.CreateObject("WScript.Shell")
appData = objWShell.expandEnvironmentStrings("%APPDATA%")
fso.CopyFile "C:\Program Files (x86)\Caphyon\ClickOnce App Repackaged\*.*", appData + "\"

3. Once you have selected the VBScript, configure the rest of the settings, as shown below:

4. The next step is to implement a simple Active Setup into the MSI. In Advanced Installer,navigate to the Product Details page and click on the Active Setup tab.

5. There, click on New and only change the Stub Path from /fou to /fus and click OK.

6. Now, the package is installing on a per-machine location and we have an Active Setup which will trigger the Custom Action that is introduced to copy the files to a per-user location once a user logs in.

7. The final step is to adjust the shortcut to point to the correct executable location. This is a two step process.

7.1 First, navigate to the Properties page and create a new property that looks something like this:

7.2 Once we have the property created, navigate to the Shortcuts Page and create a new “External File” shortcut. The most important part here is to define the Shortcut Targetdir to point to:

[SHORPATH]\Sample.exe

SHORPATH is the property we previously created, replace it with the property name you have created in your project.

8. At the end, the shortcut should look something like this:

As you can see, the shortcut is placed on a per-machine location, but the target of the shortcut will point at the end to %appdata%\Sample.exe: