Passing installation parameters to a Windows application with MSIX and App Installer

Published Sep 28 2020 05:14 AM 5,067 Views
Microsoft

As a Windows developer, a very common requirement you might be asked to implement is to track information about the installation process. For example, let's say that you have started a special campaign to advertise your application and you want to understand how many people are installing it because they have clicked one of the promotional banners. Or, in an enterprise environment, you may want to know which is the department of the employee who is installing the application, so that you can apply a different configuration. A very common solution for this requirement is to leverage a web installation and to use query string parameters, appended to the installation URI, which must be collected by the Windows application the first time it's launched. For example, your installation URL can be something like http://www.foo.com/setup?source=campaign. Then your application, when it's launched for the first time, must able to retrieve the value of the query string parameter called source and use it as it's needed (for example, by sending this information to an analytic platform like App Center).

 

As you might know if you follow this blog, MSIX is the most modern technology to deploy Windows application and, through a feature called App Installer, you can support web installations with automatic updates. As such, is there a way to pass activation parameters to the application from the installer URL with MSIX and App Installer? The answer is yes!

 

Let's see how we can do that.

Adding protocol support

The way MSIX supports this feature is by leveraging protocol support. Your app must register a custom protocol, which will be used to launch the application after it has been installed from your website using App Installer. Then, your application will retrieve all the information about the activation through the startup arguments, like in a regular protocol activation scenario. For example, let's say you register a protocol called contoso-expenses:. This means that, when someone invokes a URL like contoso-expenses:?source=campaign, your application will receive as activation arguments the value source=campaign. This is exactly what App Installer is going to do the first time it launches your MSIX packaged app after the installation has been completed.

 

Adding protocol support in a MSIX packaged application is quite easy, thanks to the application manifest. In my scenario, I have a WPF application built with .NET Core, which is packaged as MSIX using the Windows Application Packaging Project. As such, all I have to do is to double click on the Package.appxmanifest file in the Windows Application Packaging Project and move to the Declarations section. In the Available declarations dropdown menu choose Protocol and fill the Name field with the name of the custom protocol you want to register (in my scenario, it's contoso-expenses:(

 

protocol.png

 

Listening for activation arguments

The next step is to make our application aware of activation arguments. The way you implement this support changes based on the development framework you have chosen. In this sample we're going to see how to do it in a WPF application. Activation arguments can be retrieved in the App.xaml.cs file, by overriding the OnStartup() method, which is invoked every time the application starts:

 

public partial class App : Application
{
    protected override void OnStartup(StartupEventArgs e)
    {
        string path = $"{Environment.GetFolderPath(Environment.SpecialFolder.Desktop)}//AppInstaller.txt";

        if (e.Args.Length > 0)
        {
            System.IO.File.WriteAllText(path, e.Args[0]);
        }
        else
        {
            System.IO.File.WriteAllText(path, "No arguments available");
        }
    }
}

The OnStartup() method gets, as input parameter, an object of type StartupEventArgs, which includes any activation parameter that has been passed to the application. They are stored inside an array called Args. In case of protocol activation, there will be only one item in the array with the full URL that has been used to activate the application. The previous sample code simply writes this information, for logging purposes, in a text file stored on the desktop of the current user.

Test the custom protocol implementation

Before putting all together for App Installer, we have a way to quickly test if the implementation we have done works as expected. Since the App Installer implementation of this feature is based on the standard approach for managing custom protocols, we can test this scenario right away, without needing to package everything together and upload it on our website. We just need to invoke our custom protocol from any Windows shell.

 

As first step, right click on the Windows Application Packaging Project and choose Deploy, in order to install the application on the system and register the custom protocol. Now open the Run panel in Windows 10 (or just press Start+R on your keyboard) and type a URI which uses your custom protocol. For example, in my scenario I can use something like:

 

contoso-expenses:?source=campaign

If you have implemented everything correctly, your application will start. The OnStartup() event will have been triggered as well, so if I check my desktop I will find a file called AppInstaller.txt with the following content:

 

contoso-expenses:?source=campaign

As you can see, everything is working as expected. The application has launched and, in the activation arguments, I've been able to get the full URL that it has been used to invoke the custom protocol.

If you encounter issues during the OnStartup() event, the Windows Application Packaging Project gives you an option to easily test this scenario. Right click on it, move to the Debug section and enable the option Do not launch, but debug my code when it starts.

 

Debug.png

Now you can press F5 to launch the debugger, but the application won't be actively launched. The debugger will be on hold, waiting for the application to be activated. Thanks to this feature, you can easily test different activation paths. In our scenario, you can just add a breakpoint inside the OnStartup() method and then, from the Run panel, invoke the custom URL. The application will start and the debugger will wake up, triggering the breakpoint and giving you the option to debug your code.

 

Now that we have a working implementation in our application, let's see how we can configure App Installer to leverage it.

Setting up App Installer

When it comes to the App Installer configuration, you don't have to do anything special to support this scenario. The App Installer file you're using today to deploy your MSIX application works fine. However, you will have to customize the URL that is used to trigger the installation. If you're generating the App Installer file as part of the publishing process in Visual Studio, you will end up with a web page similar to the following one:

 

ContosoExpenses.png

The Get the app button will trigger the installation of the MSIX package by leveraging the special ms-appinstaller protocol and it will look like this:

 

ms-appinstaller:?source=https://contosoexpensescd.z19.web.core.windows.net/ContosoExpenses.Package.appinstaller

The trick here is to add a special parameter to this URI, called activationUri. As such, open the web page with your favorite text editor and change the URL to look like this (or copy it directly in your web browser, if you just want to do a test):

 

ms-appinstaller:?source=https://contosoexpensescd.z19.web.core.windows.net/ContosoExpenses.Package.appinstaller&activationUri=contoso-expenses:?source=campaign

As you can see, I have added at the end an activationUri parameter with, as value, the same exact custom URL I have tested before, based on the contoso-expenses protocol registered in the application. When you do this, Windows will automatically launch this URL at the end of the MSIX deployment process, instead of simply launching your application.

The installation process won't look different. When you click on Get the app button with the new custom URL, the user will continue to see the traditional MSIX deployment experience:

 

InstallApp.png

The only difference is that, as you can notice, the option Launch when ready is hidden. The application will be forcefully launched at the end of the process with the custom URL we have specified, otherwise we won't be able to get the activation parameters. Once the deployment is complete, Windows will silently invoke the custom URL we have passed to the activationUri parameter, which in our case is contoso-expenses:?source=campaign. As a consequence, the experience will be like the one we have tested before when we have locally invoked the custom protocol: the application will be launched and, on the desktop, we'll find a file called AppInstaller.txt with the full URL that has been used for triggering the execution.

 

Unfortunately, Visual Studio doesn't have a way to customize the web page that is generated to add this custom App Installer URI. However, in a real scenario, you won't probably use that page, but you will have the App Installer link embedded in a button or banner of your existing website.

 

Working with the activation parameters

An easier way to work with the activation parameters is to leverage the HttpUtility class which is included in the System.Web namespace. Thanks to this class, you can manipulate the query string parameters coming from the Uri in an easier way:

 

protected override void OnStartup(StartupEventArgs e)
{
    string path = $"{Environment.GetFolderPath(Environment.SpecialFolder.Desktop)}//AppInstaller.txt";

    if (e.Args.Length > 0)
    {
        UriBuilder builder = new UriBuilder(e.Args[0]);
        var result = HttpUtility.ParseQueryString(builder.Query);
        var value = result["source"];

        System.IO.File.WriteAllText(path, $"Source: {value}");
    }
    else
    {
        System.IO.File.WriteAllText(path, "No arguments available");
    }
}

As first step, we use the UriBuilder class to create a Uri object out of the activation parameter we have received inside the first position of the e.Args array. This way, we can easily access only to the query string parameters (without the whole contoso-expenses protocol) by using the Query property. By using the ParseQueryString() method and passing the query string we get in return a dictionary, which makes easy to access to all the various parameters. The previous sample shows how easily we can retrieve the value of the source parameter from the query string. Thanks to this approach, we can avoid to use string manipulation to retrieve the same information, which is more error prone.

 

What about a Universal Windows Platform application?

What if, instead of a .NET application like in this example, I have a UWP app? From a custom protocol registration perspective, the approach is exactly the same. The deployment technology for UWP is MSIX, so also in this case we have a manifest file where we can register our protocol. From a code perspective, instead, UWP offers a dedicated method for custom activation paths, called OnActivated(), which must be declared in the App.xaml.cs file. This is an example implementation:

 

protected override void OnActivated(IActivatedEventArgs args)
{
    if (args is ProtocolActivatedEventArgs eventArgs)
    {
        UriBuilder builder = new UriBuilder(eventArgs.Uri);
        var result = HttpUtility.ParseQueryString(builder.Query);
        var value = result["source"];
    }
}

 

As you can see, the code is very similar to the WPF implementation. The only difference is that the OnActivated event can be triggered by multiple patterns and, as such, first we need to make sure that this is indeed a protocol activation, by checking the real type of the IActivataedEventArgs parameter. In case of protocol activation, it will be ProtocolActivatedEventArgs, which gives us access to the to the Uri property we need to retrieve the activation URL.

 

Wrapping up

This implementation is based on the standard custom protocol support offered by Windows, so it's very easy to implement. Every development platform support a way to get activation parameters when the application starts, so you just need to write some code to manage the desired scenario.

 

You can find the full sample used in this blog post on GitHub.

 

Happy coding!

 

References

12 Comments
Valued Contributor

Hi,

 

Thank you for sharing, but it required technical knowledge and is not so easy.

I request work on simplify the process and make it more user friendly.

Microsoft

Hello @Reza_Ameri-Archived thanks for the comment! Can you share a more detailed feedback on how you think this feature should be simplified?

 

I think the current implementation isn't very complex since it's based on already existing implementations (like protocol association), but maybe I'm seeing it with the wrong angle.

 

Thanks! 

Valued Contributor

Hi @Matteo Pagani 

Indeed the process is simple and your description is very clear.

But it could be much simpler, for example there could be some graphical interface in Project properties and from there user select these options and configure them, instead of add some codes and so on. Then user just save it and when run it do as you said.

For more complex scenario, we will relay on coding like what you mentioned, but for general usage, I believe having one special UI for this would be interesting.

Microsoft

Thanks for the details @Reza_Ameri-Archived ! I think having a settings in the Visual Studio UI to customize the App Installer URL to add the activation parameter is a very good idea, I'll pass the feedback on.

However, unfortunately, a bit of coding will always be required to implement this scenario, because the way your app behaves when it's activated through the installation is totally custom and depends by your goals and requirements. As such, a "turn on" settings wouldn't really work here, since Visual Studio can't know which parameters you want to pass and how you want to handle them.

 

Thanks for the feedback!

Valued Contributor

Welcome @Matteo Pagani 

I am sharing this because I had experience like we want to add new feature or implement new functionality and if it is as easy as make some changes in UI, we will go ahead with that, but in case it required coding and compile, normally we leave it for future and it keep delays until we find some free time to implement it.

Regular Visitor

Is this really the end result? 

 

This only works for first launch of the application. That is why you attach a so convoluted real world example of someone wanting to register the department where it is installed. In a real world you'd want to apply arguments at later application startups.

 

Further, as far as I can tell your implementation only takes a single pair of key/value parameters. Trying 

ms-appinstaller:?source=https://...appinstaller&activationUri=contoso-expenses:?source=campaign&target=foo

raise an invalid URI exception. Surely you can do better.

 

Cheers,

 

/Martin 

 

 

 

Microsoft

Hello @Apskalle ,

thanks for your feedback. One of the key goals of this blog is to create a community for Windows developers where we can discuss technical topics and help each others.  It's totally fine if you don't like my post or if you think it can be improved, but I kindly ask you to be more respectful of the work of others next time.

Having said that, this article is specific of passing activation parameters from the installer, which is a common requirement when, for example, you're running a marketing campaign and you want to track how many people installed the application as a consequence. However, the same protocol implementation works just fine on every launch. You just have to invoke the application using the protocol (for example, by pressing Win-R and typing the full URL, or by invoking the URL from another app or website) and the query string parameters will be passed to the app. Or is your expectation that the parameters passed at the installation should always be passed down to the application? Unfortunately, this would break how protocol activation works (what if you want to activate the app with different parameters?). If you need to handle this scenario, a better approach would be to intercept the query string parameters at the first launch after the installation and then store them somewhere (a database, a file, etc.)

 

Regarding the problem with multiple query strings, thanks for the feedback. I'll test the scenario and, if it's indeed a limitation, I'll forward it to the App Installer team.

 
Regular Visitor

Oh, sorry, came out harsher then intended, my apologies.

 

Just thinking out loud, wouldnt the appinstaller file be a place for parameters

 

 

<?xml version="1.0" encoding="utf-8"?>
<AppInstaller
	<MainBundle/>
	<UpdateSettings>
		<OnLaunch
			HoursBetweenUpdateChecks="0"
			ShowPrompt="true"
			UpdateBlocksActivation="true">
			<Parameters>
				<Parameter Key=foo Value=fooval/>
				<Parameter Key=bar Value=barval/>
			<Parameters>
		</OnLaunch>
		<ForceUpdateFromAnyVersion>true</ForceUpdateFromAnyVersion>
	</UpdateSettings>
</AppInstaller>

 

As for the point of launches subsequent to install, yes it works if you continue to launch it via the appinstaller. But (the normal?) way would be via the installed app (eg Start menu) and there the arguments are no longer forwarded as far as I can see.

 

/Martin

 

 

Microsoft

No harm done @Apskalle, no worries :smiling_face_with_smiling_eyes: 

The idea of adding the parameters in the App Installer file is interesting and a good one indeed. I'll pass the feedback to the App Installer team.

 

Regarding keep passing the parameters via the Start menu, can you share a bit more about the scenario you would try to accomplish? Which is the reason why it would important to you to have the activation parameters coming from App Installer always passed to the app when it's launched via Start menu?

 

Thanks!

 

 
Regular Visitor

Hi Matteo,


My need is pretty standard I think. The app is a LOB application (net5/WPF/client/server) installed at different customer sites.
Via command line params you can among atther things control authentication method, server- and database names and alternate path for storing user configuration file.

I dont plan to use the (appinstaller) html file but intend to just place the .appinstaller file on a share letting users do initial install from there, msix appbundle files residing on another remote server.
Subsequent starts are made from users desktop.

 

Cheers,

 

/Martin

New Contributor

Thanks for this!  We have an appx package (not msix due to older versions of Win10) that contains 2 exe's in the manifest.  We manually call for updates when one is detected by the app (also to support older win10) and need to know which exe to restart after the update is complete.  Since we already have aliases registered, adding the query string above was trivial.

 

One thing to note, in our case we do not actually need to pass any arguments other then the alias but you still need to include the ending semicolon.  For example, this did NOT work:

ms-appinstaller:?source=\\some\file\path\someapp.appinstaller&activationUri=myapp2alias

 

but this DID work (note the trailing ":"):

ms-appinstaller:?source=\\some\file\path\someapp.appinstaller&activationUri=myapp2alias:

 

 

Ernie

Frequent Visitor

I have a question about the above. It says: "The only difference is that, as you can notice, the option Launch when ready is hidden".

 

However, I've followed the steps above, and everything else works well, we get protocol-based activation etc. HOWEVER, it does not hide the "Launch when ready" button. The result is if the end-user unclicks this option during install we never get to know about the the activationUri.

 

Is there maybe a step missing from the post above that describes how to hide that button?

 

[EDIT] Argh. This has to do with launching the .appinstaller from a batch file. (Have to ^ the &). Once I fixed that it works.

 

However, I second the request that it would be great having a way to specify something like <parameters> directly in an .appinstaller - that way we don't need to ship a batch file just to launch the .appinstaller with an activationUri. Though in fairness we need both mechanisms for different scenarios.

%3CLINGO-SUB%20id%3D%22lingo-sub-1721161%22%20slang%3D%22en-US%22%3ERe%3A%20Passing%20installation%20parameters%20to%20a%20Windows%20application%20with%20MSIX%20and%20App%20Installer%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1721161%22%20slang%3D%22en-US%22%3E%3CP%3EHi%2C%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EThank%20you%20for%20sharing%2C%20but%20it%20required%20technical%20knowledge%20and%20is%20not%20so%20easy.%3C%2FP%3E%3CP%3EI%20request%20work%20on%20simplify%20the%20process%20and%20make%20it%20more%20user%20friendly.%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-1721181%22%20slang%3D%22en-US%22%3ERe%3A%20Passing%20installation%20parameters%20to%20a%20Windows%20application%20with%20MSIX%20and%20App%20Installer%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1721181%22%20slang%3D%22en-US%22%3E%3CP%3EHello%20%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F13441%22%20target%3D%22_blank%22%3E%40Reza%20Ameri%3C%2FA%3E%26nbsp%3Bthanks%20for%20the%20comment!%20Can%20you%20share%20a%20more%20detailed%20feedback%20on%20how%20you%20think%20this%20feature%20should%20be%20simplified%3F%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EI%20think%20the%20current%20implementation%20isn't%20very%20complex%20since%20it's%20based%20on%20already%20existing%20implementations%20(like%20protocol%20association)%2C%20but%20maybe%20I'm%20seeing%20it%20with%20the%20wrong%20angle.%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EThanks!%26nbsp%3B%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-1725113%22%20slang%3D%22en-US%22%3ERe%3A%20Passing%20installation%20parameters%20to%20a%20Windows%20application%20with%20MSIX%20and%20App%20Installer%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1725113%22%20slang%3D%22en-US%22%3E%3CP%3EHi%26nbsp%3B%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F44595%22%20target%3D%22_blank%22%3E%40Matteo%20Pagani%3C%2FA%3E%26nbsp%3B%3C%2FP%3E%3CP%3EIndeed%20the%20process%20is%20simple%20and%20your%20description%20is%20very%20clear.%3C%2FP%3E%3CP%3EBut%20it%20could%20be%20much%20simpler%2C%20for%20example%20there%20could%20be%20some%20graphical%20interface%20in%20Project%20properties%20and%20from%20there%20user%20select%20these%20options%20and%20configure%20them%2C%20instead%20of%20add%20some%20codes%20and%20so%20on.%20Then%20user%20just%20save%20it%20and%20when%20run%20it%20do%20as%20you%20said.%3C%2FP%3E%3CP%3EFor%20more%20complex%20scenario%2C%20we%20will%20relay%20on%20coding%20like%20what%20you%20mentioned%2C%20but%20for%20general%20usage%2C%20I%20believe%20having%20one%20special%20UI%20for%20this%20would%20be%20interesting.%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-1719829%22%20slang%3D%22en-US%22%3EPassing%20installation%20parameters%20to%20a%20Windows%20application%20with%20MSIX%20and%20App%20Installer%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1719829%22%20slang%3D%22en-US%22%3E%3CP%3EAs%20a%20Windows%20developer%2C%20a%20very%20common%20requirement%20you%20might%20be%20asked%20to%20implement%20is%20to%20track%20information%20about%20the%20installation%20process.%20For%20example%2C%20let's%20say%20that%20you%20have%20started%20a%20special%20campaign%20to%20advertise%20your%20application%20and%20you%20want%20to%20understand%20how%20many%20people%20are%20installing%20it%20because%20they%20have%20clicked%20one%20of%20the%20promotional%20banners.%20Or%2C%20in%20an%20enterprise%20environment%2C%20you%20may%20want%20to%20know%20which%20is%20the%20department%20of%20the%20employee%20who%20is%20installing%20the%20application%2C%20so%20that%20you%20can%20apply%20a%20different%20configuration.%20A%20very%20common%20solution%20for%20this%20requirement%20is%20to%20leverage%20a%20web%20installation%20and%20to%20use%20query%20string%20parameters%2C%20appended%20to%20the%20installation%20URI%2C%20which%20must%20be%20collected%20by%20the%20Windows%20application%20the%20first%20time%20it's%20launched.%20For%20example%2C%20your%20installation%20URL%20can%20be%20something%20like%3CSPAN%3E%26nbsp%3B%3C%2FSPAN%3E%3CSTRONG%3E%3CA%20href%3D%22http%3A%2F%2Fwww.foo.com%2Fsetup%3Fsource%3Dcampaign%22%20target%3D%22_blank%22%20rel%3D%22noopener%20nofollow%20noreferrer%22%3Ehttp%3A%2F%2Fwww.foo.com%2Fsetup%3Fsource%3Dcampaign%3C%2FA%3E%3C%2FSTRONG%3E.%20Then%20your%20application%2C%20when%20it's%20launched%20for%20the%20first%20time%2C%20must%20able%20to%20retrieve%20the%20value%20of%20the%20query%20string%20parameter%20called%3CSPAN%3E%26nbsp%3B%3C%2FSPAN%3E%3CSTRONG%3Esource%3C%2FSTRONG%3E%3CSPAN%3E%26nbsp%3B%3C%2FSPAN%3Eand%20use%20it%20as%20it's%20needed%20(for%20example%2C%20by%20sending%20this%20information%20to%20an%20analytic%20platform%20like%3CSPAN%3E%26nbsp%3B%3C%2FSPAN%3E%3CA%20href%3D%22https%3A%2F%2Fvisualstudio.microsoft.com%2Fapp-center%2F%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noreferrer%22%3EApp%20Center%3C%2FA%3E).%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EAs%20you%20might%20know%20if%20you%20follow%20this%20blog%2C%20MSIX%20is%20the%20most%20modern%20technology%20to%20deploy%20Windows%20application%20and%2C%20through%20a%20feature%20called%3CSPAN%3E%26nbsp%3B%3C%2FSPAN%3E%3CA%20href%3D%22https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fwindows%2Fmsix%2Fapp-installer%2Fapp-installer-root%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noreferrer%22%3EApp%20Installer%3C%2FA%3E%2C%20you%20can%20support%20web%20installations%20with%20automatic%20updates.%20As%20such%2C%20is%20there%20a%20way%20to%20pass%20activation%20parameters%20to%20the%20application%20from%20the%20installer%20URL%20with%20MSIX%20and%20App%20Installer%3F%20The%20answer%20is%20yes!%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3ELet's%20see%20how%20we%20can%20do%20that.%3C%2FP%3E%0A%3CH3%20id%3D%22adding-protocol-support%22%20id%3D%22toc-hId-1254523886%22%20id%3D%22toc-hId-1254523886%22%20id%3D%22toc-hId-1254523886%22%20id%3D%22toc-hId-1254523886%22%3EAdding%20protocol%20support%3C%2FH3%3E%0A%3CP%3EThe%20way%20MSIX%20supports%20this%20feature%20is%20by%20leveraging%3CSPAN%3E%26nbsp%3B%3C%2FSPAN%3E%3CA%20href%3D%22https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fwindows%2Fapps%2Fdesktop%2Fmodernize%2Fdesktop-to-uwp-extensions%23protocol%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noreferrer%22%3Eprotocol%20support%3C%2FA%3E.%20Your%20app%20must%20register%20a%20custom%20protocol%2C%20which%20will%20be%20used%20to%20launch%20the%20application%20after%20it%20has%20been%20installed%20from%20your%20website%20using%20App%20Installer.%20Then%2C%20your%20application%20will%20retrieve%20all%20the%20information%20about%20the%20activation%20through%20the%20startup%20arguments%2C%20like%20in%20a%20regular%20protocol%20activation%20scenario.%20For%20example%2C%20let's%20say%20you%20register%20a%20protocol%20called%3CSPAN%3E%26nbsp%3B%3C%2FSPAN%3E%3CCODE%3Econtoso-expenses%3A%3C%2FCODE%3E.%20This%20means%20that%2C%20when%20someone%20invokes%20a%20URL%20like%3CSPAN%3E%26nbsp%3B%3C%2FSPAN%3E%3CCODE%3Econtoso-expenses%3A%3Fsource%3Dcampaign%3C%2FCODE%3E%2C%20your%20application%20will%20receive%20as%20activation%20arguments%20the%20value%3CSPAN%3E%26nbsp%3B%3C%2FSPAN%3E%3CCODE%3Esource%3Dcampaign%3C%2FCODE%3E.%20This%20is%20exactly%20what%20App%20Installer%20is%20going%20to%20do%20the%20first%20time%20it%20launches%20your%20MSIX%20packaged%20app%20after%20the%20installation%20has%20been%20completed.%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EAdding%20protocol%20support%20in%20a%20MSIX%20packaged%20application%20is%20quite%20easy%2C%20thanks%20to%20the%20application%20manifest.%20In%20my%20scenario%2C%20I%20have%20a%20WPF%20application%20built%20with%20.NET%20Core%2C%20which%20is%20packaged%20as%20MSIX%20using%20the%3CSPAN%3E%26nbsp%3B%3C%2FSPAN%3E%3CA%20href%3D%22https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fwindows%2Fmsix%2Fdesktop%2Fdesktop-to-uwp-packaging-dot-net%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noreferrer%22%3EWindows%20Application%20Packaging%20Project%3C%2FA%3E.%20As%20such%2C%20all%20I%20have%20to%20do%20is%20to%20double%20click%20on%20the%3CSPAN%3E%26nbsp%3B%3C%2FSPAN%3E%3CSTRONG%3EPackage.appxmanifest%3C%2FSTRONG%3E%3CSPAN%3E%26nbsp%3B%3C%2FSPAN%3Efile%20in%20the%20Windows%20Application%20Packaging%20Project%20and%20move%20to%20the%3CSPAN%3E%26nbsp%3B%3C%2FSPAN%3E%3CSTRONG%3EDeclarations%3C%2FSTRONG%3E%3CSPAN%3E%26nbsp%3B%3C%2FSPAN%3Esection.%20In%20the%3CSPAN%3E%26nbsp%3B%3C%2FSPAN%3E%3CSTRONG%3EAvailable%20declarations%3C%2FSTRONG%3E%3CSPAN%3E%26nbsp%3B%3C%2FSPAN%3Edropdown%20menu%20choose%3CSPAN%3E%26nbsp%3B%3C%2FSPAN%3E%3CSTRONG%3EProtocol%3C%2FSTRONG%3E%3CSPAN%3E%26nbsp%3B%3C%2FSPAN%3Eand%20fill%20the%3CSPAN%3E%26nbsp%3B%3C%2FSPAN%3E%3CSTRONG%3EName%3C%2FSTRONG%3E%3CSPAN%3E%26nbsp%3B%3C%2FSPAN%3Efield%20with%20the%20name%20of%20the%20custom%20protocol%20you%20want%20to%20register%20(in%20my%20scenario%2C%20it's%3CSPAN%3E%26nbsp%3B%3C%2FSPAN%3E%3CCODE%3Econtoso-expenses%3C%2FCODE%3E%3A(%3C%2Fimg%3E%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3E%3CSPAN%20class%3D%22lia-inline-image-display-wrapper%20lia-image-align-inline%22%20image-alt%3D%22protocol.png%22%20style%3D%22width%3A%20920px%3B%22%3E%3CIMG%20src%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fimage%2Fserverpage%2Fimage-id%2F222530i287F362B59A2986B%2Fimage-size%2Flarge%3Fv%3D1.0%26amp%3Bpx%3D999%22%20title%3D%22protocol.png%22%20alt%3D%22protocol.png%22%20%2F%3E%3C%2FSPAN%3E%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CH3%20id%3D%22listening-for-activation-arguments%22%20id%3D%22toc-hId--552930577%22%20id%3D%22toc-hId--552930577%22%20id%3D%22toc-hId--552930577%22%20id%3D%22toc-hId--552930577%22%3EListening%20for%20activation%20arguments%3C%2FH3%3E%0A%3CP%3EThe%20next%20step%20is%20to%20make%20our%20application%20aware%20of%20activation%20arguments.%20The%20way%20you%20implement%20this%20support%20changes%20based%20on%20the%20development%20framework%20you%20have%20chosen.%20In%20this%20sample%20we're%20going%20to%20see%20how%20to%20do%20it%20in%20a%20WPF%20application.%20Activation%20arguments%20can%20be%20retrieved%20in%20the%3CSPAN%3E%26nbsp%3B%3C%2FSPAN%3E%3CSTRONG%3EApp.xaml.cs%3C%2FSTRONG%3E%3CSPAN%3E%26nbsp%3B%3C%2FSPAN%3Efile%2C%20by%20overriding%20the%3CSPAN%3E%26nbsp%3B%3C%2FSPAN%3E%3CCODE%3EOnStartup()%3C%2FCODE%3E%3CSPAN%3E%26nbsp%3B%3C%2FSPAN%3Emethod%2C%20which%20is%20invoked%20every%20time%20the%20application%20starts%3A%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CPRE%3E%3CCODE%20id%3D%22pragma-line-24%22%20class%3D%22language-csharp%20hljs%22%3E%3CSPAN%20class%3D%22hljs-keyword%22%3Epublic%3C%2FSPAN%3E%20%3CSPAN%20class%3D%22hljs-keyword%22%3Epartial%3C%2FSPAN%3E%20%3CSPAN%20class%3D%22hljs-keyword%22%3Eclass%3C%2FSPAN%3E%20%3CSPAN%20class%3D%22hljs-title%22%3EApp%3C%2FSPAN%3E%20%3A%20%3CSPAN%20class%3D%22hljs-title%22%3EApplication%3C%2FSPAN%3E%0A%7B%0A%20%20%20%20%3CSPAN%20class%3D%22hljs-function%22%3E%3CSPAN%20class%3D%22hljs-keyword%22%3Eprotected%3C%2FSPAN%3E%20%3CSPAN%20class%3D%22hljs-keyword%22%3Eoverride%3C%2FSPAN%3E%20%3CSPAN%20class%3D%22hljs-keyword%22%3Evoid%3C%2FSPAN%3E%20%3CSPAN%20class%3D%22hljs-title%22%3EOnStartup%3C%2FSPAN%3E(%3CSPAN%20class%3D%22hljs-params%22%3EStartupEventArgs%20e%3C%2FSPAN%3E)%3C%2FSPAN%3E%0A%20%20%20%20%7B%0A%20%20%20%20%20%20%20%20%3CSPAN%20class%3D%22hljs-keyword%22%3Estring%3C%2FSPAN%3E%20path%20%3D%20%3CSPAN%20class%3D%22hljs-string%22%3E%24%22%3CSPAN%20class%3D%22hljs-subst%22%3E%7BEnvironment.GetFolderPath(Environment.SpecialFolder.Desktop)%7D%3C%2FSPAN%3E%2F%2FAppInstaller.txt%22%3C%2FSPAN%3E%3B%0A%0A%20%20%20%20%20%20%20%20%3CSPAN%20class%3D%22hljs-keyword%22%3Eif%3C%2FSPAN%3E%20(e.Args.Length%20%26gt%3B%20%3CSPAN%20class%3D%22hljs-number%22%3E0%3C%2FSPAN%3E)%0A%20%20%20%20%20%20%20%20%7B%0A%20%20%20%20%20%20%20%20%20%20%20%20System.IO.File.WriteAllText(path%2C%20e.Args%5B%3CSPAN%20class%3D%22hljs-number%22%3E0%3C%2FSPAN%3E%5D)%3B%0A%20%20%20%20%20%20%20%20%7D%0A%20%20%20%20%20%20%20%20%3CSPAN%20class%3D%22hljs-keyword%22%3Eelse%3C%2FSPAN%3E%0A%20%20%20%20%20%20%20%20%7B%0A%20%20%20%20%20%20%20%20%20%20%20%20System.IO.File.WriteAllText(path%2C%20%3CSPAN%20class%3D%22hljs-string%22%3E%22No%20arguments%20available%22%3C%2FSPAN%3E)%3B%0A%20%20%20%20%20%20%20%20%7D%0A%20%20%20%20%7D%0A%7D%0A%3C%2FCODE%3E%3C%2FPRE%3E%0A%3CP%3EThe%3CSPAN%3E%26nbsp%3B%3C%2FSPAN%3E%3CCODE%3EOnStartup()%3C%2FCODE%3E%3CSPAN%3E%26nbsp%3B%3C%2FSPAN%3Emethod%20gets%2C%20as%20input%20parameter%2C%20an%20object%20of%20type%3CSPAN%3E%26nbsp%3B%3C%2FSPAN%3E%3CCODE%3EStartupEventArgs%3C%2FCODE%3E%2C%20which%20includes%20any%20activation%20parameter%20that%20has%20been%20passed%20to%20the%20application.%20They%20are%20stored%20inside%20an%20array%20called%3CSPAN%3E%26nbsp%3B%3C%2FSPAN%3E%3CCODE%3EArgs%3C%2FCODE%3E.%20In%20case%20of%20protocol%20activation%2C%20there%20will%20be%20only%20one%20item%20in%20the%20array%20with%20the%20full%20URL%20that%20has%20been%20used%20to%20activate%20the%20application.%20The%20previous%20sample%20code%20simply%20writes%20this%20information%2C%20for%20logging%20purposes%2C%20in%20a%20text%20file%20stored%20on%20the%20desktop%20of%20the%20current%20user.%3C%2FP%3E%0A%3CH3%20id%3D%22test-the-custom-protocol-implementation%22%20id%3D%22toc-hId-1934582256%22%20id%3D%22toc-hId-1934582256%22%20id%3D%22toc-hId-1934582256%22%20id%3D%22toc-hId-1934582256%22%3ETest%20the%20custom%20protocol%20implementation%3C%2FH3%3E%0A%3CP%3EBefore%20putting%20all%20together%20for%20App%20Installer%2C%20we%20have%20a%20way%20to%20quickly%20test%20if%20the%20implementation%20we%20have%20done%20works%20as%20expected.%20Since%20the%20App%20Installer%20implementation%20of%20this%20feature%20is%20based%20on%20the%20standard%20approach%20for%20managing%20custom%20protocols%2C%20we%20can%20test%20this%20scenario%20right%20away%2C%20without%20needing%20to%20package%20everything%20together%20and%20upload%20it%20on%20our%20website.%20We%20just%20need%20to%20invoke%20our%20custom%20protocol%20from%20any%20Windows%20shell.%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EAs%20first%20step%2C%20right%20click%20on%20the%20Windows%20Application%20Packaging%20Project%20and%20choose%3CSPAN%3E%26nbsp%3B%3C%2FSPAN%3E%3CSTRONG%3EDeploy%3C%2FSTRONG%3E%2C%20in%20order%20to%20install%20the%20application%20on%20the%20system%20and%20register%20the%20custom%20protocol.%20Now%20open%20the%20Run%20panel%20in%20Windows%2010%20(or%20just%20press%20Start%2BR%20on%20your%20keyboard)%20and%20type%20a%20URI%20which%20uses%20your%20custom%20protocol.%20For%20example%2C%20in%20my%20scenario%20I%20can%20use%20something%20like%3A%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CPRE%3E%3CCODE%20id%3D%22pragma-line-52%22%20class%3D%22language-plaintext%20hljs%22%3Econtoso-expenses%3A%3Fsource%3Dcampaign%0A%3C%2FCODE%3E%3C%2FPRE%3E%0A%3CP%3EIf%20you%20have%20implemented%20everything%20correctly%2C%20your%20application%20will%20start.%20The%3CSPAN%3E%26nbsp%3B%3C%2FSPAN%3E%3CCODE%3EOnStartup()%3C%2FCODE%3E%3CSPAN%3E%26nbsp%3B%3C%2FSPAN%3Eevent%20will%20have%20been%20triggered%20as%20well%2C%20so%20if%20I%20check%20my%20desktop%20I%20will%20find%20a%20file%20called%3CSPAN%3E%26nbsp%3B%3C%2FSPAN%3E%3CSTRONG%3EAppInstaller.txt%3C%2FSTRONG%3E%3CSPAN%3E%26nbsp%3B%3C%2FSPAN%3Ewith%20the%20following%20content%3A%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CPRE%3E%3CCODE%20id%3D%22pragma-line-58%22%20class%3D%22language-plaintext%20hljs%22%3Econtoso-expenses%3A%3Fsource%3Dcampaign%0A%3C%2FCODE%3E%3C%2FPRE%3E%0A%3CP%3EAs%20you%20can%20see%2C%20everything%20is%20working%20as%20expected.%20The%20application%20has%20launched%20and%2C%20in%20the%20activation%20arguments%2C%20I've%20been%20able%20to%20get%20the%20full%20URL%20that%20it%20has%20been%20used%20to%20invoke%20the%20custom%20protocol.%3C%2FP%3E%0A%3CP%3EIf%20you%20encounter%20issues%20during%20the%3CSPAN%3E%26nbsp%3B%3C%2FSPAN%3E%3CCODE%3EOnStartup()%3C%2FCODE%3E%3CSPAN%3E%26nbsp%3B%3C%2FSPAN%3Eevent%2C%20the%20Windows%20Application%20Packaging%20Project%20gives%20you%20an%20option%20to%20easily%20test%20this%20scenario.%20Right%20click%20on%20it%2C%20move%20to%20the%3CSPAN%3E%26nbsp%3B%3C%2FSPAN%3E%3CSTRONG%3EDebug%3C%2FSTRONG%3E%3CSPAN%3E%26nbsp%3B%3C%2FSPAN%3Esection%20and%20enable%20the%20option%3CSPAN%3E%26nbsp%3B%3C%2FSPAN%3E%3CSTRONG%3EDo%20not%20launch%2C%20but%20debug%20my%20code%20when%20it%20starts%3C%2FSTRONG%3E.%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3E%3CSPAN%20class%3D%22lia-inline-image-display-wrapper%20lia-image-align-inline%22%20image-alt%3D%22Debug.png%22%20style%3D%22width%3A%20669px%3B%22%3E%3CIMG%20src%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fimage%2Fserverpage%2Fimage-id%2F222531i8B2C02960DFCFD35%2Fimage-size%2Flarge%3Fv%3D1.0%26amp%3Bpx%3D999%22%20title%3D%22Debug.png%22%20alt%3D%22Debug.png%22%20%2F%3E%3C%2FSPAN%3E%3C%2FP%3E%0A%3CP%3ENow%20you%20can%20press%20F5%20to%20launch%20the%20debugger%2C%20but%20the%20application%20won't%20be%20actively%20launched.%20The%20debugger%20will%20be%20on%20hold%2C%20waiting%20for%20the%20application%20to%20be%20activated.%20Thanks%20to%20this%20feature%2C%20you%20can%20easily%20test%20different%20activation%20paths.%20In%20our%20scenario%2C%20you%20can%20just%20add%20a%20breakpoint%20inside%20the%3CSPAN%3E%26nbsp%3B%3C%2FSPAN%3E%3CCODE%3EOnStartup()%3C%2FCODE%3E%3CSPAN%3E%26nbsp%3B%3C%2FSPAN%3Emethod%20and%20then%2C%20from%20the%20Run%20panel%2C%20invoke%20the%20custom%20URL.%20The%20application%20will%20start%20and%20the%20debugger%20will%20wake%20up%2C%20triggering%20the%20breakpoint%20and%20giving%20you%20the%20option%20to%20debug%20your%20code.%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3ENow%20that%20we%20have%20a%20working%20implementation%20in%20our%20application%2C%20let's%20see%20how%20we%20can%20configure%20App%20Installer%20to%20leverage%20it.%3C%2FP%3E%0A%3CH3%20id%3D%22setting-up-app-installer%22%20id%3D%22toc-hId-127127793%22%20id%3D%22toc-hId-127127793%22%20id%3D%22toc-hId-127127793%22%20id%3D%22toc-hId-127127793%22%3ESetting%20up%20App%20Installer%3C%2FH3%3E%0A%3CP%3EWhen%20it%20comes%20to%20the%20App%20Installer%20configuration%2C%20you%20don't%20have%20to%20do%20anything%20special%20to%20support%20this%20scenario.%20The%20App%20Installer%20file%20you're%20using%20today%20to%20deploy%20your%20MSIX%20application%20works%20fine.%20However%2C%20you%20will%20have%20to%20customize%20the%20URL%20that%20is%20used%20to%20trigger%20the%20installation.%20If%20you're%20generating%20the%20App%20Installer%20file%20as%20part%20of%20the%20publishing%20process%20in%20Visual%20Studio%2C%20you%20will%20end%20up%20with%20a%20web%20page%20similar%20to%20the%20following%20one%3A%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3E%3CSPAN%20class%3D%22lia-inline-image-display-wrapper%20lia-image-align-inline%22%20image-alt%3D%22ContosoExpenses.png%22%20style%3D%22width%3A%20703px%3B%22%3E%3CIMG%20src%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fimage%2Fserverpage%2Fimage-id%2F222532i19F2759A60D168DE%2Fimage-size%2Flarge%3Fv%3D1.0%26amp%3Bpx%3D999%22%20title%3D%22ContosoExpenses.png%22%20alt%3D%22ContosoExpenses.png%22%20%2F%3E%3C%2FSPAN%3E%3C%2FP%3E%0A%3CP%3EThe%3CSPAN%3E%26nbsp%3B%3C%2FSPAN%3E%3CSTRONG%3EGet%20the%20app%3C%2FSTRONG%3E%3CSPAN%3E%26nbsp%3B%3C%2FSPAN%3Ebutton%20will%20trigger%20the%20installation%20of%20the%20MSIX%20package%20by%20leveraging%20the%20special%3CSPAN%3E%26nbsp%3B%3C%2FSPAN%3E%3CCODE%3Ems-appinstaller%3C%2FCODE%3E%3CSPAN%3E%26nbsp%3B%3C%2FSPAN%3Eprotocol%20and%20it%20will%20look%20like%20this%3A%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CPRE%3E%3CCODE%20id%3D%22pragma-line-80%22%20class%3D%22language-plaintext%20hljs%22%3Ems-appinstaller%3A%3Fsource%3Dhttps%3A%2F%2Fcontosoexpensescd.z19.web.core.windows.net%2FContosoExpenses.Package.appinstaller%0A%3C%2FCODE%3E%3C%2FPRE%3E%0A%3CP%3EThe%20trick%20here%20is%20to%20add%20a%20special%20parameter%20to%20this%20URI%2C%20called%3CSPAN%3E%26nbsp%3B%3C%2FSPAN%3E%3CCODE%3EactivationUri%3C%2FCODE%3E.%20As%20such%2C%20open%20the%20web%20page%20with%20your%20favorite%20text%20editor%20and%20change%20the%20URL%20to%20look%20like%20this%20(or%20copy%20it%20directly%20in%20your%20web%20browser%2C%20if%20you%20just%20want%20to%20do%20a%20test)%3A%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CPRE%3E%3CCODE%20id%3D%22pragma-line-86%22%20class%3D%22language-plaintext%20hljs%22%3Ems-appinstaller%3A%3Fsource%3Dhttps%3A%2F%2Fcontosoexpensescd.z19.web.core.windows.net%2FContosoExpenses.Package.appinstaller%26amp%3BactivationUri%3Dcontoso-expenses%3A%3Fsource%3Dcampaign%0A%3C%2FCODE%3E%3C%2FPRE%3E%0A%3CP%3EAs%20you%20can%20see%2C%20I%20have%20added%20at%20the%20end%20an%3CSPAN%3E%26nbsp%3B%3C%2FSPAN%3E%3CCODE%3EactivationUri%3C%2FCODE%3E%3CSPAN%3E%26nbsp%3B%3C%2FSPAN%3Eparameter%20with%2C%20as%20value%2C%20the%20same%20exact%20custom%20URL%20I%20have%20tested%20before%2C%20based%20on%20the%3CSPAN%3E%26nbsp%3B%3C%2FSPAN%3E%3CCODE%3Econtoso-expenses%3C%2FCODE%3E%3CSPAN%3E%26nbsp%3B%3C%2FSPAN%3Eprotocol%20registered%20in%20the%20application.%20When%20you%20do%20this%2C%20Windows%20will%20automatically%20launch%20this%20URL%20at%20the%20end%20of%20the%20MSIX%20deployment%20process%2C%20instead%20of%20simply%20launching%20your%20application.%3C%2FP%3E%0A%3CP%3EThe%20installation%20process%20won't%20look%20different.%20When%20you%20click%20on%3CSPAN%3E%26nbsp%3B%3C%2FSPAN%3E%3CSTRONG%3EGet%20the%20app%3C%2FSTRONG%3E%3CSPAN%3E%26nbsp%3B%3C%2FSPAN%3Ebutton%20with%20the%20new%20custom%20URL%2C%20the%20user%20will%20continue%20to%20see%20the%20traditional%20MSIX%20deployment%20experience%3A%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3E%3CSPAN%20class%3D%22lia-inline-image-display-wrapper%20lia-image-align-inline%22%20image-alt%3D%22InstallApp.png%22%20style%3D%22width%3A%20650px%3B%22%3E%3CIMG%20src%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fimage%2Fserverpage%2Fimage-id%2F222533iB0B09CC6F6112D35%2Fimage-size%2Flarge%3Fv%3D1.0%26amp%3Bpx%3D999%22%20title%3D%22InstallApp.png%22%20alt%3D%22InstallApp.png%22%20%2F%3E%3C%2FSPAN%3E%3C%2FP%3E%0A%3CP%3EThe%20only%20difference%20is%20that%2C%20as%20you%20can%20notice%2C%20the%20option%3CSPAN%3E%26nbsp%3B%3C%2FSPAN%3E%3CSTRONG%3ELaunch%20when%20ready%3C%2FSTRONG%3E%3CSPAN%3E%26nbsp%3B%3C%2FSPAN%3Eis%20hidden.%20The%20application%20will%20be%20forcefully%20launched%20at%20the%20end%20of%20the%20process%20with%20the%20custom%20URL%20we%20have%20specified%2C%20otherwise%20we%20won't%20be%20able%20to%20get%20the%20activation%20parameters.%20Once%20the%20deployment%20is%20complete%2C%20Windows%20will%20silently%20invoke%20the%20custom%20URL%20we%20have%20passed%20to%20the%3CSPAN%3E%26nbsp%3B%3C%2FSPAN%3E%3CCODE%3EactivationUri%3C%2FCODE%3E%3CSPAN%3E%26nbsp%3B%3C%2FSPAN%3Eparameter%2C%20which%20in%20our%20case%20is%3CSPAN%3E%26nbsp%3B%3C%2FSPAN%3E%3CCODE%3Econtoso-expenses%3A%3Fsource%3Dcampaign%3C%2FCODE%3E.%20As%20a%20consequence%2C%20the%20experience%20will%20be%20like%20the%20one%20we%20have%20tested%20before%20when%20we%20have%20locally%20invoked%20the%20custom%20protocol%3A%20the%20application%20will%20be%20launched%20and%2C%20on%20the%20desktop%2C%20we'll%20find%20a%20file%20called%3CSPAN%3E%26nbsp%3B%3C%2FSPAN%3E%3CSTRONG%3EAppInstaller.txt%3C%2FSTRONG%3E%3CSPAN%3E%26nbsp%3B%3C%2FSPAN%3Ewith%20the%20full%20URL%20that%20has%20been%20used%20for%20triggering%20the%20execution.%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EUnfortunately%2C%20Visual%20Studio%20doesn't%20have%20a%20way%20to%20customize%20the%20web%20page%20that%20is%20generated%20to%20add%20this%20custom%20App%20Installer%20URI.%20However%2C%20in%20a%20real%20scenario%2C%20you%20won't%20probably%20use%20that%20page%2C%20but%20you%20will%20have%20the%20App%20Installer%20link%20embedded%20in%20a%20button%20or%20banner%20of%20your%20existing%20website.%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CH3%20id%3D%22working-with-the-activation-parameters%22%20id%3D%22toc-hId--1680326670%22%20id%3D%22toc-hId--1680326670%22%20id%3D%22toc-hId--1680326670%22%20id%3D%22toc-hId--1680326670%22%3EWorking%20with%20the%20activation%20parameters%3C%2FH3%3E%0A%3CP%3EAn%20easier%20way%20to%20work%20with%20the%20activation%20parameters%20is%20to%20leverage%20the%3CSPAN%3E%26nbsp%3B%3C%2FSPAN%3E%3CCODE%3EHttpUtility%3C%2FCODE%3E%3CSPAN%3E%26nbsp%3B%3C%2FSPAN%3Eclass%20which%20is%20included%20in%20the%3CSPAN%3E%26nbsp%3B%3C%2FSPAN%3E%3CCODE%3ESystem.Web%3C%2FCODE%3E%3CSPAN%3E%26nbsp%3B%3C%2FSPAN%3Enamespace.%20Thanks%20to%20this%20class%2C%20you%20can%20manipulate%20the%20query%20string%20parameters%20coming%20from%20the%20Uri%20in%20an%20easier%20way%3A%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CPRE%3E%3CCODE%20id%3D%22pragma-line-106%22%20class%3D%22language-csharp%20hljs%22%3E%3CSPAN%20class%3D%22hljs-function%22%3E%3CSPAN%20class%3D%22hljs-keyword%22%3Eprotected%3C%2FSPAN%3E%20%3CSPAN%20class%3D%22hljs-keyword%22%3Eoverride%3C%2FSPAN%3E%20%3CSPAN%20class%3D%22hljs-keyword%22%3Evoid%3C%2FSPAN%3E%20%3CSPAN%20class%3D%22hljs-title%22%3EOnStartup%3C%2FSPAN%3E(%3CSPAN%20class%3D%22hljs-params%22%3EStartupEventArgs%20e%3C%2FSPAN%3E)%3C%2FSPAN%3E%0A%7B%0A%20%20%20%20%3CSPAN%20class%3D%22hljs-keyword%22%3Estring%3C%2FSPAN%3E%20path%20%3D%20%3CSPAN%20class%3D%22hljs-string%22%3E%24%22%3CSPAN%20class%3D%22hljs-subst%22%3E%7BEnvironment.GetFolderPath(Environment.SpecialFolder.Desktop)%7D%3C%2FSPAN%3E%2F%2FAppInstaller.txt%22%3C%2FSPAN%3E%3B%0A%0A%20%20%20%20%3CSPAN%20class%3D%22hljs-keyword%22%3Eif%3C%2FSPAN%3E%20(e.Args.Length%20%26gt%3B%20%3CSPAN%20class%3D%22hljs-number%22%3E0%3C%2FSPAN%3E)%0A%20%20%20%20%7B%0A%20%20%20%20%20%20%20%20UriBuilder%20builder%20%3D%20%3CSPAN%20class%3D%22hljs-keyword%22%3Enew%3C%2FSPAN%3E%20UriBuilder(e.Args%5B%3CSPAN%20class%3D%22hljs-number%22%3E0%3C%2FSPAN%3E%5D)%3B%0A%20%20%20%20%20%20%20%20%3CSPAN%20class%3D%22hljs-keyword%22%3Evar%3C%2FSPAN%3E%20result%20%3D%20HttpUtility.ParseQueryString(builder.Query)%3B%0A%20%20%20%20%20%20%20%20%3CSPAN%20class%3D%22hljs-keyword%22%3Evar%3C%2FSPAN%3E%20%3CSPAN%20class%3D%22hljs-keyword%22%3Evalue%3C%2FSPAN%3E%20%3D%20result%5B%3CSPAN%20class%3D%22hljs-string%22%3E%22source%22%3C%2FSPAN%3E%5D%3B%0A%0A%20%20%20%20%20%20%20%20System.IO.File.WriteAllText(path%2C%20%3CSPAN%20class%3D%22hljs-string%22%3E%24%22Source%3A%20%3CSPAN%20class%3D%22hljs-subst%22%3E%7B%3CSPAN%20class%3D%22hljs-keyword%22%3Evalue%3C%2FSPAN%3E%7D%3C%2FSPAN%3E%22%3C%2FSPAN%3E)%3B%0A%20%20%20%20%7D%0A%20%20%20%20%3CSPAN%20class%3D%22hljs-keyword%22%3Eelse%3C%2FSPAN%3E%0A%20%20%20%20%7B%0A%20%20%20%20%20%20%20%20System.IO.File.WriteAllText(path%2C%20%3CSPAN%20class%3D%22hljs-string%22%3E%22No%20arguments%20available%22%3C%2FSPAN%3E)%3B%0A%20%20%20%20%7D%0A%7D%0A%3C%2FCODE%3E%3C%2FPRE%3E%0A%3CP%3EAs%20first%20step%2C%20we%20use%20the%3CSPAN%3E%26nbsp%3B%3C%2FSPAN%3E%3CCODE%3EUriBuilder%3C%2FCODE%3E%3CSPAN%3E%26nbsp%3B%3C%2FSPAN%3Eclass%20to%20create%20a%20Uri%20object%20out%20of%20the%20activation%20parameter%20we%20have%20received%20inside%20the%20first%20position%20of%20the%3CSPAN%3E%26nbsp%3B%3C%2FSPAN%3E%3CCODE%3Ee.Args%3C%2FCODE%3E%3CSPAN%3E%26nbsp%3B%3C%2FSPAN%3Earray.%20This%20way%2C%20we%20can%20easily%20access%20only%20to%20the%20query%20string%20parameters%20(without%20the%20whole%3CSPAN%3E%26nbsp%3B%3C%2FSPAN%3E%3CCODE%3Econtoso-expenses%3C%2FCODE%3E%3CSPAN%3E%26nbsp%3B%3C%2FSPAN%3Eprotocol)%20by%20using%20the%3CSPAN%3E%26nbsp%3B%3C%2FSPAN%3E%3CCODE%3EQuery%3C%2FCODE%3E%3CSPAN%3E%26nbsp%3B%3C%2FSPAN%3Eproperty.%20By%20using%20the%3CSPAN%3E%26nbsp%3B%3C%2FSPAN%3E%3CCODE%3EParseQueryString()%3C%2FCODE%3E%3CSPAN%3E%26nbsp%3B%3C%2FSPAN%3Emethod%20and%20passing%20the%20query%20string%20we%20get%20in%20return%20a%20dictionary%2C%20which%20makes%20easy%20to%20access%20to%20all%20the%20various%20parameters.%20The%20previous%20sample%20shows%20how%20easily%20we%20can%20retrieve%20the%20value%20of%20the%3CSPAN%3E%26nbsp%3B%3C%2FSPAN%3E%3CCODE%3Esource%3C%2FCODE%3E%3CSPAN%3E%26nbsp%3B%3C%2FSPAN%3Eparameter%20from%20the%20query%20string.%20Thanks%20to%20this%20approach%2C%20we%20can%20avoid%20to%20use%20string%20manipulation%20to%20retrieve%20the%20same%20information%2C%20which%20is%20more%20error%20prone.%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CH3%20id%3D%22what-about-a-universal-windows-platform-application%22%20id%3D%22toc-hId-807186163%22%20id%3D%22toc-hId-807186163%22%20id%3D%22toc-hId-807186163%22%20id%3D%22toc-hId-807186163%22%3EWhat%20about%20a%20Universal%20Windows%20Platform%20application%3F%3C%2FH3%3E%0A%3CP%3EWhat%20if%2C%20instead%20of%20a%20.NET%20application%20like%20in%20this%20example%2C%20I%20have%20a%20UWP%20app%3F%20From%20a%20custom%20protocol%20registration%20perspective%2C%20the%20approach%20is%20exactly%20the%20same.%20The%20deployment%20technology%20for%20UWP%20is%20MSIX%2C%20so%20also%20in%20this%20case%20we%20have%20a%20manifest%20file%20where%20we%20can%20register%20our%20protocol.%20From%20a%20code%20perspective%2C%20instead%2C%20UWP%20offers%20a%20dedicated%20method%20for%20custom%20activation%20paths%2C%20called%3CSPAN%3E%26nbsp%3B%3C%2FSPAN%3E%3CCODE%3EOnActivated()%3C%2FCODE%3E%2C%20which%20must%20be%20declared%20in%20the%3CSPAN%3E%26nbsp%3B%3C%2FSPAN%3E%3CSTRONG%3EApp.xaml.cs%3C%2FSTRONG%3E%3CSPAN%3E%26nbsp%3B%3C%2FSPAN%3Efile.%20This%20is%20an%20example%20implementation%3A%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CPRE%3E%3CCODE%20id%3D%22pragma-line-133%22%20class%3D%22language-csharp%20hljs%22%3E%3CSPAN%20class%3D%22hljs-function%22%3E%3CSPAN%20class%3D%22hljs-keyword%22%3Eprotected%3C%2FSPAN%3E%20%3CSPAN%20class%3D%22hljs-keyword%22%3Eoverride%3C%2FSPAN%3E%20%3CSPAN%20class%3D%22hljs-keyword%22%3Evoid%3C%2FSPAN%3E%20%3CSPAN%20class%3D%22hljs-title%22%3EOnActivated%3C%2FSPAN%3E(%3CSPAN%20class%3D%22hljs-params%22%3EIActivatedEventArgs%20args%3C%2FSPAN%3E)%3C%2FSPAN%3E%0A%7B%0A%20%20%20%20%3CSPAN%20class%3D%22hljs-keyword%22%3Eif%3C%2FSPAN%3E%20(args%20%3CSPAN%20class%3D%22hljs-keyword%22%3Eis%3C%2FSPAN%3E%20ProtocolActivatedEventArgs%20eventArgs)%0A%20%20%20%20%7B%0A%20%20%20%20%20%20%20%20UriBuilder%20builder%20%3D%20%3CSPAN%20class%3D%22hljs-keyword%22%3Enew%3C%2FSPAN%3E%20UriBuilder(eventArgs.Uri)%3B%0A%20%20%20%20%20%20%20%20%3CSPAN%20class%3D%22hljs-keyword%22%3Evar%3C%2FSPAN%3E%20result%20%3D%20HttpUtility.ParseQueryString(builder.Query)%3B%0A%20%20%20%20%20%20%20%20%3CSPAN%20class%3D%22hljs-keyword%22%3Evar%3C%2FSPAN%3E%20%3CSPAN%20class%3D%22hljs-keyword%22%3Evalue%3C%2FSPAN%3E%20%3D%20result%5B%3CSPAN%20class%3D%22hljs-string%22%3E%22source%22%3C%2FSPAN%3E%5D%3B%0A%20%20%20%20%7D%0A%7D%0A%3C%2FCODE%3E%3C%2FPRE%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EAs%20you%20can%20see%2C%20the%20code%20is%20very%20similar%20to%20the%20WPF%20implementation.%20The%20only%20difference%20is%20that%20the%3CSPAN%3E%26nbsp%3B%3C%2FSPAN%3E%3CCODE%3EOnActivated%3C%2FCODE%3E%3CSPAN%3E%26nbsp%3B%3C%2FSPAN%3Eevent%20can%20be%20triggered%20by%20multiple%20patterns%20and%2C%20as%20such%2C%20first%20we%20need%20to%20make%20sure%20that%20this%20is%20indeed%20a%20protocol%20activation%2C%20by%20checking%20the%20real%20type%20of%20the%3CSPAN%3E%26nbsp%3B%3C%2FSPAN%3E%3CCODE%3EIActivataedEventArgs%3C%2FCODE%3E%3CSPAN%3E%26nbsp%3B%3C%2FSPAN%3Eparameter.%20In%20case%20of%20protocol%20activation%2C%20it%20will%20be%3CSPAN%3E%26nbsp%3B%3C%2FSPAN%3E%3CCODE%3EProtocolActivatedEventArgs%3C%2FCODE%3E%2C%20which%20gives%20us%20access%20to%20the%20to%20the%3CSPAN%3E%26nbsp%3B%3C%2FSPAN%3E%3CCODE%3EUri%3C%2FCODE%3E%3CSPAN%3E%26nbsp%3B%3C%2FSPAN%3Eproperty%20we%20need%20to%20retrieve%20the%20activation%20URL.%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CH3%20id%3D%22wrapping-up%22%20id%3D%22toc-hId--1000268300%22%20id%3D%22toc-hId--1000268300%22%20id%3D%22toc-hId--1000268300%22%20id%3D%22toc-hId--1000268300%22%3EWrapping%20up%3C%2FH3%3E%0A%3CP%3EThis%20implementation%20is%20based%20on%20the%20standard%20custom%20protocol%20support%20offered%20by%20Windows%2C%20so%20it's%20very%20easy%20to%20implement.%20Every%20development%20platform%20support%20a%20way%20to%20get%20activation%20parameters%20when%20the%20application%20starts%2C%20so%20you%20just%20need%20to%20write%20some%20code%20to%20manage%20the%20desired%20scenario.%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EYou%20can%20find%20the%20full%20sample%20used%20in%20this%20blog%20post%3CSPAN%3E%26nbsp%3B%3C%2FSPAN%3E%3CA%20href%3D%22https%3A%2F%2Fgithub.com%2Fmicrosoft%2FWindows-AppConsult-Samples-DesktopBridge%2Ftree%2Fmain%2FBlog-AppInstallerWithActivation%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noreferrer%22%3Eon%20GitHub%3C%2FA%3E.%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EHappy%20coding!%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CH3%20id%3D%22references%22%20id%3D%22toc-hId-1487244533%22%20id%3D%22toc-hId-1487244533%22%20id%3D%22toc-hId-1487244533%22%20id%3D%22toc-hId-1487244533%22%3EReferences%3C%2FH3%3E%0A%3CUL%20id%3D%22pragma-line-155%22%3E%0A%3CLI%20id%3D%22pragma-line-155%22%3EApp%20Installer%3A%3CSPAN%3E%26nbsp%3B%3C%2FSPAN%3E%3CA%20href%3D%22https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fwindows%2Fmsix%2Fapp-installer%2Fapp-installer-root%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noreferrer%22%3Ehttps%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fwindows%2Fmsix%2Fapp-installer%2Fapp-installer-root%3C%2FA%3E%3C%2FLI%3E%0A%3CLI%20id%3D%22pragma-line-156%22%3EProtocol%20support%20in%20MSIX%3A%3CSPAN%3E%26nbsp%3B%3C%2FSPAN%3E%3CA%20href%3D%22https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fwindows%2Fapps%2Fdesktop%2Fmodernize%2Fdesktop-to-uwp-extensions%23protocol%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noreferrer%22%3Ehttps%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fwindows%2Fapps%2Fdesktop%2Fmodernize%2Fdesktop-to-uwp-extensions%23protocol%3C%2FA%3E%3C%2FLI%3E%0A%3CLI%20id%3D%22pragma-line-157%22%3EWindows%20Application%20Packaging%20Project%3A%3CSPAN%3E%26nbsp%3B%3C%2FSPAN%3E%3CA%20href%3D%22https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fwindows%2Fmsix%2Fdesktop%2Fdesktop-to-uwp-packaging-dot-net%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noreferrer%22%3Ehttps%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fwindows%2Fmsix%2Fdesktop%2Fdesktop-to-uwp-packaging-dot-net%3C%2FA%3E%3C%2FLI%3E%0A%3CLI%20id%3D%22pragma-line-158%22%3EHttpUtility%20class%3A%3CSPAN%3E%26nbsp%3B%3C%2FSPAN%3E%3CA%20href%3D%22https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fdotnet%2Fapi%2Fsystem.web.httputility%3Fview%3Dnetcore-3.1%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noreferrer%22%3Ehttps%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fdotnet%2Fapi%2Fsystem.web.httputility%3Fview%3Dnetcore-3.1%3C%2FA%3E%3C%2FLI%3E%0A%3C%2FUL%3E%3C%2FLINGO-BODY%3E%3CLINGO-TEASER%20id%3D%22lingo-teaser-1719829%22%20slang%3D%22en-US%22%3E%3CP%3E%3CSPAN%3EAs%20a%20Windows%20developer%2C%20a%20very%20common%20requirement%20you%20might%20be%20asked%20to%20implement%20is%20to%20track%20information%20about%20the%20installation%20process.%26nbsp%3BLet's%20see%20how%20to%20achieve%20this%20task%20with%20MSIX%20and%20App%20Installer.%3C%2FSPAN%3E%3C%2FP%3E%3C%2FLINGO-TEASER%3E%3CLINGO-SUB%20id%3D%22lingo-sub-1725254%22%20slang%3D%22en-US%22%3ERe%3A%20Passing%20installation%20parameters%20to%20a%20Windows%20application%20with%20MSIX%20and%20App%20Installer%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1725254%22%20slang%3D%22en-US%22%3E%3CP%3EWelcome%26nbsp%3B%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F44595%22%20target%3D%22_blank%22%3E%40Matteo%20Pagani%3C%2FA%3E%26nbsp%3B%3C%2FP%3E%3CP%3EI%20am%20sharing%20this%20because%20I%20had%20experience%20like%20we%20want%20to%20add%20new%20feature%20or%20implement%20new%20functionality%20and%20if%20it%20is%20as%20easy%20as%20make%20some%20changes%20in%20UI%2C%20we%20will%20go%20ahead%20with%20that%2C%20but%20in%20case%20it%20required%20coding%20and%20compile%2C%20normally%20we%20leave%20it%20for%20future%20and%20it%20keep%20delays%20until%20we%20find%20some%20free%20time%20to%20implement%20it.%3C%2FP%3E%3C%2FLINGO-BODY%3E
Version history
Last update:
‎Sep 28 2020 05:26 AM
Updated by: