回答:
次のように、<Content>
使用<ContentWithTargetPath>
してターゲットパスを指定する代わりに、
<ItemGroup>
<ContentWithTargetPath Include="lib\some_file.dat">
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
<TargetPath>some_file.dat</TargetPath>
</ContentWithTargetPath>
<ItemGroup>
このエントリはVisual Studio(2012、2015、2017)からは表示されない場合がありますが、csprojに手動で追加すると、Visual Studioに表示されます。ただし、ターゲットパスはUIから編集できません。
ContentWithTargetPath
ブレークインクリメンタルコンパイルの使用(VS 2017 15.9.9でテスト済み)
それらをに保持し$(ProjectDir)\Lib
ますが、これらのファイルを「リンクとして」.csprojのルートに追加します。これで、それらはlibに存在せずにbin \ Debug(またはその他の出力フォルダー)にコピーされます。
編集:この回答は、私が使用していたVS / MSBuildのバージョンでContentWithTargetPathが利用できなかったときに書かれました。古いバージョンのVSを使用する必要がある可能性のある人のために、この回答はここに残してください。これについてのコメントはやめてください。今より良い方法があることは誰もが知っています。
プロジェクトのルートディレクトリを乱雑にせずにDLLを含めることが主な目的である場合、別の解決策は、DLLを別の共有プロジェクトに移動し、これを元のプロジェクトの参照として追加することです。
(フォルダーとプロジェクトの構造が保持されないため、この投稿はこの質問に直接回答していませんが、私のケースではプロジェクトを再構築できたため、およびここの他のアプローチの欠点)
手順
Solution -> Add -> New Project -> Shared Project
Build Action: Content
およびCopy to Output Directory: Copy Always
)References -> Add Reference -> Shared Projects
セットアップは次のようになります。
dllファイルをプロジェクトへの参照として追加し、参照で「ローカルにコピー」をtrueに設定します。
LibsディレクトリからルートフォルダーVS2017にファイルをコピーする必要がある場合:
<ItemGroup Condition="'$(Platform)' == 'x64'">
<None Include="Libs\x64\**" Link="\%(Filename)%(Extension)" CopyToOutputDirectory="PreserveNewest" />
</ItemGroup>
<ItemGroup Condition="'$(Platform)' == 'x86'">
<None Include="Libs\x86\**" Link="\%(Filename)%(Extension)" CopyToOutputDirectory="PreserveNewest" />
</ItemGroup>
Libs(RecursiveDir)フォルダーを含む他のフォルダー
<ItemGroup Condition="'$(Platform)' == 'x86'">
<None Include="Libs\x86\**" Link="mycustomfolder\%(RecursiveDir)%(Filename)%(Extension)" CopyToOutputDirectory="PreserveNewest" />
</ItemGroup>
VisualStudio 2015 では、「リンクを使用して追加する」DLLが同じプロジェクトのサブフォルダーにある場合、それらは自動的にフォルダーに配置され、出力も見たようなフォルダーに配置されます。
DLLが別のプロジェクトまたはプロジェクトのサブフォルダーではなくディスク上のディレクトリにある場合は、「リンク付きで追加」することができ、ルートディレクトリに問題なく配置されます。
別の方法は、項目をタイプのままにすることNone
です。ソリューションエクスプローラーで、デプロイするものをクリックして、Content
プロパティをに設定しますTrue
。
注:これはVS2019で行いましたが、バージョンごとに状況が変わる可能性があります。
これを機能させるには、プロジェクトを右クリックして、[プロジェクトのアンロード]を選択します。次に、アンロードしたプロジェクトを右クリックして、「project_name.vcxprojの編集」を選択します。
エディターで、ファイルの最後まで移動し、末尾の</Project>
タグの直前にこのターゲットを挿入します。
<Target Name="CopyContent" AfterTargets="Build">
<Copy SourceFiles="@(None)" Condition="'%(None.DeploymentContent)' == 'true'" DestinationFolder="$(OutputPath)" ContinueOnError="true" />
</Target>
アンロードしたプロジェクトを右クリックして、「プロジェクトの再読み込み」を選択します。プロンプトが表示されたら、保存して閉じることを選択します。
私もに設定OutputDirectory
します:
$(SolutionDir)bin\$(Configuration)\$(Platform)\
そしてIntermediateDirectory
:
$(SolutionDir)obj\$(Configuration)\$(ProjectName)\$(Platform)\
プロジェクトプロパティの[全般]ページ。これにより、出力が「bin」フォルダーに、中間体がソリューションのルートの「obj」フォルダーに配置されます。
注:$(SolutionDir)
コマンドラインからMSBuildを実行する場合、は定義されません。GetDirectoryNameOfFileAboveを使用して、.slnファイルが存在するフォルダーにそれを定義するために使用できるトリックがあります。(読者のための演習として残しました)。また、2019年にはとにかくコマンドラインでこれを正しく処理しているようです。うん:)$(SolutionDir)
それの後に何もしたがって、末尾のバックスラッシュが含まれていません。それぞれの結果には、末尾にバックスラッシュが必要です。
さて、Pro以上を所有している場合は、プロジェクトを作成する必要があるたびにこれを行わないでください。それは足りないでしょう。代わりに、プロジェクトを希望どおりにセットアップしたら、を選択しますProject -> Export Template
。名前を付けて、次にそのプロジェクトと同じようにプロジェクトを作成する場合は、[新しいプロジェクト]ダイアログでその名前を選択します。(以前のバージョンでは、これはだったと思いますFiles -> Export Teamplate...
。)
Visual Studio 2010 / C#プロジェクトでも同じ問題が発生しました。
アセンブリ(つまり.NETインターフェイスを持つ)の場合は、ソリューションエクスプローラーのプロジェクトの下にある「参照」フォルダーを使用します。それを右クリックして、「既存のアイテムを追加」を選択し、.dllアセンブリを見つけます。
一般的な.dllファイルはサブフォルダーに配置でき(「\ lib」は前述のとおり)、プロパティで次のように選択します。
これは希望どおりに機能しました-ビルド中、.DLLは "\ lib"サブフォルダーなしで出力ディレクトリにコピーされます。