G
Guest
I have an application that I would like to deploy via ClickOnce. I have
read from several sources you never want to store end-user managed data in
the application data of a click once application because it will be removed
on subsequent upgrades. However, I haven’t seen any posts that mention where
end-user managed documents should be stored.
I think I might like to create a repository on the end-users application
that stores end-user managed documents. This repository would store the
source files the end-user supplies for use with my application. My
application would provide a nice means of navigating through these end-user
files. These files should never be deleted or changed on the deployment of
new revisions of my application. Where should a repository like this be
created when deploing a clickOnce application. I would like for the
application to create this repository on installation.
This application also makes extensive use of an excel spreadsheet that
is deployed with the application. I expect that the spreadsheet will most
likely be revised far more often than the application itself. I always plan
to provide the latest and greatest spreadsheet with my application, but I’m
not sure I want to be obligated to redeploy my application just because the
spreadsheet has been revised. For this reason I give the user the ability
to point my application to a different spread sheet that may be supplied via
another source. I have experimented with having my application copy the new
spreadsheet back into the data directory of the application but I’m not sure
if this is the best approach.
I am also concerned that this spreadsheet is also quite large and if it
ends up being stored in the data directory of each revision of the
application it could really waste a lot of space. Also my users might not
appreciate it if this spreadsheet is deleted on the next release of the
application. For this reason I was considering having a partially end-user
managed repository for my application. In this case I might never delete
thier previous document. I would just copy the new document into
semi-end-user managed data repository and point my application to the new
document on the first run of the application after clickonce deployment.
If I were to create an end-user manage document repository for my
application where should it be placed when deploying the application by
clickonce?
Also what parts of the old deployment remain on the clients machine after
a new rev of the application is deployed?
As I mentioned before the spread sheet is quite large. I would prefer not
to have old revisions of the spread sheet lying around in old application
data folders (or copied into the new deployments and renamed) as it is hard
for the users to navigate the click once directories and these files may just
never be deleted.
If anyone has any guidance it would be most appreciated
Thanks,
Jeff
read from several sources you never want to store end-user managed data in
the application data of a click once application because it will be removed
on subsequent upgrades. However, I haven’t seen any posts that mention where
end-user managed documents should be stored.
I think I might like to create a repository on the end-users application
that stores end-user managed documents. This repository would store the
source files the end-user supplies for use with my application. My
application would provide a nice means of navigating through these end-user
files. These files should never be deleted or changed on the deployment of
new revisions of my application. Where should a repository like this be
created when deploing a clickOnce application. I would like for the
application to create this repository on installation.
This application also makes extensive use of an excel spreadsheet that
is deployed with the application. I expect that the spreadsheet will most
likely be revised far more often than the application itself. I always plan
to provide the latest and greatest spreadsheet with my application, but I’m
not sure I want to be obligated to redeploy my application just because the
spreadsheet has been revised. For this reason I give the user the ability
to point my application to a different spread sheet that may be supplied via
another source. I have experimented with having my application copy the new
spreadsheet back into the data directory of the application but I’m not sure
if this is the best approach.
I am also concerned that this spreadsheet is also quite large and if it
ends up being stored in the data directory of each revision of the
application it could really waste a lot of space. Also my users might not
appreciate it if this spreadsheet is deleted on the next release of the
application. For this reason I was considering having a partially end-user
managed repository for my application. In this case I might never delete
thier previous document. I would just copy the new document into
semi-end-user managed data repository and point my application to the new
document on the first run of the application after clickonce deployment.
If I were to create an end-user manage document repository for my
application where should it be placed when deploying the application by
clickonce?
Also what parts of the old deployment remain on the clients machine after
a new rev of the application is deployed?
As I mentioned before the spread sheet is quite large. I would prefer not
to have old revisions of the spread sheet lying around in old application
data folders (or copied into the new deployments and renamed) as it is hard
for the users to navigate the click once directories and these files may just
never be deleted.
If anyone has any guidance it would be most appreciated
Thanks,
Jeff