|
We have a rather large ClickOnce WinForm app that is commonly deployed to a workstation that is shared by multiple users. It is very inconvienant (and annoying) for every user to have to install the app and/or version upgrades. It would be nice if, like many thick clients, there was an option for "just me" or "everyone who uses this computer" during the initial install,but this option is not available out of the box.
Is there some way this can be done programatically using the deployment namespace? |
| Bill2010 Wednesday, July 29, 2009 6:39 PM |
Sorry, you can't do this with ClickOnce. The deal is that ClickOnce installs the application under the user's profile, which is why it doesn't require privileges to install it. RobinDotNet Click here to visit my ClickOnce blog!- Marked As Answer byBill2010 Thursday, July 30, 2009 1:45 PM
-
|
| RobinDotNet Wednesday, July 29, 2009 11:11 PM |
Hi Bill2010, ClickOnce is designed to be a per-user installation, so there are no deployment namespaces you can leverage to get it installing for all users. I found some interesting ways others applied in the deployment when needing this kind of requirement in this discussion . You can take a look, and see if it is suitable for you. Best regards, Bruce Zhou
Please remember to mark the replies as answers if they help and unmark them if they provide no help. Welcome to the All-In-One Code Framework! If you have any feedback, please tell us. Send us any feedback you have about the help from MSFT at fbmsdn@microsoft.com. - Marked As Answer byBill2010 Thursday, July 30, 2009 1:37 PM
-
|
| Bruce.Zhou Thursday, July 30, 2009 3:33 AM |
I understand your frustration, but one of the things that ClickOnce is supposed to be able to do is to be installed with no privileges, and you can't install for all users with no privileges. It's supposed to be a low profile simple deployment that an organization can trust won't mess with any other folders it's not supposed to. RobinDotNet Click here to visit my ClickOnce blog!- Marked As Answer byBill2010 Monday, August 10, 2009 3:22 PM
-
|
| RobinDotNet Thursday, July 30, 2009 4:50 PM |
Sorry to hear that. I've passed a link to thie thread along to someone at MSFT to let them know that this question comes up once or twice a month. Maybe in the future they will address it. RobinDotNet Click here to visit my ClickOnce blog!- Marked As Answer byBill2010 Monday, August 10, 2009 3:21 PM
-
|
| RobinDotNet Monday, August 10, 2009 5:36 AM |
Sorry, you can't do this with ClickOnce. The deal is that ClickOnce installs the application under the user's profile, which is why it doesn't require privileges to install it. RobinDotNet Click here to visit my ClickOnce blog!- Marked As Answer byBill2010 Thursday, July 30, 2009 1:45 PM
-
|
| RobinDotNet Wednesday, July 29, 2009 11:11 PM |
The problem is we are not a freely distributed app. Our access and clients will be tightly controlled.It would be far better for us to deal with the privilage issue than the complaints we are going to get from having the same app download and update on a per user basis per workstation. I guess I don't understand why there isn't at least an interface in the deployment namespace where we could make this feature available, as it is with the vast number of thick applications.
Total bummer. |
| Bill2010 Wednesday, July 29, 2009 11:35 PM |
Hi Bill2010, ClickOnce is designed to be a per-user installation, so there are no deployment namespaces you can leverage to get it installing for all users. I found some interesting ways others applied in the deployment when needing this kind of requirement in this discussion . You can take a look, and see if it is suitable for you. Best regards, Bruce Zhou
Please remember to mark the replies as answers if they help and unmark them if they provide no help. Welcome to the All-In-One Code Framework! If you have any feedback, please tell us. Send us any feedback you have about the help from MSFT at fbmsdn@microsoft.com. - Marked As Answer byBill2010 Thursday, July 30, 2009 1:37 PM
-
|
| Bruce.Zhou Thursday, July 30, 2009 3:33 AM |
Thanks. That link was helpful.
I do wish Microsoft would rethink their design constraint on this. It is particularly annoying to those of us with a well-known/controlled target user group. It seems to me that this should be something that is OUR choice to make, not Microsoft's. Especially as I am getting a lot of grief from stakeholders on the limitation. |
| Bill2010 Thursday, July 30, 2009 1:45 PM |
I understand your frustration, but one of the things that ClickOnce is supposed to be able to do is to be installed with no privileges, and you can't install for all users with no privileges. It's supposed to be a low profile simple deployment that an organization can trust won't mess with any other folders it's not supposed to. RobinDotNet Click here to visit my ClickOnce blog!- Marked As Answer byBill2010 Monday, August 10, 2009 3:22 PM
-
|
| RobinDotNet Thursday, July 30, 2009 4:50 PM |
I have no problem with that design goaland it should definitelybe AN option (even the default option)... but not the ONLY option.
I really don't understand why Microsoft is being so adament about restricting my flexibility in a way that causes more problems for MY target user's and stakeholders.
Oh, well... it is what it is, I guess. |
| Bill2010 Thursday, July 30, 2009 5:20 PM |
I understand what you mean. My guess would be that the whole "install in the user's profile" is a basic underpinning of the design, and would be a major reworking on their part. For doing that, using a setup & deployment package (included in VS Professional, and I think VS Standard as well) makes more sense. RobinDotNet Click here to visit my ClickOnce blog! |
| RobinDotNet Friday, July 31, 2009 8:40 AM |
We are using a hybred SaaS architecture that is designed for frequent (possibly monthly) upgrades, so distributing and installing the package would be impractical and ClickOnce makes more sense. We have moduralized the app so that only those parts that change will be downloaded on a version upgrade in order to speed up the process and presever customer bandwith to their site... this would become a little more problematic if we use a deployment package.
We went with WinForm over a pure SaaS WebForm because we needed more granularity in the user interaction and we support a concept we call "gracefull degradation." We have minimal hardware deployed to the customers site, but do have a small custom appliance there that allows the application to run in degraded mode for essential business functions in the event of catastrophic failure to the backend. This applience is synchronized to the backend, which catches up once the connection is restored.
There was some thought of writing our own version of ClickOnce, but this is a major undertaking... although we may have no choice, depending on customer feedback. |
| Bill2010 Friday, July 31, 2009 1:43 PM |
What is the problem with having the user have their own version of the application?
Is it completely impractical to have the users all use the same windows account when they want to access that application? Or do they need access to their own files at the same time? YOu could even leave the general account logged on all the time, and they can switch to that user when they need to do something with your application.
It's not perfect, but it might help.
RobinDotNet Click here to visit my ClickOnce blog! |
| RobinDotNet Sunday, August 02, 2009 6:01 PM |
The problem is the time it sometimes takes to do an update, depending on which modules changed. If it updated once for one user, it will be annoying to have to do it AGAIN for another.
Each user logs in separately due to different roles one user may have vs. another... and for logging purposes. |
| Bill2010 Wednesday, August 05, 2009 5:49 PM |
I understand. But the user won't know that the other user already updated. So aside from you just knowing it, the user will see it as him receiving an update, and won't even know it's a duplicate. You could try it and see what they say...
RobinDotNet Click here to visit my ClickOnce blog! |
| RobinDotNet Thursday, August 06, 2009 1:35 AM |
There is no way that users will be unaware of this insofar as the download process already takes up considerable time and bandwidth, which we are making effort to manage.
I explained Mirosofts reasoning for this limitationas it relates to priviliages to our stakeholders and, quite frankly, it was not well recieved and comes across as sounding like an excuse to them... but we will have to live with it for now, regardless.
If push comes to shove, we may wind up having to write our own version of ClickOnce, which is not desirable as it is 90% of what we are looking for... especially if extended using the existing deployment namespace. |
| Bill2010 Thursday, August 06, 2009 5:40 PM |
Sorry to hear that. I've passed a link to thie thread along to someone at MSFT to let them know that this question comes up once or twice a month. Maybe in the future they will address it. RobinDotNet Click here to visit my ClickOnce blog!- Marked As Answer byBill2010 Monday, August 10, 2009 3:21 PM
-
|
| RobinDotNet Monday, August 10, 2009 5:36 AM |
Thank you. I can't tell you how annoying the current limitation isif you have a need for the solution I am looking for... and how embarassing it is to have to pass along the Microsoft "reason" for it to stakeholders and customers. It comes across as almost dismissive by Microsoft... IOW, take it or leave it.
I do hope they will take this more seriously... especially insofar as we are considering migrating to WPF for future releases. |
| Bill2010 Monday, August 10, 2009 3:21 PM |
You're welcome. You never know. My contact didn't realize people were asking for it.
Good luck!
RobinDotNet Click here to visit my ClickOnce blog! |
| RobinDotNet Tuesday, August 11, 2009 3:23 AM |