我有一个 SenseNet 存储库，它是从 SenseNet 6.5.4 创建的，它有 40 多个自定义内容类型 (CTD)，每个都有自己的内容处理程序。这个存储库已经为一个客户运行了一年多，里面有很多数据。
我想为这个客户端创建一个 ASP.NET MVC 应用程序，现在使用新的 SenseNet 7.0（测试版）框架看起来非常简单。但是，我的内容存储库来自早期版本的 SenseNet，这意味着我的处理程序依赖于以前的 SenseNet 库，这些库可能与新的不兼容。
这甚至可能吗？如果可以，考虑到该客户端将在某个时候升级到 SN 7.0，是否是一个好主意？
是的，这是可能的，但工作量很大，因为您必须创建链接到新 SN 7.0 库的内容处理程序。对于现有的自定义内容处理程序，这是一个简单的复制/粘贴，在这里和那里进行一些编辑。只需将处理程序的 C# 代码添加到新的 MVC 项目并确保它可以编译并且没有错误。
这是最容易的部分！现在您必须为存储库中引用 6.5 库的所有数据创建处理程序。对于我的项目，我必须移植 11 个内容处理程序（来自 SN 安装），以及另外 30 多个支持类。
在启动移植之前从存储库中删除所有未使用的内容是个好主意，因为 MVC 应用程序在尝试从存储库中提取内容并且找不到 SN 7.0 处理程序时会引发异常。Blog, Wiki,等东西Journal如果不使用可以删除。
编辑：为了解决 Miklos 的评论，应该说明这个问题来自一个评估 SN 7.0 升级路径的实验项目，而不是推荐的升级方法。啊，开源软件的美！
我打算通过从 6.5 存储库中将数据导出为 XML，然后将其导入 7.0 存储库来尝试升级自定义内容。只要没有任何内容源自 6.5 中但不是 7.0 中的任何奇异内容类型 (CTD)，这应该是可行且直接的。
最后，我不同意最好的做法是在 6.5 框架中为 MVC 应用程序使用 REST API 的评论。我已经这样做了好几次了，SN 6.5 就是不容易支持 MVC。所有调用都是客户端 OData Ajax，调试很痛苦，没有服务器端 C# API，每次需要查询存储库时都编写 Ajax 调用是荒谬的。是的，我知道您可以从服务器创建 OData 调用，但这与具有良好智能感知的干净简单的服务器端 API 相去甚远。这根本不值得奋斗。使用 SN 7.0，您可以使用 NuGet 包在大约 10 分钟内运行 MVC 站点，并提供服务器端和客户端支持。只是没有可比性。