Archive

Posts Tagged ‘ClickOnce’

RemoteX Application Clients now work on 64-bit

May 29th, 2009 No comments

As a result of the recent changes to the ClickOnce deployment of RemoteX Applications. All clients now work on 64-bit operatingsystems. Verified on Windows Server 2008 and Vista.

Tags:

Changing the platform of ClickOnce deployed applications breaks automatic upgrade

May 27th, 2009 No comments

I wrote earlier about and issue with ClickOnce Deployment, where the processor of the deployment manifests need to match the processor the application is compiled for. Naturally of course, it turns out we need to compile for a specific platform.

By compiling for x86 and marking the deployment manifest as x86 we managed to get some applications running on 64-bit machines. These applications have dependencies on assemblies that crashes if they are run on 64-bit machines, but aren’t compiled for any specific architecture.

So we recently changed to x86 on most of our ClickOnce-deployments. This resulted in the following error when upgrading previous versions.

+ The deployment identity does not match the subscription.

Apparently when we change the application to compile using x86 the applications identity is changed. This means that the ClickOnce-deployment doesn’t work when we shift from All Platforms to x86.

Updating ClickOnce deployment manifest with PowerShell

May 20th, 2009 No comments

We are automating some of our deployment using powershell. As such we use the command line tool mage.exe for signing our deployment manifests, in effect were creating them using mage.exe as well.

We needed to add the trustUrlParamter setting to one of our manifests. Using mageui.exe you just check the box for allowing the application to see the query string, but with mage.exe this isn’t possible.

What you need to do is modify the XML of the application.deployment manifest, adding the parameter as an attribute to the deployment tag.

<deployment install="true" >

Should become

<deployment install="true" trustURLParameters="true">

As I said, we’ve already automated the process of creating and signing deployment manifests using powershell, now we just need to add the element attribute before signing the manifest. Powershell has some nifty features for updating XML, part 3 of  Windows PowerShell in Action: Working With Text and Files in Windows PowerShell (Part 3) demonstrates this.

So just before invoking mage.exe to sign the manifest we add this litle piece of powershell code:

    $xml = [xml]( Get-Content $deploymentManifestPath )
    $trustUrl = $xml.CreateAttribute("trustURLParameters")
    $trustUrl.psbase.Value = "true"
    $null = $xml.assembly.deployment.SetAttributeNode($trustUrl)

Voila, the manifest now has the trustURLParameters set.

The customHostSpecified attribute is not supported for Windows Forms applications.

May 20th, 2009 No comments

Last night we worked on ClickOnce deploying an application. The application is a connector between two standard systems, one for economics and the other is RemoteX Applications. In essence it means that our customers will be able to update their integration with the economic system by ClickOnce.

It is an application because the economic system is designed for small scale enterprises and doesn’t have a server component.

Anyway as we were working on the ClickOnce deployment, and as usual we get a deployment error. This however was a new one:

The customHostSpecified attribute is not supported for Windows Forms applications.

The problem is that the application was compiled for x86 platforms, switching it to all platforms resolves the deployment error. Switching to All Platforms isn’t an issue for us, but I can imagine it becoming a problem if you need to specify the platform.

In that case you would have to look into the mage commands reference:

http://msdn.microsoft.com/en-us/library/acz3y3te.aspx

and work with the -p parameter for specifying the processor.