具有shared.vb扩展名的部分实体类不与“其他”关联；使用 RIA 服务的客户端中的部分类
我已经使用分部类中的计算属性扩展了 Entity Framework 4 实体类。该成员在通过 WCF RIA 服务向其公开实体的客户端上不可用。
使用 C# 时此问题的解决方案似乎是将部分类文件的扩展名从 .cs 更改为 .shared.cs。我用我的 VB.Net 解决方案（.vb 到 .shared.vb）尝试了这一点，并得到了一长串错误。我相信发生的事情是分部类失去了与客户端上的实体的关联 - 它继承自对象而不是EntityObject。
我最好的猜测是，这与 VB.Net 处理名称空间的方式有关。每个项目都有一个“根命名空间”，它被添加到代码文件中定义的任何内容之前。 C# 有一个“默认命名空间”，它是默认情况下通过文件中的命名空间语句放置新类型的命名空间。
分部类可能会在其前面添加客户端命名空间，这会将其放入与服务器上关联的实体不同的命名空间中。
是否有任何方法可以通过 WCF RIA 服务和 VB.Net 在客户端上使用这些扩展来扩展实体？
I have extended an Entity Framework 4 entity class with a calculated property in a partial class. This member is not available on the client to which the entities are exposed via WCF RIA Services.
The solution to this problem when using C# appears to be changing the extension of the partial class file from .cs to .shared.cs. I tried this with my VB.Net solution (.vb to .shared.vb) and got a long list of errors. I believe what happened is that the partial class lost its association with the entity on the client - it inherited from object rather than EntityObject.
My best guess is that this is related to the way that VB.Net handles namespaces. Each project has a 'Root Namespace' which is prepended to anything that is defined within a code file. C# has a 'Default Namespace' which is the namespace into which new types are placed by default - via a namespace statement within the file.
The partial class is probably having the client namespace prepended to it which puts it into a different namespace than the entity with which it is associated on the server.
Is there any means of extending an entity in such a way that those extensions are available on the client via WCF RIA Services and VB.Net?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
此问题有一个解决方法，该解决方法取决于生成实体类的 T4 模板中的某些逻辑。
如果可用，则在项目级别定义的根命名空间内生成实体，否则在 EDMX 文件内指定的命名空间内生成实体（CodeGenerationTools.VsNamespaceSuggestion 方法似乎可以处理此问题）。
在根命名空间可用的情况下，手动编码的部分类需要位于该命名空间中以匹配生成的部分类 - 它们在文件级别没有命名空间声明。当这些文件“共享”给客户端（通过共享的 .vb 扩展名）时，它们最终位于客户端的根命名空间中，而生成的实体最终位于由客户端的根命名空间加上服务器根命名空间组成的命名空间中。
从服务器项目中删除根命名空间，然后在手动编码的部分类中显式声明 EDMX 的命名空间会导致这些共享文件和生成的实体最终位于客户端上的同一命名空间中（客户端的根命名空间加上 EDMX 的命名空间） 。
注意：“ADO.Net EntityObject Generator”模板（使用 EDMX 设计器中的“添加代码生成项...”上下文菜单项添加）的行为似乎与设计器的本机模板不同。即使我在项目级别清除了根命名空间，它也不会在我的测试中生成命名空间声明。我不确定这是为什么。
There is a workaround for this issue that depends on some logic within the T4 templates that generate the entity classes.
The entities are generated within the Root Namespace defined at the project level if one is available, and within the Namespace spedified within the EDMX file otherwise (the CodeGenerationTools.VsNamespaceSuggestion method seems to handle this).
Where a Root Namespace is available, the hand-coded partial classes need to be in that namespace to match the generated ones - they have no namespace declaration at the file level. When these these files are 'shared' to the client (via the shared.vb extension), they end up in the client's Root Namespace whereas the generated entities end up in a namespace that consists of the client's Root Namespace plus the servers Root Namespace.
Removing the Root Namespace from the server project and then explicitly declaring the EDMX's namespace within the handcoded, partial classes results in both these shared files and the generated entitites ending up in the same namespace on the client (the client's Root Namespace plus the EDMX's namespace).
Note: The 'ADO.Net EntityObject Generator' template (added using the 'Add Code Generated Item...' context menu item in the EDMX designer) seems to behave differently than the designer's native one. It was not generating a namespace declaration in my tests even if I cleared the Root Namespace at the project level. I am not sure of the reason for this.