背景: "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を直接入力してチームに回答があることを確認しました。
これはNuGet 2.1で導入された回帰/バグです。問題を修正しており、今月は2.2で修正される予定です。 – Jay