Security Exception Opinion - Runtime Security Policy
Hi Guys,
I am currently developing an app that will be executed from a network share by multiple users. During testing I ran into the Security Exception caused by executing the assembly from a network location. Not a problem...
I solved this problem by creating the keypair file using the sn.exe utility. Once I had the keypair file I modified the AssemblyInfo.vb with:
VB Code:
<Assembly: AssemblyKeyFile("..\KeyPair.snk")>
Then I created a code group in the .Net 1.1 Config utility and everything is fine...
I was showing a colleague how this was done. I was a little proud of my long winded efforts to get this working. He on the other hand gave me a wierd look of HUH? He proceeded to show me the .Net 1.1 Config. Wizard->Trust an Assembly utility. With no more than about 5 mouse clicks the assembly was running from a network share with full trust. No code modification, no code groups, no keypair files - NOTHING! Why didn't I do it this way he asked? I simply replied with "I was under the impression from the little web research I did, that this is the only way..."
What is the difference, why does the majority of articles on the web explain and promote the long (keypair) way. Why isn't the wizard more commonly used? Why is it that when you use a search string like '.net security exception network share' in Google you are presented with results that only show the keypair method. What is wrong with the wizard? If nothing why isnt it promoted as the primary way to do this?
Why is it that when you use the wizard no visible changes are made to your code groups in the runtime security policy?
What are your thoughts and experiences on this people? Any links to articles on the Wizard->Trust an Assembly?
Re: Security Exception Question - Runtime Security Policy