将 SQL CLR 项目从 VS2008 迁移到 VS2010 - 部署失败
我在 VS2008 中有一个 SQL CLR 项目的解决方案。解决方案/项目已转换为 VS2010，现在部署不再有效。 我收到以下类型的错误：
开始将程序集 MyProjectDatabaseCode.dll 部署到服务器 DEVPN-004：MyProject 如果部署的 SQL CLR 项目是为与 SQL Server 目标实例不兼容的 .NET Framework 版本构建的，则可能会出现以下错误：“部署错误 SQL01268：程序集创建程序集失败，因为程序集验证失败”。要解决此问题，请打开项目的属性，然后更改 .NET Framework 版本。 C:\inetpub\wwwroot\VS2010_MyProjectSolution\DatabaseCode\bin\Release\MyProjectDatabaseCode.dll ：部署错误：计划验证遇到错误；部署无法继续。 C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\TeamData\Microsoft.Data.Schema.SqlClr.targets(96,5)：部署错误 TSD00561：此部署在执行过程中可能会遇到错误，因为更改为[dbo].[Column1] 被 [dbo].[Table1].[Column1] 在目标数据库中的依赖项阻止。
我已经验证，该项目是针对 .NET 3.5 的。我们有应该运行的 predeployscript.sql 和 postdeployscript.sql 文件。看起来它们不是由 VS2010 运行的。可能是什么原因导致了这个问题？
I have a solution with a SQL CLR project in VS2008. The solution / project was converted to VS2010 and now the deploy no longer works.
I get the following type of erros:
Beginning deployment of assembly MyProjectDatabaseCode.dll to server DEVPN-004 : MyProject
The following error might appear if you deploy a SQL CLR project that was built for a version of the .NET Framework that is incompatible with the target instance of SQL Server: "Deploy error SQL01268: CREATE ASSEMBLY for assembly failed because assembly failed verification". To resolve this issue, open the properties for the project, and change the .NET Framework version.
C:\inetpub\wwwroot\VS2010_MyProjectSolution\DatabaseCode\bin\Release\MyProjectDatabaseCode.dll : Deploy error : Plan verification encountered errors; deployment cannot continue.
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\TeamData\Microsoft.Data.Schema.SqlClr.targets(96,5): Deploy error TSD00561: This deployment may encounter errors during execution because changes to [dbo].[Column1] are blocked by [dbo].[Table1].[Column1]'s dependency in the target database.
I verified and the project is targeted against .NET 3.5. We have predeployscript.sql and postdeployscript.sql files that are supposed to be run. It appears like they are not being run by VS2010. What could be causing the issue?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我们最终联系了 Microsoft，他们将我们的问题重现为已知错误。他们提供了一种解决方法，将程序集重新定位到 .NET 2.0，但这在我们的场景中也不起作用。
似乎在修复之前唯一的方法是在 2010 年创建一个全新的 SQL CLR 项目并手动将所有文件添加到其中。
We ended up contacting Microsoft and they reproduced our issue as a known bug. They offered a workaround by retargeting the assembly to .NET 2.0, but that didn't work in our scenario either.
It seems that the only way forward until the fix is to create a brand new SQL CLR project in 2010 and add all the files to it by hand.
我建议使用 Reflector 在构建输出中查看程序集目录。如果您看到 2 个对 mscorlib 的引用，则说明对 4.0 框架的虚拟引用已添加到项目中。如果您看到此问题，您可以通过手动编辑项目文件来摆脱 4.0 引用。在 XML 编辑器中打开项目，然后查找以下行：
将
ToolsVersion="2.0" 更改为ToolsVersion="4.0"这帮助我解决了类似的升级问题，但您的里程可能会有所不同。如果您没有看到幻影 mscorlib 参考，则可能遇到另一个问题。
I'd recommend using Reflector to take a look at your assembly in the build output directory. If you see 2 references to mscorlib, then what has happened is that a phantom reference to the 4.0 framework has been added to the project. If you see this problem, you may be able to get rid of the 4.0 reference by hand editing your project file. Open the project in an XML editor, and look for the following line:
Change
ToolsVersion="2.0" toToolsVersion="4.0"This helped me with a similar upgrade problem, but your mileage may vary. If you don't see the phantom mscorlib reference, you probably have another issue.
当我重命名某些对象或目标数据库以某种方式不同步时，即某些对象未删除并且部署试图重新创建它们时，我一直看到这个问题。
我设法通过从 MS Server Management Studio 运行清理脚本（删除对象/程序集）并验证数据库中没有保留旧对象来修复它。
这是一次尝试/错误的体验，但您可以首先尝试部署到另一个服务器/数据库，如果成功，则目标数据库中可能有一些垃圾，这就是我得出的结论，因为我能够部署到另一个数据库。
I've seem this problem consistently when I renamed some objects or somehow the target database got out of sync, that is, some objects were not dropped and Deploy was trying to recreate them.
I managed to fix it by running a cleanup script (drop objects/assemblies) from MS Server Management Studio and verifying that no old objects remained in the Database.
It's a try/error experience but you can try first to deploy to another server/database and if it succeeds, chances are you have some garbage in the target database, that's how I came to the conclusion for I was able to deploy to another database.