我有一个 .NET Core 3 项目，它引用了其他几个项目。我的主根项目有Release-X构建配置，但其他项目只有一个Release配置，没有匹配的Release-X配置。
当我尝试使用此发布我的主根项目时......
dotnet publish MyProject.csproj -c Release-X
...它似乎对所有引用的项目使用了一些神秘的不存在的默认构建配置。（我可以这么说，因为引用的项目允许在其所有构建配置中使用不安全代码，但使用上述命令进行构建会导致不安全代码错误。）
我希望能够使用其Release-X构建配置来构建我的主根项目，但使用其Release配置来构建所有引用的项目。我该怎么做呢？
我正在处理一个具有多种解决方案的项目。我最近在我的一个解决方案中添加了对 Nuget 包 X 的引用。这导致了一些版本冲突，所以我更新了所有解决方案中 x 的版本。现在在有冲突的解决方案中，我可以看到添加了以下几行
<Import Project="..\packages\X.3.3.2.0\build\X.props" Condition="Exists('..\packages\X.3.3.2.0\build\X.props')" />
<Error Condition="!Exists('..\packages\X.3.3.2.0\build\X.props')" Text="$([System.String]::Format('$(ErrorText)', '..\packages\X.3.3.2.0\build\X.props'))" />
有谁知道为什么添加这个以及这些行的意义是什么？
我正在TeamCity中为.Net Core项目构建一组构建模板.除了控制台项目外,一切都很好.问题是,当我发布解决方案时,我需要指定框架版本.在构建中没有其他任何点我需要知道框架.在发布.sln文件时,至少会出现这种情况,控制台项目只有一个框架.
所以现在我处于这样一种情况,我需要弄清楚控制台项目应该以什么框架为目标.我可以阅读各种XML文件,但我希望我不需要.是否有一些内置的方法可以查询给定解决方案使用的框架？
例如,像(PowerShell)
$frameworks = & dotnet.exe --<what I want> .\MySolution.sln
for ($framework in $frameworks) {
& dotnet.exe publish -f $framework .\MySolution.sln
}
这样,每次使用新框架时,我都不需要修改构建系统.我在CLI仓库中探索过,但我找不到能满足我需要的命令.打开.csproj文件是我唯一的希望吗？
我对csproj文件有疑问。
由于我拥有大量的源库，因此我正在尝试最大程度地减少项目文件上的冲突（与团队一起开发时）。
我设法通过使用如下标记消除了大多数碰撞：
<Compile Include="Services\**\*.cs" />
对于普通的cs文件和
<Page Include="Entities\**\*.xaml">
<SubType>Designer</SubType>
<Generator>MSBuild:Compile</Generator>
</Page>
用于xaml和代码隐藏。
不幸的是，我松开了.xaml和.xaml.cs对的分组，这是可以忍受的，但是笨拙。
有什么办法为这些创建通用模式吗？
<Compile Include="MainWindow.xaml.cs">
<DependentUpon>MainWindow.xaml</DependentUpon>
<SubType>Code</SubType>
</Compile>
我知道分裂csproj本身的可能性，但这将禁止解决方案范围内的搜索，因此这是不可行的
我是一名大学生。我想在我的课程中使用 .NET Core。为此，我的代码需要在部门 Linux 集群上编译和运行，因为这是我的导师测试我提交的内容。
我的系统管理员在试用的基础上为我安装了最近发布的 .NET Core 2.0 RHEL 包。我创建、构建并运行了Microsoft 提供的示例 CLI 项目，并且它们运行良好。但是我的系统管理员很不高兴，因为dotnet在（全局）/tmp 中创建了至少一个文件，在我注销后它仍然存在。
-rw------- myuser mygroup /tmp/.NETCoreApp,Version=v2.0.AssemblyAttributes.cs
原则上，他不希望dotnet在/tmp中创建任何在其进程完成后不会清理的文件。更重要的是，当他试图自己构建微软的样本时，它失败了；dotnet试图访问上述文件，他的用户没有读取权限！
理想情况下，dotnet不会创建任何生命周期与其正在构建的项目不同的文件。为了实现这一点，任何这样的文件都可以存在于项目目录中——可能在bin子目录下，以便 aclean将清除它们。有没有办法让dotnet这些文件写在那里？否则，它是否可以至少使用临时文件名，以避免我们遇到的权限冲突？
无论解决方案是什么，它都必须是全系统的，不能依赖于用户的良好行为。所以像要求用户设置$TMPDIR这样的事情是行不通的。
我正在为一个新项目设置开发环境。它是一个 Web API 项目，通过静态文件为 @Angular 项目提供服务。为了促进这一点，在构建后，我运行 Angular cli 的构建函数，然后将文件复制到 wwwroot 中。这一切都工作正常。
但是，我希望能够根据项目处于调试模式还是发布模式来运行两个不同的 npm 脚本。在我的构建后脚本中，我尝试了以下方法：
if "$(ConfigurationName)" == "Debug"
(
npm run build
)
else if "$(ConfigurationName)"=="Release"
(
npm run prod
)
但我得到了
The command "if "" == "Debug"
(
npm run build
)
else if ""=="Release"
(
npm run prod
)" exited with code 255.
看起来没有为 ConfigurationName 提供任何值。我尝试过调试和发布模式并得到相同的错误。VS 2017 中的 ConfigurationName 变量是否发生了变化？
编辑：但是，如果我单击“编辑构建后”，然后单击“宏”，我可以在此处看到ConfigurationName 有一个值。只是我的脚本没有看到它
我正在尝试包含 Directory.build.props 文件，因为我想在一个地方更改所有项目的版本。
如果我使用 Visual Studio 构建解决方案，Director.build.props 文件中的属性会正确嵌入到构建的 exe 文件中。如果我使用dotnet build命令，exe 文件没有嵌入所需的属性。我观察到 dll 文件具有使用 CLI 命令以及使用 Visual Studio 嵌入的正确属性。
Directory.build.props 文件位于解决方案的根目录下（我尝试将它放在项目的根目录下，但同样的事情发生了）。这是我正在使用的 Directory.build.props 文件
<Project>
<PropertyGroup>
<Company>Company</Company>
<Copyright>Copyright</Copyright>
<Version>1.0.0</Version>
<AssemblyVersion>1.0.0</AssemblyVersion>
<FileVersion>1.0.0</FileVersion>
</PropertyGroup>
</Project>
我想知道我是否缺少一些配置，为什么 dll 成功嵌入了属性而 exe 文件没有？