Expose ActivationData to launched .NET app

[NikolaMilosavljevic]

Fixes: #236 and #113

Description

This work enables .NET app, deployed using ClickOnce, to use the activation arguments.

This solves two scenarios:

1. app was activated using appref-ms shortcut and custom arguments were provided on the command-line
2. app was activated using a file with custom extension, registered using file association feature

Launcher reads the AppDomain.CurrentDomain.SetupInformation.ActivationArguments.ActivationData array and sets some environment variables if array is non-empty.

New environment variables

ClickOnce_ActivationData_Count

If this variable exists, the value is the count of elements in ActivationData string array.

ClickOnce_ActivationData_<n>

For each element in array, new environment variable gets added, with a zero-based index, i.e.:
ClickOnce_ActivationData_0
ClickOnce_ActivationData_1
...

Note that the scenarios being fixed always use the 0-index element, so the variable will always be ClickOnce_ActivationData_0, but the code is flexible and is able to pass all activation data to .NET app.

Usage scenario

Developer can read these environment variables to discover ActivationData content, using something like the following:

string value = Environment.GetEnvironmentVariable("ClickOnce_ActivationData_0");

Previously, for .NET FX apps, this would have been achieved using the following code:

string value = AppDomain.CurrentDomain?.SetupInformation?.ActivationArguments?.ActivationData?[0];

[joeloff]

Wouldn't Length be better here since Count is a computed result?

[NikolaMilosavljevic]

They should have equivalent value, in this case, so we could use either. I used count to match the env. var. name I'm using - ClickOnce_ActivationData_Count. It does require Linq and is slightly slower - but this array usually has zero or only 1 element.

[NikolaMilosavljevic]

Pushed the change - removing Linq dependency and using Length.

[sujitnayak]

So these environment variables will get inherited all the way through to the application process where the app can choose to read these variables?

[NikolaMilosavljevic]

Yes, that is correct. It is the model we've been using for passing data from Launcher (which is a ClickOnce-activated app and has access to additional data like ApplicationDeployment.CurrentDeployment) to the .NET (Core) app being launched.

[mgnsm]

@NikolaMilosavljevic How do I actually start a .NET app with custom arguments using the appref-ms shortcut after this proposed fix?

Targeting .NET 8, I can still start the app like this from the command-line:

App.appref-ms

But when passing a custom parameter it just silently fails:

App.appref-ms myarg

[nas-rda]

@NikolaMilosavljevic How do I actually start a .NET app with custom arguments using the appref-ms shortcut after this proposed fix?

Targeting .NET 8, I can still start the app like this from the command-line:

App.appref-ms

But when passing a custom parameter it just silently fails:

App.appref-ms myarg

@mgnsm I ran into this today. What I found is you can pass a URL as the parameter but you cannot pass individual arguments. Example:
App.appref-ms "https://a.com?test123=test456"
You can then access the URL via ApplicationDeployment.CurrentDeployment.ActivationUri.

---

Why it fails when passing normal arguments? You can setup a string registry key under HKCU\SOFTWARE\Classes\Software\Microsoft\Windows\CurrentVersion\Deployment called LauncherLogFilePath (hint: see https://github.com/dotnet/deployment-tools/blob/main/src/clickonce/launcher/Constants.cs). Then you can try launching with normal arguments and in the log file you will see:
*** Error: Invalid URI: The format of the URI could not be determined.

But if you pass a URL as the argument then the error doesn't occur.