System.InvalidProgramException在Microsoft安全更新MS13-004之后在MSTest中執行單元測試時

Question

在2013年1月8日應用Microsoft安全更新http://technet.microsoft.com/en-us/security/bulletin/ms13-004后，我們已經開始在我們的構建服務器和本地的CI構建中遇到故障在我們的開發盒上運行測試。

我們得到一個System.InvalidProgramException：公共語言運行時檢測到一個無效的程序 。

這僅在使用使用Castle Windsor DynamicProxy的MSTest運行測試時才會發生，盡管我不相信DynamicProxy在這里有問題。

下面將生成一個生成異常的示例代碼。

    [TestMethod]
    public void ShouldBeAbleToGenerateADynamicProxyForAnObject()
    {
        var container = new WindsorContainer();

        container.Register(Component.For<TestInterceptor>());

        container.Register(Component.For<ISomething>()
                               .Instance(new TestDependency("Called from test framework."))
                               .LifeStyle.Transient);

        container.Register(Component.For<IService>()
                               .ImplementedBy<TestService>()
                               .Interceptors(InterceptorReference.ForType<TestInterceptor>())
                               .Anywhere
                               .LifeStyle.Transient);

        var service = container.Resolve<IService>();
        Assert.AreEqual("Called from test framework.", service.MethodNumberOne());
    }    

這會生成一個堆棧跟蹤，最終會在DynamicProxy中調用MixinData構造函數時拋出異常：

Castle.DynamicProxy.MixinData..ctor（IEnumerable`1 mixinInstances）Castle.DynamicProxy.ProxyGenerationOptions.Initialize（）Castle.DynamicProxy.Generators.InterfaceProxyWithTargetGenerator.GenerateCode（Type proxyTargetType，Type [] interfaces，ProxyGenerationOptions options）Castle.DynamicProxy.DefaultProxyBuilder。 CreateInterfaceProxyTypeWithTarget（Type interfaceToProxy，Type [] additionalInterfacesToProxy，Type targetType，ProxyGenerationOptions options）Castle.DynamicProxy.ProxyGenerator.CreateInterfaceProxyTypeWithTarget（Type interfaceToProxy，Type [] additionalInterfacesToProxy，Type targetType，ProxyGenerationOptions options）Castle.DynamicProxy.ProxyGenerator.CreateInterfaceProxyWithTarget（Type interfaceToProxy，Type [] additionalInterfacesToProxy，Object target，ProxyGenerationOptions選項，IInterceptor []攔截器）Castle.Windsor.Proxy.DefaultProxyFactory.Create（IKernel kernel，Object target，ComponentModel model，CreationContext context，Object [] constructorArguments）Castle.M icroKernel.ComponentActivator.DefaultComponentActivator.CreateInstance（CreationContext context，ConstructorCandidate constructor，Object [] arguments）Castle.MicroKernel.ComponentActivator.DefaultComponentActivator.CreateInstance（CreationContext context，ConstructorCandidate constructor，Object [] arguments）Castle.MicroKernel.ComponentActivator.DefaultComponentActivator.Instantiate（ CreationContext context）Castle.MicroKernel.ComponentActivator.DefaultComponentActivator.InternalCreate（CreationContext context）Castle.MicroKernel.ComponentActivator.AbstractComponentActivator.Create（CreationContext context，Burden burden）Castle.MicroKernel.Lifestyle.AbstractLifestyleManager.CreateInstance（CreationContext context，Boolean trackedExternally）Castle。 MicroKernel.Lifestyle.AbstractLifestyleManager.Resolve（CreationContext context，IReleasePolicy releasePolicy）Castle.MicroKernel.Handlers.DefaultHandler.ResolveCore（CreationContext context，Boolean requiresDecommission，Boolean instanceRequired，B urden＆burden）Castle.MicroKernel.Handlers.DefaultHandler.Resolve（CreationContext context，Boolean instanceRequired）Castle.MicroKernel.Handlers.AbstractHandler.Resolve（CreationContext context）Castle.MicroKernel.DefaultKernel.ResolveComponent（IHandler handler，Type service，IDictionary additionalArguments，IReleasePolicy策略）Castle.MicroKernel.DefaultKernel.Castle.MicroKernel.IKernelInternal.Resolve（類型服務，IDictionary參數，IReleasePolicy策略）Castle.MicroKernel.DefaultKernel.Resolve（類型服務，IDictionary參數）Castle.Windsor.WindsorContainer.ResolveT ShouldBeAbleToGenerateADynamicProxyForAnObject（）in TestCastleWindsorDynamicProxy.cs：第34行

我的第一個想法是DynamicProxy在創建代理時在安全更新后實際上生成了無效的IL，但據我所知，情況並非如此，因為它沒有那么遠。 我反編譯了Castle並使用調試器，我看到異常是按照堆棧跟蹤拋出的，當通過如下調用從ProxyGenerationOptions類調用MixinData構造函數時（ 注意：在上面的代碼示例中，this.mixins將是null，但這是在被調用的構造函數的代碼中預期和正確處理的 ）：

this.mixinData = new Castle.DynamicProxy.MixinData(this.mixins);

在MSTest運行器之外，一切都按預期工作，我們的應用程序繼續運行，當使用MSTest在xUnit或甚至TestDriven.NET中運行單元測試時，它們不會生成異常。 我們只看到此行為從Visual Studio運行測試或使用TFS和我們的MSBuild腳本進行自動構建。

在我們向微軟提出支持票之前，我想我們會問其他人是否經歷過類似的事情，或者對可能導致我們問題的事情有任何想法？

編輯：今天早上經過一些新的事情后，我們發現這實際上似乎與我們正在使用的Castle NuGet包有關。 當我們使用最新的NuGet包引用Castle時，我們最終得到了針對.NET Client Profile 4編譯的Castle.Core程序集的引用。這個引用是上面例外的原因（為什么？我還不完全確定）。 更改對為.NET 3.5編譯的版本的引用可確保測試在所有方案中按預期傳遞。

編輯：在進行了一些挖掘之后，似乎確實存在一個鏈接問題（這讓我們有理由回到微軟並看看他們要說些什么） Common Language Runtime在單元測試中檢測到無效的程序錯誤

Answer 1

我剛剛在我的同事計算機上修復了相同的錯誤，卸載了針對.net的micrsoft安全補丁kb2742595。 我想在安全設置中修復了一些問題，並且MSTest運行器無法處理新設置。 我們沒有安裝Castle.Core。

Answer 2

嘗試運行使用TypeMock的測試時，我遇到了類似的錯誤。 為了解決這個問題，我在Visual Studio中打開了我的解決方案並選擇了Test - Edit Test Settings 。 在“ 測試設置”對話框中，我選擇了“ 主機”並將其切換為在64位計算機上以64位進程運行測試 。

如果這有幫助，請告訴我。 如果這與您的錯誤無關，請告訴我，我將刪除我的答案。