问题：B 类是 A 类的子类。RIA 服务返回对象 B 的列表。A 类和 B 类都必须在服务器端定义。它们可以很好地序列化，我可以在主客户端项目中使用它们。
我有另外两个库，组织为客户端库。一种用于自定义控件，另一种用于在自定义控件和实际客户端项目之间共享的类。
我需要可以从 Classes 库客户端访问 Class A（以便自定义控件可以访问它）。我怎样才能做到这一点？
我已经这样做了：
http://msdn.microsoft.com/en-us/library/ee707369%28v=vs.91%29.aspx
但是 *.shared.cs 约定除了在服务器中更新 ClassA.cs 之外，除了实际的客户端库访问 A 类之外，没有提供库访问权限。第二种方法（添加为链接）确实做了我想要做的事情项目不会导致客户端版本更新，因此每次更改两个类文件时都必须更新它们，这是不可接受的。
编辑：多次尝试后添加为链接效果很好。
在 Visual Studio 中（至少是 2010 年——不知道添加该功能的确切时间），您可以将现有项目作为“链接”添加到项目中，这意味着源文件在项目之间共享。只有一个版本的源文件存在。
简单的！
现在，对共享源文件的任何更改都会反映在这两个地方。当然，缺点是开发人员没有得到任何迹象表明对共享源文件的更改可能会产生比她可能意识到的更广泛的影响。
另一种选择是创建一个hard link两个文件名引用同一个文件（Unix 术语中的“inode”）。在命令行上，只需念出魔法咒语：
fsutil hardlink create <new-filename> <existing-filename>
就像是：
fsutil hardlink create c:\foo\bar\some-project\bazbat.cs c:\foo\bar\another-project\bazbat.cs
限制是两个名称必须在同一个卷上。
当然，这有可能混淆您的源代码控制系统。我敢打赌，TFS 没有考虑文件系统不一定是树结构并且同一个文件可能存在于多个目录中的可能性。
硬链接文件可以按任何顺序删除：当最后一个链接被删除时，文件将不复存在。
第三个选项，当然，可能是“最佳实践”——讨厌这个词！— 是将分片类分解为一个独立的程序集，该程序集部署到客户端和服务器。如果想限制浮动的程序集数量，构建后，您可以使用ilmerge来合并程序集：
想一想，您也没有理由不能将共享程序集嵌入为按需加载（甚至在启动时）的嵌入式资源。这甚至可能比使用ilmerge. 以下是如何做到这一点：