What Do You Want to See in Crypto / ClickOnce?

Now that Whidbey's out the door, it's time to look at what we want to do in future releases.  If you've run into any issues with the crypto classes or with ClickOnce let me know!  You can leave comments here or file requests in the MSDN Product Feedback Center.

Even though I'm focusing on crypto and the ClickOnce runtime (simple sandboxed domains, AppLaunch, etc), if you have feedback for other parts of ClickOnce or security I can certainly route those to the right places as well.


Comments (7)

  1. Trygve Valøy says:


    I would like to se support for Plugins (or addins as you call them) in ClickOnce. I have not investigated the issue extensively, but I have read (on your blog among others) that all assemblies used by a ClickOnce-app must be defined in the applicaitons manifest.

    I would like to see the possibility of defining a path from which the ClickOnce-application can search for plugin-assemblies during loading. If this already is possible (and my research is lakking) you can disregard this request.



  2. It’s possible but only by jumping through some hoops as you’ve seen. We’ll look into making it easier for you 🙂


  3. How about a managed implementation of the ECC (FIPS 186-2 and NIST Special Publication 800-56) public key algorithms? The "NSA Crypto Suite B" (http://www.nsa.gov/ia/industry/crypto_suite_b.cfm) does not authorize the use of RSA for SECRET and above usage after 2010. It requires ECC.


  4. Thanks Jeff. ECC is absolutely on our radar or things to look at.


  5. Sam says:

    LinkDemands make it really difficult for code to degrade functionality gracefully in low trust environments as the class with the LinkDemand must be called through reflection e.g. FileSystemWatcher. In this particular case, why is FullTrust required?

  6. Bill says:

    I would like to see RFC2440 (OpenPGP) support.

  7. Anonymous Coward says:

    Hi Shawn,

    My requests can be grouped under two umbrellas (I don’t know whether you’re the right person to send them to, but if you think these thoughts are useful, maybe you can route them to more appropriate people):

    1. ClickOnce vs. MSI – provide some clear guidance on when to choose one vs. the other. Imho, MSI is a much better technology for deploying full-blown clients and it’s supported a lot better in the intranet (it just works with Active Directory and SMS, for instance). On the other hand, ClickOnce does provide a huge benefit, the promise of "web style deployment – modify once, update instantly anywhere". Unless you provide clear and explicit guidance on ClickOnce and its indended use, developers will end up in a mess, just like it happened with a lot of other technologies – some will make one choice, other will go for the other option and I can just bet most of them won’t be making an informed decision.

    2. Provide better tools and guidance on how to write low trust applications. I tried writing low-trust apps and controls, but in many situations you just end up not knowing what to do next. It’s extremely hard in v1.x to determine the minimum, optional and refused permission sets of an assembly. In v2.0 it’s somewhat easier to get things right with PermCalc, but it’s still a tough job (for anything but trivial apps). If something goes wrong it’s hard to tell what happened exactly (unless you’re a CAS guru). It took me a long time to understand and deal with CAS properly, and I’m not sure I’m good at it yet.

    If you think about it, in an ideal world, all apps would have partial trust, not full trust ("the principle of least privilege", right?). I think it’s time for you guys to take a step back and really think this through, if you want it to become a reality. Windows has had support for privileges, restricted tokens, ACLs and lots of other tools for ages, but I can’t really think of any application using them in the real world. Hell, even Microsoft hasn’t used restricted tokens in high-profile apps until recently (but I guess LUA is about to change that :)).

    If you really want people to write partial trust applications, you just have to make it a lot easier for developers. Otherwise, partial trust & CAS will follow the path of restricted tokens & Windows privileges, cool technologies that could save a lot of people from a lot of headaches, but that no one uses because it’s too damn complicated.

Skip to main content