从ASP.NET Core项目引用.NET 3.5 DLL项目

问题描述：

我有一个在.NET 3.5下编译的代表POCO数据模型的DLL。客户端应用程序仅限于.NET 3.5，并且DLL必须由客户端和服务器共享，因此不能重新编译该DLL。从ASP.NET Core项目引用.NET 3.5 DLL项目

我试图将服务器REST API重写为ASP.NET Core MVC项目（使用VS2015下的1.0版本和预览版本2工具）。我试图更新与所谓的“bin语法”的project.json如下图所示，但包恢复日志显示了一堆错误，如：

error: Package Microsoft.NETCore.App 1.0.0 is not compatible with net35 (.NETFramework,Version=v3.5). Package Microsoft.NETCore.App 1.0.0 supports: netcoreapp1.0 (.NETCoreApp,Version=v1.0)

"frameworks": { 
"netcoreapp1.0": { 
    "imports": [ "dotnet5.6", "portable-net45+win8" ] 
}, 
"net35": { 
    "bin": { "assembly": "c:\\source\\externaldllsdebug\\datadef.dll" } 
}

我也尝试设立的NuGet打包在DLL文件夹中，然后使该文件夹成为新的nuget源。它打开包很好，但试图导入DLL时失败。

我会尝试瞄准net451 +，并保持我的手指交叉:) – Pawel

答

我不认为你目前正在尝试做什么。

另一种解决办法是重构产生共享的DLL产生，这将是既.NET 3.5和netcoreapp1.0兼容的库项目：

"frameworks": { 
    "net35": { }, 
    "netstandard1.1": { 
     "dependencies": { 
      "NETStandard.Library": "1.6.0" 
     } 
    } 
}

这样，你就可以产生一个DLL，仍然在你的.NET 3.5项目中工作，也可以安装在你的ASP.NET Core项目中，没有任何问题或黑客。

正如你可能知道的，这会产生两个DLL。正如你注意到的那样，虽然比维护两个项目更容易，但这并不是我想要的，但我很欣赏这个建议。我想如果我想追求NuGet包装角度，这是正确的方法。 – McGuireV10

@ McGuireV10是的，它确实产生了两个DLL。但是如果你通过NuGet打包，只有一个将被安装在项目中。 –

我会给你答案的答案。经过额外的调查发现，这个DLL并不像我以前所认为的那样简单，所以如果没有一些其他的依赖声明（与3.5版的mscorlib相比），它不会与Core兼容，所以NuGet体操是不可避免的。 – McGuireV10

从ASP.NET Core项目引用.NET 3.5 DLL项目

相关推荐