我无法生成微软假货组件时说类库引用了PCL（便携式类库）下的Visual Studio 2013打靶的.Net 4.5和Silverlight 5。

类库（.NET 4.5）

这只能发生如果类库（.NET 4.5）：

在声明一个类从派生型，可在System.dll中V4.0.0.0和v2.0.5.0 既可以找到 在声明其他类型从一个在PCL库，而这又源于在System.dll中v.2.0.5.0 声明的类型声明派生

无论是.NET 4.5类库和PCL库编译就好了。不过，我有一个单元测试项目（同时.NET 4.5），这需要生成假货在.NET 4.5类库。试图生成假货失败，给了我下面的错误。

 错误：系统，版本= 2.0.5.0，文化=中性公钥= 7cec85d7bea7798e，重定目标=是组装Repro.dll未能正确加载无法解析组件。你是缺少程序集引用？
 

如果添加引用System.dll中v2.0.5.0在我的单元测试项目失败，因为一提到系统V4.0.0.0已经存在于项目的组成部分。

我也尝试添加一个app.config到我的单元测试项目并形成一个集绑定重定向system.dll中，但没有奏效。我怀疑集绑定重定向对正版正货代零的效果。

再现的问题是容易的。

创建一个可移植类库命名为Repro.Portable'里面有一个单一的接口：

 使用System.ComponentModel;

命名空间Repro.Portable
{
   公共接口IPortableEntity：INotifyPropertyChanged的
   {
   }
}
 

然后创建一个.NET 4.5类库命名为摄制它引用了便携式类库，并声明如下两个接口。

 使用Repro.Portable;

命名空间摄制
{
  公共接口ISpecializedEntity：IPortableEntity
  {
  }
}
 

和

 使用System.ComponentModel;

命名空间摄制
{
  公共接口IOtherInterface：INotifyPropertyChanged的
  {
  }
}
 

最后，创建单元测试项目引用这两个摄制和Repro.Portable组件。编译在这一点上一定会成功。然而，试图生成微软假货的摄制组件将失败。

由于所有这似乎是一个pretty的合法的事情，我在想，如果我冲进了微软正版正货生成了一个bug，或者如果有解决方法。

有没有什么办法让假货产生的工作还是我坚持使用不同的模拟框架遇到这种特定情况下，当？

解决方案

微软提供了一个解决方法的问题。

  

要得到过去的问题，添加XML二进制大对象中包含在你的.fakes文件。

 ＆LT;编译＆GT;
   ＆lt;参考路径=C：\ Program Files文件（x86）的\参考大会\微软\框架\ .NETPortable \ V4.0 \档案\ Profile158 \ System.dll中全名=系统，版本= 2.0.5.0，文化=中性公钥= 7cec85d7bea7798e/＆GT;
＆LT; /编译＆GT;
 

它的工作建立在当地的时候，但是我还没有测试，如果这是使用TFS在线版本的服务器或没有时，一个可行的解决办法。

I am unable to generate the Microsoft Fakes assembly for a class library (.NET 4.5) when said class library references a PCL (Portable Class Library) targetting .Net 4.5 and Silverlight 5 under Visual Studio 2013.

This only occurs if the class library (.NET 4.5):

Declares a type deriving from a type which can both be found in System.dll v4.0.0.0 and v2.0.5.0 Declares another type deriving from one declared in the PCL library, which in turn derives from a type declared in System.dll v.2.0.5.0

Both the .NET 4.5 class library and the PCL library compiles just fine. However I have a Unit Test project (also .NET 4.5) which needs to generate Fakes for the .NET 4.5 class library. Trying to generate the fakes fails and gives me the following error.

error : assembly Repro.dll failed to load properly Could not resolve assembly 'System, Version=2.0.5.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e, Retargetable=Yes'. Are you missing an assembly reference?

Trying to add a reference to System.Dll v2.0.5.0 in my Unit Test project fails since a reference to the component 'System' v4.0.0.0 already exists in the project.

I also tried adding an App.Config to my Unit Test project and defining an assembly binding redirection for System.Dll, but it did not work. I suspect assembly binding redirection has zero effect on Fakes generation.

Reproducing the issue is easy.

Create a Portable Class Library named 'Repro.Portable' which has a single interface:

using System.ComponentModel; 

namespace Repro.Portable
{
   public interface IPortableEntity : INotifyPropertyChanged
   {
   }
}

Then create a .NET 4.5 Class Library named 'Repro' which references the Portable Class Library and declare the following two interfaces.

using Repro.Portable;

namespace Repro
{
  public interface ISpecializedEntity : IPortableEntity
  {
  }
}

and...

using System.ComponentModel;

namespace Repro
{
  public interface IOtherInterface : INotifyPropertyChanged
  {
  }
}

Finally, create a Unit Test Project referencing both the Repro and Repro.Portable assemblies. Compiling at this point will succeed. However, trying to generate the Microsoft Fakes for the Repro assembly will fail.

As all of this seems like a pretty legitimate thing to do, I am left wondering if I ran into a bug in the Microsoft Fakes generator, or if a workaround exists.

Is there any way to make the Fakes generation work or am I stuck using a different Mocking framework when encountering this specific scenario ?

解决方案

Microsoft provided a workaround for the bug.

To get past the issue, add an XML blob like below in your .fakes file.

<Compilation>
   <Reference Path="C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETPortable\v4.0\Profile\Profile158\System.dll" FullName="System, Version=2.0.5.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e"/>
</Compilation>

It does work when building locally, however I have yet to test if this is a viable workaround when using TFS online build server or not.