No excuses. I've heard all about how CAS is a fact of life, but there's no reason -- none whatsoever -- that this system can't generate meaningful messages when trapping loader exceptions.

The least MSFT could do would be to tell us which assembly has inadequate evidence or permissions. There's no reason you can't tell us where the problem lies when you refuse to run our code over what amounts to a mere technicality.

cpurick wrote:

No excuses. I've heard all about how CAS is a fact of life, but there's no reason -- none whatsoever -- that this system OmegaMan VSTO security is a very complicated thing and I was frustrated myself on many occasions (see this one). And I work on the team! But let me put this thread into a more constructive direction and ask you what feedback from the security system would you like to see? Misha (VSTO team is hiring. We would like to hear from you http://tinyurl.com/ZQGW2) Misha Shneerson - MSFT Well, as I said, I think it would be nice if the loader logged details about which assemblies were being rejected, and why. This functionality could conceivably be extended to include a design-time test-loader that verifies the "loadability" of an entire deployment package. Also, there's no reason we should have to write our own code to script caspol.exe. The install packer should be able to generate this as something that would complement the above design-time functionality. I'll hold my tongue because I realize the VSTO team did not write this security model as much as they chose it from a limited selection, but I have serious doubts about whether all this extra effort is worth the marginal security it provides. After all, it appears that any ordinary user can pretty much give any software "full trust" permissions by simply installing it -- as long as it's strongly named. How can that be called "security?" cpurick For the logging part - it is there - just not enabled by default. See this link: Troubleshooting Add-ins Using a Log File and Error Messages Visual Studio Tools for Office can write all errors that occur during startup to a log file or display each error in a message box. By default, these options are turned off for Outlook projects. You can turn the options on by adding and setting environment variables. To display each error in a message box, set the VSTO_SUPPRESSDISPLAYALERTS variable to 0 (zero). You can suppress the messages by setting the variable to 1 (one). To write the errors to a log file, set the VSTO_LOGALERTS variable to 1 (one). Visual Studio Tools for Office creates the log file in the folder that contains the application manifest. The default name is <Manifestname>.manifest.log. To stop logging errors, set the variable to 0 (zero). For information about setting environment variables in Microsoft Windows XP, see "How To Manage Environment Variables in Windows XP" (http://support.microsoft.com/default.aspx?scid=kb;en-us;310519). The "secuirty" part of VSTO security is that end-user has to make explicit decision to trust the code. Suppose, there is a scenario when someone sends you a Word document. When you open it you really do not intend that the mere fact of opening to document will execute code on your machine. So, to mitigate against this you need to make a trust decision - and VSTO have picked CAS as a security mechanism. We are aware of the usability aspects of this security model and we are trying to improve it, but again, everything about security must be EXPLICIT. We need you to be an active participant of the security story for the component that you deploy to your customers. Security is not the right choice for "It just works" approach. I know it is painful to have absolutely NONE tools support for deployment. This will get somewhat better in v3. But still we need to make tought choice when choosing between not allowing any trojans on the end-user machine and having developers work harder. Misha (VSTO team is hiring. We would like to hear from you http://tinyurl.com/ZQGW2) Misha Shneerson - MSFT "The "secuirty" part of VSTO security is that end-user has to make explicit decision to trust the code." Once we establish that all the "security" model really does is require the user to install applications, then what purpose is served by making it any harder than necessary to package installable applications? Surely you're not about to argue that the increased difficulty of building installable applications helps to deter hackers...? "Security is not the right choice for "It just works" approach." True, but security should also be more than just requiring the end-user to install the program.  Frankly, it's an insult that I have to subscribe to CAS and carefully key my entire deployment when the truth is that any hacker can do all the same things, and that in the end the only thing that makes us secure is our reliance on the user to only install "good" programs.  Make no mistake: this model may protect Microsoft, but from where I stand it's mostly just programming overhead.  Show me a model where my software will work but the malware won't, and maybe it'll be worth the effort. I appreciate the logging tips.  I will be sure to try it the next time I'm having problems with an installer.  Are you saying it will actually tell me which component/strong name key is the problem? cpurick The log should have the complete security exception with the stack (from which you should be able to conclude which assembly failed to load and why. Misha (VSTO team is hiring. We would like to hear from you http://tinyurl.com/ZQGW2) Misha Shneerson - MSFT Also, I think the problem (and our mistake) is that we have projected our security system that was originally developed to protect against code executed by documents (which do not require the full installation and this security story makes more sense) onto our security story for the add-ins. Misha (VSTO team is hiring. We would like to hear from you http://tinyurl.com/ZQGW2) Misha Shneerson - MSFT

reply 8

You can use google to search for other answers Enter your search terms Submit search form   Web www.bokebb.com

More Articles

·VSTO Runtime Installation

·InfoPath 2003 Tools for Visual Studio 2003

·Re-opening message after MessageClass changed

·Filter in Word 2003

·How To Get ->> Microsoft.Office.Tools.Excel

·Workbook VBA project stays in memory after the workbook is closed

·How to build Installer in 'Release' mode

·Find.Execute throws "Command is not available" error

·Excel & VSTO problem

·Switching to an existing instance of outlook and opening the cale...