tags:

views:

23

answers:

2

Hi There, I have a ClickOnce application that checks a server for a new version on startup. I recently deployed a new version (2.0.0.0) whilst leaving the old version (1.9.9.9) on the server.

On startup version 2 will inform the user that a new version of available and download 1.9.9.9.

Is there a reason this could be happening? I assumed that ClickOnce would look at the version numbers alone when deciding if a version was newer or not.

Thanks

EDIT - this is the publish version

EDIT TWO

Thanks for the replies guys. The app is published by visual studio. It has placed a .application file in the root which contains info such as the following:

<assemblyIdentity name="CokeAudit.application" version="2.0.0.0" publicKeyToken="0000000000000000" language="neutral" processorArchitecture="x86" xmlns="urn:schemas-microsoft-com:asm.v1" />

The .application file that exists on the server (which I havent updated to the new version yet) contains a .application file in the root which contains details such as:

<assemblyIdentity name="CokeAudit.application" version="1.9.9.9" publicKeyToken="4c4bf139090ca52a" language="neutral" processorArchitecture="x86" xmlns="urn:schemas-microsoft-com:asm.v1" />

The only thing I can see that is different, aside from the version number, is the public key info. Could this be due to the fact that between version 1.9.9.9 I had to disable the signing of the application as the certificate expired? Would this cause the upgrade issue?

I did not, at any stage, sign the app with an actual 'proper' certificate - it was always a test one generated by visual studio.

+2  A: 

ClickOnce does not look at the version numbers -- it simply looks at the application manifest file in the top level directory of your ClickOnce repository. This is important when, for example, you need to do an enforced rollback of a release.

Make sure the application manifest in the top level is the same as the application manifest in the 2.0.0.0 directory under Application files -- if it's not, just copy the manifest up to the top level.

Richard Dunlap
+1  A: 

How are you publishing your application? IF you are using Visual Studio, it will place the new deployment manifest (.application file) in the root; otherwise Richard Dunlap is right, you will need to do that yourself.

The other case where I've seen people have this problem is when caching is turned on on the webserver. (I think I've only heard of that with Unix or Apache servers.)

RobinDotNet