Still More on VSTO Security
Here is more of my conversation with Peter Torr on VSTO Security:
ME: The document should prompt the user [that the code isn't trusted], warn them of the dangers of running untrusted code, ask if the the assembly should be granted FullTrust [...] and then set the appropriate security policy automatically.
PT: Great in theory (that's what VBA's "Medium" security mode does) but horrible in practice. Outlook warned users about the dangers of opening VBS or SCR or EXE attachments, but we still had all those e-mail viruses. Now all those extensions are just blocked by Outlook. IE used to warn people before auto-installing ActiveX controls; now you have the "Gold Bar" experience (which is an interesting solution when combined with Authenticode signed code, but not a good enough mechanism by itself). Unfortunately, users just don't make good security decisions, especially when it is interrupting their workflow and they just want to "get their job done." Modal prompting is a BAD idea when it comes to security (emphasis added).
As for the setup project idea... yes, that is one way to do it, although unfortunately we don't ship with a setup project out-of-the-box. (One drawback to local installs is that you can no longer update the assembly in-place if you find a bug).
I really want to comment on the "users just don't make good security decisions" part. There is a part of me that response "they deserve what they get if they don't make good security decisions." However, there is also the part of me that recognizes that a company with Microsoft's visibility is often blamed for things that aren't their fault. I've seen a degree of that even in my little corner of the world. Often when I'm supposed to be interoperating with 3rd party components or tools and the 3rd party tool fails, the failure has been blamed on my app solely because my app is the one that is visible. Nobody interoperates with more 3rd party software than Microsoft. Even though Microsoft isn't technically at fault when a user makes a dumb security decision, Microsoft might be perceived to be at fault by that user. Right or wrong, Microsoft has to guard against that perception. So, in that light, I can sort of see where Peter Torr is coming from.
That said, I still believe there must be a simpler way to manage VSTO security. I don't know what it is yet, but I'll put more mental effort to it when next I have to work with VSTO.
If I haven't said so already Peter, thanks for the time you spent discussing this issue with me.