Basically, I want to be able to load both at the startup of my ClickOnce app to
1. Get the Publisher and Product info from the Deployment manifest
2. Iterate through the Application manifest for optional download groups to provide a background process to pre-fetch these groups.
I've scoured the API trying to find out how to get access to the current manifest in a programmatic way....
Thanks,
Jim
!!!URGENT!!! Accessing the Application Manifest and Deployment Manifest at runtime
Chris Patten
ClickOnce v1 doesn't support assemblies belonging to multiple groups, or for groups to be composed of multiple groups; only a flat list of groups is supported.
However, it still sounds like you can acheive this if you carry the necessary data along with the app: With the app manifest carrying a flat set of defined groups, let the app carry a file that defines the group set memberships (set Z contains groups X and Y, etc). The application's on-demand logic could translate a user request for set Z to an on-demand request for groups X, Y, etc. This still requires that you carry custom metadata that mirrors manifest data, and have the necessary app logic to translate sets to groups, but doesn't seem that difficult and should allow you to get the behavior you want.
Soren Lund
There is no supported programmatic method for obtaining manifest information such as publisher/product, or enumerating optional files and dependencies, etc today.
You can get what you want by simplying mirroring this information in a file carried with the app. It is inelegant and requires keeping this file in sync with the app manifest but is the only way to currently access this information reliably. You should avoid carrying and parsing manifest xml directly since future changes in the manifest schema are not guaranteed to be back-compatible and could break your parser.
We are evaluating exposing a manifest DOM to applications for the purpose of reflecting over the manifest metadata in future releases of ClickOnce.
GrayShade
ScottK11203
Alan Caceres
Hi James,
I don't suppose you ever got any response to this Were you able to find a workaround
I'd like to be able to list the optional updates and give the user a choice as to whether they are installed.
Thanks,
David.
ravi bhagat
This is essentially what I am doing now. However, the next part I think is really a must is that ability to create dynamic download groups *or* have the ability when creating the manifest to assign assemblies to multiple groups.
For example, we isntall via ClickOnce our core assemblies and set the rest of the application to optional so that they can be downloaded on demand. However, some power users may want to get everything up front. Well, right now there is no elegant solution to this. What I am doing now is iterating thru my copy of the download groups as mentioned above and checking if each group is downloaded individually. This is very inefficient it seems and is compounded by a larger number of assemblies. It would be ideal to have the existing groups *also* incldued in a master group or second group that can be called to download the remainder in one call...this would solve many performance problems with retrieving the "rest" of the application.
fragglefeet
michaelgrimm
I will have to check to see if we can do this. Also, I would like to clarify that the time to cehck for and then start downloading takes a long time. I haven't broken it down to the checking of the download group versus begining to download the group. Seems that there is a significant amount of time between asking to download the group and before anything is actually downlaoded, and a lot of disk activity is taking place at that time.
If I can't get access to our real deployment then I would have to create a sample app that has as many assemblies. I truly suspect it is because of the number of files that is causing the performance issue. There has been another person in this forum that complained of something similar in relation to having a large number of files.
Theo Postma
This is what I am doing, however, making the additional on demand requests for many mutliple groups is not very efficient. More time is spent outside of actually downloading the files. I have a rather large ClickOnce deployment with 500+ files, and just checking if one group is downlaoded can take 9 seconds on a very fast machine. So I assumed doing this once would be far more efficient than N times.
I have also a bug in that states that checking if files are downloaded in a large ClickOnce deployment takes far too long. I've seen it take as long as 3-4 minutes to check if a file group has been downloed already. All this time it is doing it, there is a lot of disk activity so I can only assume it is because o the number of files. However, if only 3 of those N number of files are in the group, why does it take so long I assume it should only need to look for the files in the group and not touch the others...