简体   繁体   English

将解决方案中的项目编译到文件夹层次结构中的推荐/安全方法是什么?

[英]What's a recommended/safe way to compile projects in a solution into a folder hierarchy?

I sometimes create C#-based software that consists of multiple projects inside one solution.我有时会创建基于 C# 的软件,该软件在一个解决方案中包含多个项目。 The assemblies created from the projects should go into different output directories.从项目创建的程序集应 go 到不同的 output 目录中。

As a simple example, consider this:作为一个简单的例子,考虑一下:

myApplication
 |- MainApplication.exe
 |- PluginInterfaces.dll
 \- plugins
     \- SamplePlugin.dll

That would be the result of a solution with three projects inside.这将是内部包含三个项目的解决方案的结果。

In former versions of Visual Studio (I am not exactly sure when the switch happened - maybe from VS 2019 to VS 2022, as VS 2022 was the first version where I became aware of the issue?), I could use the project settings to set an output path for each project.在以前版本的 Visual Studio 中(我不确定切换发生的时间 - 可能是从 VS 2019 到 VS 2022,因为 VS 2022 是我意识到这个问题的第一个版本?),我可以使用项目设置来设置每个项目的 output 路径。

As the output path contained the build configuration, I had to set this output path for each project and each build configuration, which was slightly cumbersome, but still, it would get the job done.由于 output 路径包含构建配置,我必须为每个项目和每个构建配置设置这个 output 路径,这有点麻烦,但仍然可以完成工作。 In the above example, this would result in the following settings:在上面的示例中,这将导致以下设置:

Project项目 Debug Output Path调试 Output 路径 Release Output Path发布 Output 路径
MainApplication主应用 ..\..\bin\Debug\ ..\..\bin\Release\
PluginInterfaces插件接口 ..\..\bin\Debug\ ..\..\bin\Release\
SamplePlugin示例插件 ..\..\bin\Debug\plugins\ ..\..\bin\Release\plugins\

Now, I just became aware this looks a bit different in VS 2022 - there now is a single, configuration-agnostic setting called "Base Output Path".现在,我才意识到这在 VS 2022 中看起来有点不同——现在有一个与配置无关的设置,称为“Base Output Path”。

This way, the build configuration (and target framework) will be added automatically after the base output path.这样,构建配置(和目标框架)将自动添加到基本 output 路径之后。 While this is somewhat more convenient, I now face the problem that it makes no sense anymore to assign different base output paths to individual projects, unless I want to have the resulting assemblies end up in completely separate folder trees.虽然这更方便一些,但我现在面临的问题是,为各个项目分配不同的基本 output 路径不再有意义,除非我想让生成的程序集最终位于完全独立的文件夹树中。


If there is no setting in VS to work around that, I presume I could edit the .csproj file to somehow directly influence the output path - ways to do this are mentioned in another answer , though its author cautions that it may have undesirable side-effects for the build-logic.如果 VS 中没有设置来解决这个问题,我想我可以编辑.csproj文件以某种方式直接影响 output 路径 - 另一个答案中提到了这样做的方法,尽管它的作者警告说它可能有不受欢迎的一面 -构建逻辑的效果。

FWIW, I have actually tried modifying the <OutputPath> like this: FWIW,我实际上已经尝试像这样修改<OutputPath>

<OutputPath>$(BaseOutputPath)$(PlatformName)\$(Configuration)\plugins\</OutputPath>

Unfortunately, the platform for some reason gets appended after that path.不幸的是,由于某种原因,该平台被附加该路径之后。 Same if I use <OutDir> instead of <OutputPath> .如果我使用<OutDir>而不是<OutputPath>也是一样。

Another possible approach could be just compiling to the default locations, then using a post-build event to copy everything to the final location - but then, I fear launching the application from VS for debugging would not take the assemblies from their final (copied to) location.另一种可能的方法可能只是编译到默认位置,然后使用构建后事件将所有内容复制到最终位置 - 但是,我担心从 VS 启动应用程序进行调试不会将程序集从它们的最终位置(复制到) 地点。


What is an effective way to configure my projects so the output forms a folder tree, while not risking to run into any side-effects by circumventing default behaviour?什么是配置我的项目的有效方法,使 output forms 成为一个文件夹树,同时又不冒因规避默认行为而遇到任何副作用的风险?

It appears I can achieve the desired result with the following settings in my .csproj file:看来我可以通过.csproj文件中的以下设置获得所需的结果:

<BaseOutputPath>..\..\bin\</BaseOutputPath>
<OutDir>$(BaseOutputPath)\$(Configuration)\$(TargetFramework)\plugins\</OutDir>

I am not sure why it works like this - looking at the source , I had actually expected also having to specify我不确定为什么它会这样工作 - 查看源代码,我实际上还希望必须指定

<AppendTargetFrameworkToOutputPath>False</AppendTargetFrameworkToOutputPath>

but apparently, that was not necessary - the additional targt framework mention after \plugins\ is gone already once I force the target framework to appear in front of it.但显然,这不是必需的 - 一旦我强制目标框架出现在它前面, \plugins\之后提到的额外目标框架就已经消失了。

(Now, I am not yet sure this does not provoke any undesirable side-effects, so I'm going to leave this answer open for a while rather than marking it as accepted right away.) (现在,我还不确定这不会引起任何不良的副作用,所以我打算暂时保留这个答案,而不是立即将其标记为已接受。)

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

相关问题 Visual Studio 解决方案中的推荐项目数 - Recommended number of projects in Visual Studio Solution 解决方案具有位于解决方案文件夹之外的项目 - Solution has projects that are located outside the solution folder 将所有项目EXE和DLL文件复制到一个公用文件夹的解决方案中的最佳方法? - Best Way To Copy All Projects EXE And DLL Files In A Solution To One Common Folder? Visual Studio:跨项目引用资源的正确方法是什么? - Visual Studio: What's the correct way to reference resources across projects? 有没有办法为解决方案中的特定项目自动化构建顺序? - Is there a way to automate build order for specific projects in a solution? 有没有一种简单的方法可以将多个项目添加到解决方案中? - Is there an easy way to add multiple projects to a solution? Visual Studio 2008加载项检查层次结构项是否为解决方案文件夹 - Visual Studio 2008 Add-In Check if Hierarchy Item is solution folder qmake可以支持Visual Studio解决方案的文件夹层次结构吗? - Can qmake support a folder hierarchy for a Visual Studio solution? 什么是 Visual Studio 中的解决方案文件夹? - What is a solution folder in Visual Studio? 一个解决方案中两个项目之间的Visual Studio 2013共享文件夹 - Visual Studio 2013 shared folder between two projects in one solution
 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM