AllowPartiallyTrustedCallersAttribute and .NET 4

[tillig]

I know that .NET 4 introduces a new security model but, to be honest,
I'm not sure how it affects or changes the need/use of
AllowPartiallyTrustedCallersAttribute.

The reason I bring it up is that I have reasonably common conflicts
when testing with coverage in .NET 4 against assemblies that have
APTCA on them. I blogged about it here:
http://www.paraesthesia.com/archive/2010/06/04/verificationexception-during-coverage-check-your-security-attributes.aspx

Basically, the problem is that assemblies that have APTCA on them
in .NET 4 seem to cause an exception when consuming those assemblies
and running unit tests involving code coverage. (The tests run fine
WITHOUT coverage, but when instrumented, problems occur.)

System.Security.VerificationException : Operation could destabilize
the runtime.

I've found that removing the APTCA from the assembly seems to fix the
issue, at least for the tests.

I'm working with the 2.3.1.530 .NET 4 versions of Autofac/Contrib and
I'm starting to get unit test issues in CI with them. Just
constructing one of the objects in the library (e.g., "new
ContainerBuilder()") causes it in seemingly random places.

I'm going to try building a local copy of the assemblies and test the
theory, but I didn't know if anyone else had seen the issue or not.

[tillig]

Finding this may be an issue primarily in TestDriven.NET. Running the
same build from the command line a couple of times (with coverage)
doesn't seem to yield the issue... though I swear it was doing it
before.

Anyway, still interested in knowing if anyone else has seen this, and
if APTCA makes sense in the new .NET 4 security model.

-T

On Oct 6, 9:21 am, tillig <travis.il...@gmail.com> wrote:
> I know that .NET 4 introduces a new security model but, to be honest,
> I'm not sure how it affects or changes the need/use of
> AllowPartiallyTrustedCallersAttribute.
>
> The reason I bring it up is that I have reasonably common conflicts
> when testing with coverage in .NET 4 against assemblies that have

> APTCA on them. I blogged about it here:http://www.paraesthesia.com/archive/2010/06/04/verificationexception-...

[tillig]

Verified that compiling a custom version that has APTCA removed allows
tests to pass in both TestDriven.NET and on the command line.

Based on this MSDN article...
http://msdn.microsoft.com/en-us/library/bb397858.aspx
...which says "For code that is developed for the .NET Framework 4,
always use level 2 transparency" I gather that APTCA is not something
that should be on .NET 4 assemblies.

And the information in this other blog entry where another person ran
into the same issue I'm having...
http://www.thebooleanfrog.com/post/MSTest-Code-Coverage-and-VerifyException.aspx
...it looks like .NET 4 should be using
[assembly: SecurityRules(SecurityRuleSet.Level2)] to indicate the new
security rules apply, and
[assembly: SecurityTransparent] to indicate that use of the assembly
should not cause an elevation in privilege and that partially trusted
callers can access it.

Of course, I tried using the SecurityRules and SecurityTransparent
attributes in a local build and still got the VerificationException,
so there's something to do with partial trust, coverage, and
TestDriven that just doesn't want to work. The only way it works is to
not put the attributes on at all.

[tillig]

Using [assembly: SecurityRules(SecurityRuleSet.Level1)] the way that
booleanfrog article did, coverage works in both TD.NET and command-
line build.

I gather that there's something to do with the .NET 4 assemblies
(e.g., AutofacContrib.Multitenant.dll) calling into .NET 2 runtime
assemblies (e.g., Castle.Core.dll).

Aaaaanyway, I don't know if I'm knowledgeable enough to say "this is
the solution," but it seems there is some opportunity here to fix this
up.

On Oct 6, 10:54 am, tillig <travis.il...@gmail.com> wrote:
> Verified that compiling a custom version that has APTCA removed allows
> tests to pass in both TestDriven.NET and on the command line.
>

> Based on this MSDN article...http://msdn.microsoft.com/en-us/library/bb397858.aspx

> ...which says "For code that is developed for the .NET Framework 4,
> always use level 2 transparency" I gather that APTCA is not something
> that should be on .NET 4 assemblies.
>
> And the information in this other blog entry where another person ran

> into the same issue I'm having...http://www.thebooleanfrog.com/post/MSTest-Code-Coverage-and-VerifyExc...

[tillig]

It also appears that you can put both
[SecurityRules(SecurityRuleSet.Level1)] and [APTCA] on the assembly at
the same time and things work... but, again, not sure if they somehow
conflict or something.

[tillig]

Added an issue for this in the tracker so it can be addressed as
prioritized. It'd be nice to make sure we're both behaving properly
security-wise AND work with coverage tools, etc.

-T

[Nicholas Blumhardt]

Thanks Travis

--
You received this message because you are subscribed to the Google Groups "Autofac" group.
To post to this group, send email to aut...@googlegroups.com.
To unsubscribe from this group, send email to autofac+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/autofac?hl=en.

[ddou...@gmail.com]

Was this issue resolved in the 2.5.2.380 release for .Net 4?  I'm running into this issue as well on my CI server (TeamCity) when executing coverage reporting on my NUnit tests around AutoFac registration verification.  We are currently using the AutoFac 2.4.5.724 assemblies...

[Wayne Hearn]

I'm having an issue that may be related.  I'm trying to use the DynamicProxy2 interceptors in a .Net 4.0 application and I'm getting this error:

Attempt by security transparent method 'AutofacContrib.DynamicProxy2.RegistrationExtensions..cctor()' to access security critical method 'Castle.DynamicProxy.ProxyGenerator..ctor()' failed.

Assembly 'AutofacContrib.DynamicProxy2, Version=2.4.5.724, Culture=neutral, PublicKeyToken=17863af14b0044da' is marked with the AllowPartiallyTrustedCallersAttribute, and uses the level 2 security transparency model. &nbsp;Level 2 transparency causes all methods in AllowPartiallyTrustedCallers assemblies to become security transparent by default, which may be the cause of this exception.

I tried adding the [assembly: SecurityRules(SecurityRuleSet.Level2)] attribute to my assembly but got the same result.  I'm guessing something has to change in the autofac or castle dlls?

Any ideas how to get this going?

Thanks,

[Nicholas Blumhardt]

Thanks for getting in touch - no, this is still not addressed. I've just bumped priority in the issue tracker up to 'high' with the intention that we'll get this into our next release.

--
You received this message because you are subscribed to the Google Groups "Autofac" group.

To view this discussion on the web visit https://groups.google.com/d/msg/autofac/-/xjnYmaEgeZ8J.