Deploying and Launching non-Whidbey Apps with ClickOnce

A common question when I give talks on ClickOnce is whether you can deploy legacy applications with ClickOnce. The answer depends on how legacy you mean.

If you have an existing managed (.NET) application that will run fine against the .NET framework version 2.0, then you can deploy it using ClickOnce, without needing to rebuild the application using Visual Studio 2005. To do so, you will have to create the directory structure in which to place your application on the deployment server, and can then use the MAGE tool to author and sign application and deployment manifests for the application.

The thing to realize is that when your application is deployed this way, it will be launched inside the host process created by ClickOnce (currently named AppLaunch.exe), which loads the .NET rumtime version 2.0 to host the application. Based on the way .NET runtime and framework unification work, that also means that the version of the .NET Framework class libraries that you will be running against will be the 2.0 versions. If your legacy .NET application uses any features in the framework that have breaking changes between 2.0 and past versions, you might encounter errors when your app is running through ClickOnce that you never experienced before. You also have to realize that the application might be running in partial trust depending on how you configure the security permissions in your application manifest, so that could prevent certain operations in your application that used to work fine when not executed through ClickOnce.

If you app is REALLY legacy (i.e. VB6, MFC, ATL, etc.), as in an unmanaged code executable, then no, you cannot deploy it as an executable through ClickOnce. The MAGE tool takes a look at the executable that you select as the entry point for the application, and won’t let you specify an unmanaged executable as the entry point. Without an entry point, you don’t have a valid launchable ClickOnce application.

Are there workarounds? Of course!! There are always workarounds. If the unmanaged code you are trying to deploy is in the form of a library, there is nothing stopping you from consuming unmanaged code from a ClickOnce application, provided that the ClickOnce application is granted either full trust, or at least the unmanaged code execution security permission through the application trust for the ClickOnce application deployment. If you really want to launch an unmanaged executable through ClickOnce, you could write a very simple shim managed application with .NET that just does a Process.Start. Again, you will need unmanaged code permission for that to work.

A simple example is available here.