2012-10-10 21 views
5

背景: "A"と "B"という2つのアセンブリがあります。 「A」は「B」を参照しています。「A」は、nupkgにパッケージする必要がある追加のdll(Microsoft.Enterprise Library.DataおよびMicrosoft Enterprise Library.Common)も参照しています。NuGet dllのパッケージ化と参照

私のnupkgパッケージ"A"、 "B"と2つの "Microsoft Enterprise"アセンブリからのアセンブリ出力を含む必要があります。そのため、誰かが自分のパッケージをインストールすると、アセンブリ "A"への直接参照を提供し、 。しかし、直接自分のアプリが実行されますように、非参照DLLをパッケージ化する正しい方法は何ですか、参照されない

試み#1:?\のnet35フォルダ に必要なすべてのDLLののパッキングによると、element "この要素を省略すると、libフォルダのすべてのアセンブリを参照する通常の動作が適用されます。"この要素を使用すると、参照として指定されたアセンブリのみが含まれます。これは、 "ファイル"要素<file src=*.dll" target="lib\net35" />も使用している場合には当てはまりません。このような要素があれば、すべてのdllをパッケージにコピーします。このパッケージを実装するアセンブリでは、\ net35ディレクトリ内のすべてのアセンブリを参照できます。これは私がしたいことではありません。 "references"で指定されたアセンブリのみが実際に参照され、他のすべてがexploded \ packagesフォルダに残り、すべてのdllが同じディレクトリに配置されているため、アプリケーションが動作するという魔法が必要でした。たぶん私は、私が代わりにLIB用の\ net35の\コンテンツ\ libにに参照されていないアセンブリを配置する場合、これは中\ libフォルダを作成し、パッケージする際、コンテンツとして追加

試み#2は を投影する....間違いましたよ\ content \ lib dllをそのプロジェクトに直接ダンプします。それによって、ソースコントロールにチェックインされます。これは動作し、コンパイルして実行したいが、実際にはプロジェクトの\ libフォルダに格納したくない。

私は、プロジェクトが "A"への参照を取得し、同じ場所に配置されているが直接参照されていない他の必要なアセンブリに対して実行できるソリューションを探しています。試行#1が正しいパスだと思われますが、おそらくバグがありますか?

FYI、私はこのas a issue with NuGetを直接入力してチームに回答があることを確認しました。

答えて

3

これはNuget 2.1で導入されたバグだったと、後に正しく動作するようになりました、元の投稿に試み#1を使用して2012年12月に

をリリースしましたNugetバージョン2.2で修正されました。

0

"試行1"は実際には動作しないと思います。 「A」のみを参照する場合。パッケージをビルドすると、 "A"だけが(デフォルトで)出力ディレクトリにコピーされます。次に、アプリケーションを配布すると、「A」のみが存在し、エラーが発生します。

アプリケーションを実行するには、すべてのDLLへの参照が必要です(または参照先のDLLを出力ディレクトリに自動的にコピーする別のソリューションを用意してください)が、参照を指定しないと直接)。いくつかのDLLしかないので、すべてのDLLがlibフォルダから自動的に参照されるように、リファレンスセクションを省略するのが最善の方法です。

+0

これはNuGet 2.1で導入された回帰/バグです。問題を修正しており、今月は2.2で修正される予定です。 – Jay

関連する問題