SetPrincipalPolicy in Visual Studio Unit Test

SetPrincipalPolicy in Visual Studio Unit Test by dfbaskin

Closed

as By Design Help for as By Design

Type:	Bug
ID:	372793
Opened:	10/3/2008 12:45:51 PM
Access Restriction:	Public

Workaround(s)

view

User(s) can reproduce this bug

The following always fails in my Visual Studio (2008 SP1) unit tests:

[TestClass]
public static class TestInfo
{
[AssemblyInitialize]
public static void InitializeTesting( TestContext testContext )
{
AppDomain.CurrentDomain.SetPrincipalPolicy(
System.Security.Principal.PrincipalPolicy.WindowsPrincipal );
Assert.IsInstanceOfType( System.Threading.Thread.CurrentPrincipal,
typeof( System.Security.Principal.WindowsPrincipal ) );
}
}

According to the documentation at
http://msdn.microsoft.com/en-us/library/system.appdomain.setprincipalpolicy.aspx:

----------------------------
Setting this value will only be effective if you set it before using the
Thread.CurrentPrincipal property. For example, if you set
Thread.CurrentPrincipal to a given principal (for example, a generic
principal) and then use the SetPrincipalPolicy method to set the
PrincipalPolicy to WindowsPrincipal, the current principal will remain the
generic principal.
----------------------------

So it sounds like somewhere the test manager environment is accessing the
Thread.CurrentPrincipal and thus preventing unit tests from modifying the
Principal.

Details (expand)

English

Visual Studio 2008 Service Pack 1

Windows Vista

English

Create a unit test and include the following class:

[TestClass]
public static class TestInfo
{
[AssemblyInitialize]
public static void InitializeTesting( TestContext testContext )
{
AppDomain.CurrentDomain.SetPrincipalPolicy(
System.Security.Principal.PrincipalPolicy.WindowsPrincipal );
Assert.IsInstanceOfType( System.Threading.Thread.CurrentPrincipal,
typeof( System.Security.Principal.WindowsPrincipal ) );
}
}

Assert always fails.

Assert should not fail.

0 attachments

Posted by Microsoft on 10/6/2008 at 12:37 AM

We were able to reproduce the issue you are seeing. We are escalating this bug to the product unit who works on that specific feature area. The product team will review this issue and make a decision on whether they will fix it or not for the next release

Posted by Microsoft on 2/26/2009 at 2:29 PM

Hi,

This is by design. We noticed this when doing testing of the fix for SP1 and made a trade off. The tradeoff is a performance hit that we would take each time we invoke a method in the test assembly verses using a simple workaround. The workaround is to explicitly set the “System.Threading.Thread.CurrentPrincipal”.

The following snippet from the MSDN documentation on the “AppDomain.SetPrincipalPolicy()” method explains why we see this behavior:

Setting this value will only be effective if you set it before using the Thread.CurrentPrincipal property.

We use the Thread.CurrentPrincipal policy prior to invoking any test method to make a backup of its value. We do this so we can restore it to the original policy after the test finishes executing. This was done to solve the issues with custom principals being serialized back into the main AppDomain and failing to deseralize.

Thanks
Visual Studio Product Team