2

私は、POCOデータモデルを表す.NET 3.5でコンパイルされたDLLを持っています。クライアントアプリケーションは.NET 3.5に限定されており、クライアントとサーバーの両方でDLLを共有する必要があるため、DLLの再コンパイルはオプションではありません。ASP.NETコアプロジェクトからの.NET 3.5 DLLの参照

サーバーのREST APIをASP.NET Core MVCプロジェクトとして書き直そうとしています(VS2015の1.0リリースとPreview 2ツールを使用しています)。私もnugetを設定しようとした

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" } 
} 

:ログのようなエラーの束を示し、以下のように私は、いわゆる「ビン構文」とproject.jsonを更新しようとしたが、パッケージには、復元しますパッケージをDLLフォルダーに入れ、フォルダーを新しいナゲットソースにします。パッケージを正常に開いたが、DLLをインポートしようとすると失敗した。

+0

私はnet451 +をターゲットにしようとしていて、私の指が交差していないようにしています:) – Pawel

答えて

1

あなたがしようとしていることは現在可能ではないと思います。

代替ソリューションは、.NET 3.5およびnetcoreapp1.0の両方と互換性があるでしょうライブラリーを作製するために共有DLLを作成するプロジェクトリファクタリングすることです:

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

をこのように、あなたはそのDLLを作り出すことができますまだ.NET 3.5プロジェクトで動作していましたが、ASP.NET Coreプロジェクトに問題やハッキングなしでインストールできるものもありました。

+0

おそらく分かるように、これは2つのDLLを生成します。 2つのプロジェクトを維持するよりも簡単ですが、これは私が望んでいたことではありませんが、提案に感謝します。私はNuGetパッケージアングルを追求したいなら、これが正しいアプローチだと思います。 – McGuireV10

+0

@ McGuireV10ええ、それは2つのDLLを生成します。しかし、NuGet経由でパッケージ化すれば、プロジェクトには1つしかインストールされません。 –

+1

私はあなたに答えのクレジットを与えます。私が信じていたようにDLLがバニラではないことが判明したので、NuGetの体操は避けられないように、いくつかの代替依存宣言(3.5のmscorlibと比較して)なしではCoreと互換性がありません。 – McGuireV10

関連する問題