1

Using this strategy the MSDN documentation states that "Technically, the application is downloaded and installed to an application cache on the local computer. This strategy works best for applications that are used infrequently—for example, an employee-benefits tool that is typically run only once a year."

  1. Is it possible to use full trust with this strategy?

  2. I want to be able to create/update user settings on a serialized xml file. Is this possible? [Note: I can't depend on ClickOnce Settings because they are deleted at the end of a session. From MSDN: When the user clicks a link on a Web page (or double-clicks an icon on the file share), the application is started. When users close the application, it is no longer available on their local computer"]

  3. Why does MS recommend infrequent use of this strategy?

  4. Any comments (pro/cons) from actual experience in using this strategy would be sincerly appreciated.

Ananize Scott
  • 901
  • 1
  • 8
  • 11

1 Answers1

0

That wording is misleading. ClickOnce works great for frequently and infrequently used apps. However, in the infrequent scenario, ClickOnce is particularly nice because users can just start the app and immediately be on the newest version rather than messing with downloading/running an .msi and then going through the install prompts. This doesn't mean that it doesn't work well with apps you use daily. Quite the opposite, it works great.

Your app can request full trust and will then be able to do anything the user running the app has privileges to do. So creating/editing an xml file shouldn't be an issue. The line about "it is no longer available" after they close the app is false. All the ClickOnce files are installed into the user profile and stay there when the app is closed. You have several options for your xml file. I've used application-scoped isolated storage before and it has worked quite well, but it may just depend on your scenario.

Community
  • 1
  • 1
codeConcussion
  • 12,739
  • 8
  • 49
  • 62