locked
Pex 0.94: when exploring, causes TypeInitializer Exception -> "Operation could destabilize the runtime" RRS feed

  • Question

  • Using Pex 0.94, VS2010, Win7 64-bit

    The code under test uses the CuttingEdge.Conditions library (http://conditions.codeplex.com/ ) to test preconditions.  When the exploration causes the code under test to Throw an ArgumentNullException, CuttingEdge attempts to retrieve an error message from a resource file.  The call to the ResourceManager constructor (from a static class property initializer) fails with the TypeInitializationException shown below.  The inner exception says: "Operation could destabilize the runtime".

    The output of the exploration message:

    --- Description
    failing test: TypeInitializationException, The type initializer for 'CuttingEdge.Conditions.SR' threw an exception.
     
    rServiceInterceptor rServiceInterceptor;
    rServiceInterceptor =
      this.Constructor((Logger)null, (InterceptionFactory)null);

     
    [Test]
    [PexGeneratedBy(typeof(rServiceInterceptorTest))]
    [PexRaisedException(typeof(TypeInitializationException))]
    public void ConstructorThrowsTypeInitializationException414()
    {
        rServiceInterceptor rServiceInterceptor;
        rServiceInterceptor =
          this.Constructor((Logger)null, (InterceptionFactory)null);
    }


     
    --- Exception details
     
    System.TypeInitializationException: The type initializer for 'CuttingEdge.Conditions.SR' threw an exception.      at System.String CuttingEdge.Conditions.SR.GetStringInternal(System.String name, System.Object[] args) 
          at System.String CuttingEdge.Conditions.Throw.GetFormattedConditionMessage(CuttingEdge.Conditions.ConditionValidator`1<!!0> validator, System.String resourceKey, System.String conditionDescription, System.Object[] resourceFormatArguments) 
          at System.Void CuttingEdge.Conditions.Throw.ValueShouldNotBeNull(CuttingEdge.Conditions.ConditionValidator`1<!!0> validator, System.String conditionDescription) 
          at CuttingEdge.Conditions.ConditionValidator`1<!!0> CuttingEdge.Conditions.ValidatorExtensions.IsNotNull(CuttingEdge.Conditions.ConditionValidator`1<!!0> validator) 
        C:\Users\crudolphi\Documents\Visual Studio 2010\Projects\Spikes\Validation_Interception\EpcService\Infrastructure\ServiceInterception\rServiceInterceptor.cs(21): at System.Void r.DomainService.ProductCatalog.Infrastructure.ImageInfrastructure.ServiceInterception.rServiceInterceptor..ctor(r.DomainService.ProductCatalog.Infrastructure.ImageInfrastructure.Logging.Logger lgr, r.DomainService.ProductCatalog.Infrastructure.ImageInfrastructure.ServiceInterception.InterceptionFactory intFactory) 
        C:\Users\crudolphi\Documents\Visual Studio 2010\Projects\Spikes\Validation_Interception\EpcService\InterceptionAndCacheTests\ImageInfrastructure\ServiceInterception\rServiceInterceptorTest.cs(22): at r.DomainService.ProductCatalog.Infrastructure.ImageInfrastructure.ServiceInterception.rServiceInterceptor r.DomainService.ProductCatalog.Infrastructure.ImageInfrastructure.ServiceInterception.rServiceInterceptorTest.Constructor(r.DomainService.ProductCatalog.Infrastructure.ImageInfrastructure.Logging.Logger lgr, r.DomainService.ProductCatalog.Infrastructure.ImageInfrastructure.ServiceInterception.InterceptionFactory intFactory) 
    System.Security.VerificationException: Operation could destabilize the runtime.      at System.Void CuttingEdge.Conditions.SR..cctor() 
     
     

    The CuttingEdge code is referenced as a library.  The code under test and the Test project are compiled with Debug|AnyCPU.  Could this be a 32-/64-bitness problem?

    Any suggestions on how I can move forward?  Right now, using PEX is stalled until I can get around this issue.

    Thanks,

    Chris

    Friday, October 1, 2010 6:24 PM

Answers

  • Thanks for the repro. The issue is not related to Pex: It turns out that the assembly Conditions.CuttingEdge is blocked since it was probably copied from the web. You need to right click on the assembly, click on 'Unblock', build and run again.

    This issue is not uncommon, it would be nice to be smarter about detecting and send a more meaningful error the next time.


    Jonathan "Peli" de Halleux - Try Pex online at www.pexforfun.com!
    Saturday, October 2, 2010 2:14 PM

All replies

  • Is it possible to package a repro solution and send it to pex _ad_ microsoft dot com ?
    Jonathan "Peli" de Halleux - Try Pex online at www.pexforfun.com!
    Friday, October 1, 2010 8:23 PM
  • Thanks for the repro. The issue is not related to Pex: It turns out that the assembly Conditions.CuttingEdge is blocked since it was probably copied from the web. You need to right click on the assembly, click on 'Unblock', build and run again.

    This issue is not uncommon, it would be nice to be smarter about detecting and send a more meaningful error the next time.


    Jonathan "Peli" de Halleux - Try Pex online at www.pexforfun.com!
    Saturday, October 2, 2010 2:14 PM
  • Interesting.  As you suggest, by marking the downloaded .dll as 'Unblocked', the Pex explorations run to completion.

    As a follow-up question, just to further my own understanding: My code, which consumed this library, runs just fine without 'unblocking' the library .dll.  So it seems the .NET run-time was allowing that library to execute without being unblocked.  What goes on within Pex that requires the library to be unblocked?  Is it that one cannot reflect against a type that resides within a blocked assembly .dll?

    Chris

    Monday, October 4, 2010 1:08 PM