Hello,

I would like to use ClickOne but we need to stagger our update process.
Currently we are shipping cd's when it is time for an update. We stagger
the release in waves of 250 each so our clients do not overwhelm our support
staff with loading questions and new feature questions. ClickOnce will
elininate the CD cost and the loading questions but that still does not take
care of the calls for new feature questions. I would like to control which
clients get updated and which have to wait.

In my first attempt I set up a server that direct the client to their
install version based on client number.

The server has these two PHISICAL install locations
http://mysite.com/app/ver2006_11_15 and http://mysite.com/app/ver2007_01_01

The client would install from a virtual location
for example one client would install/update from
http://mysite.com/app/100001
where the next would go to http://mysite.com/app/100002

neither of these physical paths exist so I redirect them according to which
version I want the client to receive

http://mysite.com/app/100001 will transfer to
http://mysite.com/app/ver2006_11_15 (not updated)
http://mysite.com/app/100002 will transfer to
http://mysite.com/app/ver2007_01_01 (receives an update)

the redirection works but, the problem is keeping the clients sitenumber in
tact after they receive the .application file.

To TRY and resolve this I intercept all *.application request and change
the deploymentProvider codebase on the fly.
for example I change
<deploymentProvider
codebase="http://mysite.com/app/ver2006_11_15/WindowsApplication1.application"
/>
to
<deploymentProvider
codebase="http://mysite.com/app/100001/WindowsApplication1.application" />
(if you try this yourself be sure to add this line Response.ContentType =
"application/x-ms-application"; )

the change takes but the problem occurs when ClickOnce downloads the
application.exe.manifest I get and error (pasted below)

Any help would be appreciate. I do not mind completely changing direction
but I cannot create a folder for each of our clients it would be to much to
manage.

If I can change the update path on the fly that will work or or another Idea
is if I can get the client application to specify which version they run on
that would work also (I wonder if this is possible because in a ClickOne add
remove programs you can choose to roolback to a previous version).

Thanks

Jamey

----------------
here is that error
-----------------

PLATFORM VERSION INFO
Windows : 5.1.2600.131072 (Win32NT)
Common Language Runtime : 2.0.50727.42
System.Deployment.dll : 2.0.50727.103 (QFE.050727-1000)
mscorwks.dll : 2.0.50727.42 (RTM.050727-4200)
dfdll.dll : 2.0.50727.42 (RTM.050727-4200)
dfshim.dll : 2.0.50727.42 (RTM.050727-4200)

SOURCES
Deployment url :
http://localhost/app/111111/WindowsA...n1.application

ERROR SUMMARY
Below is a summary of the errors, details of these errors are listed later
in the log.
* Activation of http://localhost/app/111111/WindowsA...n1.application
resulted in exception. Following failure messages were detected:
+ Exception reading manifest from
http://localhost/app/111111/WindowsA...1.application: the manifest
may not be valid or the file could not be opened.
+ Manifest XML signature is not valid.
+ The digital signature of the object did not verify.


COMPONENT STORE TRANSACTION FAILURE SUMMARY
No transaction error was detected.

WARNINGS
There were no warnings during this operation.

OPERATION PROGRESS STATUS
* [1/19/2007 12:10:48 PM] : Activation of
http://localhost/app/111111/WindowsA...n1.application has started.

ERROR DETAILS
Following errors were detected during this operation.
* [1/19/2007 12:10:48 PM]
System.Deployment.Application.InvalidDeploymentException (ManifestParse)
- Exception reading manifest from
http://localhost/app/111111/WindowsA...1.application: the manifest
may not be valid or the file could not be opened.
- Source: System.Deployment
- Stack trace:
at System.Deployment.Application.ManifestReader.FromDocument(String
localPath, ManifestType manifestType, Uri sourceUri)
at
System.Deployment.Application.DownloadManager.DownloadDeploymentManifestDirectBypass(SubscriptionStore
subStore, Uri& sourceUri, TempFile& tempFile, SubscriptionState& subState,
IDownloadNotification notification, DownloadOptions options,
ServerInformation& serverInformation)
at
System.Deployment.Application.DownloadManager.DownloadDeploymentManifestBypass(SubscriptionStore
subStore, Uri& sourceUri, TempFile& tempFile, SubscriptionState& subState,
IDownloadNotification notification, DownloadOptions options)
at
System.Deployment.Application.ApplicationActivator.PerformDeploymentActivation(Uri
activationUri, Boolean isShortcut)
at
System.Deployment.Application.ApplicationActivator.ActivateDeploymentWorker(Object
state)
--- Inner Exception ---
System.Deployment.Application.InvalidDeploymentException
(SignatureValidation)
- Manifest XML signature is not valid.
- Source: System.Deployment
- Stack trace:
at
System.Deployment.Application.Manifest.AssemblyManifest.ValidateSignature(Stream
s)
at System.Deployment.Application.ManifestReader.FromDocument(String
localPath, ManifestType manifestType, Uri sourceUri)
--- Inner Exception ---
System.Security.Cryptography.CryptographicException
- The digital signature of the object did not verify.

- Source: System.Deployment
- Stack trace:
at
System.Deployment.Internal.CodeSigning.SignedCmiManifest.Verify(CmiManifestVerifyFlags
verifyFlags)
at
System.Deployment.Application.Manifest.AssemblyManifest.ValidateSignature(Stream
s)

COMPONENT STORE TRANSACTION DETAILS

Have you tried to uninstall the previous version before click the ClickOne
installation?

chanmm

"Jamey McElveen" <(E-Mail Removed)_nospam> wrote in
message news:%23x9r$6%(E-Mail Removed)...
> Hello,
>
> I would like to use ClickOne but we need to stagger our update process.
> Currently we are shipping cd's when it is time for an update. We stagger
> the release in waves of 250 each so our clients do not overwhelm our
> support staff with loading questions and new feature questions. ClickOnce
> will elininate the CD cost and the loading questions but that still does
> not take care of the calls for new feature questions. I would like to
> control which clients get updated and which have to wait.
>
> In my first attempt I set up a server that direct the client to their
> install version based on client number.
>
> The server has these two PHISICAL install locations
> http://mysite.com/app/ver2006_11_15 and
> http://mysite.com/app/ver2007_01_01
>
> The client would install from a virtual location
> for example one client would install/update from
> http://mysite.com/app/100001
> where the next would go to http://mysite.com/app/100002
>
> neither of these physical paths exist so I redirect them according to
> which version I want the client to receive
>
> http://mysite.com/app/100001 will transfer to
> http://mysite.com/app/ver2006_11_15 (not updated)
> http://mysite.com/app/100002 will transfer to
> http://mysite.com/app/ver2007_01_01 (receives an update)
>
> the redirection works but, the problem is keeping the clients sitenumber
> in tact after they receive the .application file.
>
> To TRY and resolve this I intercept all *.application request and change
> the deploymentProvider codebase on the fly.
> for example I change
> <deploymentProvider
> codebase="http://mysite.com/app/ver2006_11_15/WindowsApplication1.application"
> />
> to
> <deploymentProvider
> codebase="http://mysite.com/app/100001/WindowsApplication1.application" />
> (if you try this yourself be sure to add this line Response.ContentType =
> "application/x-ms-application"; )
>
> the change takes but the problem occurs when ClickOnce downloads the
> application.exe.manifest I get and error (pasted below)
>
> Any help would be appreciate. I do not mind completely changing direction
> but I cannot create a folder for each of our clients it would be to much
> to manage.
>
> If I can change the update path on the fly that will work or or another
> Idea is if I can get the client application to specify which version they
> run on that would work also (I wonder if this is possible because in a
> ClickOne add remove programs you can choose to roolback to a previous
> version).
>
> Thanks
>
> Jamey
>
> ----------------
> here is that error
> -----------------
>
> PLATFORM VERSION INFO
> Windows : 5.1.2600.131072 (Win32NT)
> Common Language Runtime : 2.0.50727.42
> System.Deployment.dll : 2.0.50727.103 (QFE.050727-1000)
> mscorwks.dll : 2.0.50727.42 (RTM.050727-4200)
> dfdll.dll : 2.0.50727.42 (RTM.050727-4200)
> dfshim.dll : 2.0.50727.42 (RTM.050727-4200)
>
> SOURCES
> Deployment url :
> http://localhost/app/111111/WindowsA...n1.application
>
> ERROR SUMMARY
> Below is a summary of the errors, details of these errors are listed later
> in the log.
> * Activation of
> http://localhost/app/111111/WindowsA...n1.application resulted in
> exception. Following failure messages were detected:
> + Exception reading manifest from
> http://localhost/app/111111/WindowsA...1.application: the manifest
> may not be valid or the file could not be opened.
> + Manifest XML signature is not valid.
> + The digital signature of the object did not verify.
>
>
> COMPONENT STORE TRANSACTION FAILURE SUMMARY
> No transaction error was detected.
>
> WARNINGS
> There were no warnings during this operation.
>
> OPERATION PROGRESS STATUS
> * [1/19/2007 12:10:48 PM] : Activation of
> http://localhost/app/111111/WindowsA...n1.application has started.
>
> ERROR DETAILS
> Following errors were detected during this operation.
> * [1/19/2007 12:10:48 PM]
> System.Deployment.Application.InvalidDeploymentException (ManifestParse)
> - Exception reading manifest from
> http://localhost/app/111111/WindowsA...1.application: the manifest
> may not be valid or the file could not be opened.
> - Source: System.Deployment
> - Stack trace:
> at System.Deployment.Application.ManifestReader.FromDocument(String
> localPath, ManifestType manifestType, Uri sourceUri)
> at
> System.Deployment.Application.DownloadManager.DownloadDeploymentManifestDirectBypass(SubscriptionStore
> subStore, Uri& sourceUri, TempFile& tempFile, SubscriptionState& subState,
> IDownloadNotification notification, DownloadOptions options,
> ServerInformation& serverInformation)
> at
> System.Deployment.Application.DownloadManager.DownloadDeploymentManifestBypass(SubscriptionStore
> subStore, Uri& sourceUri, TempFile& tempFile, SubscriptionState& subState,
> IDownloadNotification notification, DownloadOptions options)
> at
> System.Deployment.Application.ApplicationActivator.PerformDeploymentActivation(Uri
> activationUri, Boolean isShortcut)
> at
> System.Deployment.Application.ApplicationActivator.ActivateDeploymentWorker(Object
> state)
> --- Inner Exception ---
> System.Deployment.Application.InvalidDeploymentException
> (SignatureValidation)
> - Manifest XML signature is not valid.
> - Source: System.Deployment
> - Stack trace:
> at
> System.Deployment.Application.Manifest.AssemblyManifest.ValidateSignature(Stream
> s)
> at System.Deployment.Application.ManifestReader.FromDocument(String
> localPath, ManifestType manifestType, Uri sourceUri)
> --- Inner Exception ---
> System.Security.Cryptography.CryptographicException
> - The digital signature of the object did not verify.
>
> - Source: System.Deployment
> - Stack trace:
> at
> System.Deployment.Internal.CodeSigning.SignedCmiManifest.Verify(CmiManifestVerifyFlags
> verifyFlags)
> at
> System.Deployment.Application.Manifest.AssemblyManifest.ValidateSignature(Stream
> s)
>
> COMPONENT STORE TRANSACTION DETAILS
>
>
>
>

Thanks, That will not help because I need to controll the version of each
client independently from the server.

Thanks,

Jamey

"Chan Ming Man" <(E-Mail Removed)> wrote in message
news:4059A649-5D49-4F4E-BE0A-(E-Mail Removed)...
> Have you tried to uninstall the previous version before click the ClickOne
> installation?
>
> chanmm
>
> "Jamey McElveen" <(E-Mail Removed)_nospam> wrote in
> message news:%23x9r$6%(E-Mail Removed)...
>> Hello,
>>
>> I would like to use ClickOne but we need to stagger our update process.
>> Currently we are shipping cd's when it is time for an update. We stagger
>> the release in waves of 250 each so our clients do not overwhelm our
>> support staff with loading questions and new feature questions.
>> ClickOnce will elininate the CD cost and the loading questions but that
>> still does not take care of the calls for new feature questions. I would
>> like to control which clients get updated and which have to wait.
>>
>> In my first attempt I set up a server that direct the client to their
>> install version based on client number.
>>
>> The server has these two PHISICAL install locations
>> http://mysite.com/app/ver2006_11_15 and
>> http://mysite.com/app/ver2007_01_01
>>
>> The client would install from a virtual location
>> for example one client would install/update from
>> http://mysite.com/app/100001
>> where the next would go to http://mysite.com/app/100002
>>
>> neither of these physical paths exist so I redirect them according to
>> which version I want the client to receive
>>
>> http://mysite.com/app/100001 will transfer to
>> http://mysite.com/app/ver2006_11_15 (not updated)
>> http://mysite.com/app/100002 will transfer to
>> http://mysite.com/app/ver2007_01_01 (receives an update)
>>
>> the redirection works but, the problem is keeping the clients sitenumber
>> in tact after they receive the .application file.
>>
>> To TRY and resolve this I intercept all *.application request and change
>> the deploymentProvider codebase on the fly.
>> for example I change
>> <deploymentProvider
>> codebase="http://mysite.com/app/ver2006_11_15/WindowsApplication1.application"
>> />
>> to
>> <deploymentProvider
>> codebase="http://mysite.com/app/100001/WindowsApplication1.application"
>> />
>> (if you try this yourself be sure to add this line Response.ContentType
>> = "application/x-ms-application"; )
>>
>> the change takes but the problem occurs when ClickOnce downloads the
>> application.exe.manifest I get and error (pasted below)
>>
>> Any help would be appreciate. I do not mind completely changing
>> direction but I cannot create a folder for each of our clients it would
>> be to much to manage.
>>
>> If I can change the update path on the fly that will work or or another
>> Idea is if I can get the client application to specify which version they
>> run on that would work also (I wonder if this is possible because in a
>> ClickOne add remove programs you can choose to roolback to a previous
>> version).
>>
>> Thanks
>>
>> Jamey
>>
>> ----------------
>> here is that error
>> -----------------
>>
>> PLATFORM VERSION INFO
>> Windows : 5.1.2600.131072 (Win32NT)
>> Common Language Runtime : 2.0.50727.42
>> System.Deployment.dll : 2.0.50727.103 (QFE.050727-1000)
>> mscorwks.dll : 2.0.50727.42 (RTM.050727-4200)
>> dfdll.dll : 2.0.50727.42 (RTM.050727-4200)
>> dfshim.dll : 2.0.50727.42 (RTM.050727-4200)
>>
>> SOURCES
>> Deployment url :
>> http://localhost/app/111111/WindowsA...n1.application
>>
>> ERROR SUMMARY
>> Below is a summary of the errors, details of these errors are listed
>> later in the log.
>> * Activation of
>> http://localhost/app/111111/WindowsA...n1.application resulted in
>> exception. Following failure messages were detected:
>> + Exception reading manifest from
>> http://localhost/app/111111/WindowsA...1.application: the manifest
>> may not be valid or the file could not be opened.
>> + Manifest XML signature is not valid.
>> + The digital signature of the object did not verify.
>>
>>
>> COMPONENT STORE TRANSACTION FAILURE SUMMARY
>> No transaction error was detected.
>>
>> WARNINGS
>> There were no warnings during this operation.
>>
>> OPERATION PROGRESS STATUS
>> * [1/19/2007 12:10:48 PM] : Activation of
>> http://localhost/app/111111/WindowsA...n1.application has started.
>>
>> ERROR DETAILS
>> Following errors were detected during this operation.
>> * [1/19/2007 12:10:48 PM]
>> System.Deployment.Application.InvalidDeploymentException (ManifestParse)
>> - Exception reading manifest from
>> http://localhost/app/111111/WindowsA...1.application: the manifest
>> may not be valid or the file could not be opened.
>> - Source: System.Deployment
>> - Stack trace:
>> at System.Deployment.Application.ManifestReader.FromDocument(String
>> localPath, ManifestType manifestType, Uri sourceUri)
>> at
>> System.Deployment.Application.DownloadManager.DownloadDeploymentManifestDirectBypass(SubscriptionStore
>> subStore, Uri& sourceUri, TempFile& tempFile, SubscriptionState&
>> subState, IDownloadNotification notification, DownloadOptions options,
>> ServerInformation& serverInformation)
>> at
>> System.Deployment.Application.DownloadManager.DownloadDeploymentManifestBypass(SubscriptionStore
>> subStore, Uri& sourceUri, TempFile& tempFile, SubscriptionState&
>> subState, IDownloadNotification notification, DownloadOptions options)
>> at
>> System.Deployment.Application.ApplicationActivator.PerformDeploymentActivation(Uri
>> activationUri, Boolean isShortcut)
>> at
>> System.Deployment.Application.ApplicationActivator.ActivateDeploymentWorker(Object
>> state)
>> --- Inner Exception ---
>> System.Deployment.Application.InvalidDeploymentException
>> (SignatureValidation)
>> - Manifest XML signature is not valid.
>> - Source: System.Deployment
>> - Stack trace:
>> at
>> System.Deployment.Application.Manifest.AssemblyManifest.ValidateSignature(Stream
>> s)
>> at System.Deployment.Application.ManifestReader.FromDocument(String
>> localPath, ManifestType manifestType, Uri sourceUri)
>> --- Inner Exception ---
>> System.Security.Cryptography.CryptographicException
>> - The digital signature of the object did not verify.
>>
>> - Source: System.Deployment
>> - Stack trace:
>> at
>> System.Deployment.Internal.CodeSigning.SignedCmiManifest.Verify(CmiManifestVerifyFlags
>> verifyFlags)
>> at
>> System.Deployment.Application.Manifest.AssemblyManifest.ValidateSignature(Stream
>> s)
>>
>> COMPONENT STORE TRANSACTION DETAILS
>>
>>
>>
>>
>