J
Jamey McElveen
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/WindowsApplication1.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/WindowsApplication1.application
resulted in exception. Following failure messages were detected:
+ Exception reading manifest from
http://localhost/app/111111/WindowsApplication1.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/WindowsApplication1.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/WindowsApplication1.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
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/WindowsApplication1.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/WindowsApplication1.application
resulted in exception. Following failure messages were detected:
+ Exception reading manifest from
http://localhost/app/111111/WindowsApplication1.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/WindowsApplication1.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/WindowsApplication1.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