"Kevin Westhead" <kevinw@NOSPAM.i2DOTcoDOTuk> wrote in message
news:%23Vpm4RJoEHA.692@TK2MSFTNGP12.phx.gbl...
> Is there a way I can toggle SecurityManager.SecurityEnabled so that I can
> test some methods that check this value? For example, I have a class that
> I
> want to use with NUnit as follows:
>
> [Category("Exceptions - code access security is disabled.")]
> [TestFixture()]
> public class CodeAccessSecurityDisabledExceptions
> {
>
> public CodeAccessSecurityDisabledExceptions() : base()
> {
> }
>
> [TestFixtureSetUp()]
> public void DisableCodeAccessSecurity()
> {
> SecurityManager.SecurityEnabled = false;
> }
>
> [TestFixtureTearDown()]
> public void EnableCodeAccessSecurity()
> {
> SecurityManager.SecurityEnabled = true;
> SecurityManager.SavePolicy();
> }
>
> // Various method tests that are expected to throw SecurityException
> when SecurityManager.SecurityEnabled == false)
>
> }
>
> Unfortunately CAS remains disabled when I run any other tests, so it looks
> like simply setting SecurityManager.SecurityEnabled = true isn't the
> answer.
> Is there a way I can turn CAS back on from code?
>
> TIA.
>
> --
> Kevin Westhead
>
>

"Kevin Westhead" <kevinw@NOSPAM.i2DOTcoDOTuk> wrote in message
news:%2327yLaKoEHA.2684@TK2MSFTNGP11.phx.gbl...
> Thanks for the helpful response.
>
> Now that I know I'm seeing expected behaviour I can start figuring out how
> to arrange my tests, which will probably be something along the lines of
> one
> of your suggestions.
>
> Out of curiosity, do you know why the SecurityEnabled property is only
> settable one way? The documentation sort of hints at it with
> "SecurityEnabled provides a way for administrators to disable code access
> security." although IMHO the resulting behaviour is unintuitive: making
> the
> property read-only and providing a DisableSecurity method would have made
> the usage clearer even if the reasoning behind it was still vague.
>
> --
> Kevin Westhead
>
> "Nicole Calinoiu" <ngcalinoiu REMOVETHIS AT gmail DOT com> wrote in
> message
> news:u3Sq$5JoEHA.3224@tk2msftngp13.phx.gbl...
>> Unfortunately, weird as it may seem, it can't be turned back on for the
>> current process. The simplest workaround is to name the various test
>> classes and methods so that the CAS-enabled tests run prior to disabling
>> CAS. (IME so far, they are run in alphabetical order.) Of course, if
>> you
>> take this approach, you should end the NUnit process between each test
> run.
>>
>> Another option would be to split your CAS-enabled and CAS-disabled tests
>> into separate test assemblies. This is my own preferred approach. As
> with
>> the previous approach, a new instance of NUnit should be launched once
>> any
>> disabled-CAS test suite has been run.
>>
>> Yet another option is to launch the individual tests on separate
> processes.
>> AFAIK, this is not a terribly convenient approach in any of the existing
>> unit testing frameworks for .NET. In addition, if you actually need to
>> persist the setting (as opposed to simply disabling within any given
>> process), elevated user privileges may be required.
>
>

"Nicole Calinoiu" <ngcalinoiu REMOVETHIS AT gmail DOT com> wrote in message
news:u3Sq$5JoEHA.3224@tk2msftngp13.phx.gbl...
> Unfortunately, weird as it may seem, it can't be turned back on for the
> current process. The simplest workaround is to name the various test
> classes and methods so that the CAS-enabled tests run prior to disabling
> CAS. (IME so far, they are run in alphabetical order.) Of course, if you
> take this approach, you should end the NUnit process between each test
run.
>
> Another option would be to split your CAS-enabled and CAS-disabled tests
> into separate test assemblies. This is my own preferred approach. As
with
> the previous approach, a new instance of NUnit should be launched once any
> disabled-CAS test suite has been run.
>
> Yet another option is to launch the individual tests on separate
processes.
> AFAIK, this is not a terribly convenient approach in any of the existing
> unit testing frameworks for .NET. In addition, if you actually need to
> persist the setting (as opposed to simply disabling within any given
> process), elevated user privileges may be required.