Visual Studio 可以像 app.config 一样自动调整其他文件的名称吗?

发布于 2024-11-06 16:49:13 字数 540 浏览 5 评论 0原文

将应用程序配置文件添加到 Visual Studio 中的 .Net 项目时,它将被命名为 app.config 并将在构建时重命名为 ApplicationName.config

我有一个包含大约 40 个项目的解决方案。我想为其中一些添加 log4net 功能。因此,对于每个项目,我都会添加一个文件 app.log4net。然后我会声明一个像这样的构建后事件:

copy $(ProjectDir)app.log4net $(TargetPath).log4net

效果很好。但我想知道是否有一种内置方法可以在没有明确的构建后事件的情况下实现相同的目的。

编辑:虽然我喜欢 JaredPar 和 Simon Mourier 提出的两种解决方案,但它们没有提供我所希望的。为此使用自定义工具或 MsBuild 规则使其不太透明(对于项目中的其他程序员而言),或者至少比使用我当前使用的构建后事件更复杂。尽管如此,我觉得 MsBuild 将是解决类似问题的正确地方。

When adding an Application Configuration file to a .Net project in Visual Studio it will be named app.config and will be renamed (on build) to ApplicationName.config.

I have a solution with about 40 projects. I want to add log4net functionality to quite a few of them. So for every project I would add a file app.log4net. I would then declare a post-build event like this:

copy $(ProjectDir)app.log4net $(TargetPath).log4net

That works just fine. But I was wondering whether there was a built-in way to achieve the same without an explicit post-build event.

Edit: While I like both solutions proposed by JaredPar and Simon Mourier, they don't provide what I was hoping for. Having a custom tool or MsBuild rule for this makes it less transparent (for other programmers on the project) or at least more complicated than using the post-build event I am currently using. Nevertheless, I feel like MsBuild would be the correct place to solve similar issues.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

_畞蕅 2024-11-13 16:49:13

在这种情况下,更新 app.config 名称的不是 Visual Studio,而是独立于 Visual Studio 的核心 MSBuild 规则。如果您想模拟 app.config 模型,您应该采用这种方法。

控制 app.config 复制的构建序列的两个部分位于 Microsoft.Common.targets 中。

首先计算文件名

<ItemGroup>
    <AppConfigWithTargetPath Include="$(AppConfig)" Condition="'$(AppConfig)'!=''">
        <TargetPath>$(TargetFileName).config</TargetPath>
    </AppConfigWithTargetPath>
</ItemGroup>

,然后将其实际复制为构建的一部分

<Target
    Name="_CopyAppConfigFile"
    Condition=" '@(AppConfigWithTargetPath)' != '' "
    Inputs="@(AppConfigWithTargetPath)"
    Outputs="@(AppConfigWithTargetPath->'$(OutDir)%(TargetPath)')">

    <!--
    Copy the application's .config file, if any.
    Not using SkipUnchangedFiles="true" because the application may want to change
    the app.config and not have an incremental build replace it.
    -->
    <Copy
        SourceFiles="@(AppConfigWithTargetPath)"
        DestinationFiles="@(AppConfigWithTargetPath->'$(OutDir)%(TargetPath)')"
        OverwriteReadOnlyFiles="$(OverwriteReadOnlyFiles)"
        Retries="$(CopyRetryCount)"
        RetryDelayMilliseconds="$(CopyRetryDelayMilliseconds)"
        UseHardlinksIfPossible="$(CreateHardLinksForAdditionalFilesIfPossible)"
        >

        <Output TaskParameter="DestinationFiles" ItemName="FileWrites"/>

    </Copy>

</Target>

In this case it's not Visual Studio which is updating the name of app.config but instead it's a core MSBuild rule which is independent of Visual Studio. If you want to emulate the app.config model this is the approach you should take

The two parts of the build sequence which control the copying of app.config are found in Microsoft.Common.targets.

First the name of the file is calculated

<ItemGroup>
    <AppConfigWithTargetPath Include="$(AppConfig)" Condition="'$(AppConfig)'!=''">
        <TargetPath>$(TargetFileName).config</TargetPath>
    </AppConfigWithTargetPath>
</ItemGroup>

Next it is actually copied as a part of the build

<Target
    Name="_CopyAppConfigFile"
    Condition=" '@(AppConfigWithTargetPath)' != '' "
    Inputs="@(AppConfigWithTargetPath)"
    Outputs="@(AppConfigWithTargetPath->'$(OutDir)%(TargetPath)')">

    <!--
    Copy the application's .config file, if any.
    Not using SkipUnchangedFiles="true" because the application may want to change
    the app.config and not have an incremental build replace it.
    -->
    <Copy
        SourceFiles="@(AppConfigWithTargetPath)"
        DestinationFiles="@(AppConfigWithTargetPath->'$(OutDir)%(TargetPath)')"
        OverwriteReadOnlyFiles="$(OverwriteReadOnlyFiles)"
        Retries="$(CopyRetryCount)"
        RetryDelayMilliseconds="$(CopyRetryDelayMilliseconds)"
        UseHardlinksIfPossible="$(CreateHardLinksForAdditionalFilesIfPossible)"
        >

        <Output TaskParameter="DestinationFiles" ItemName="FileWrites"/>

    </Copy>

</Target>
吖咩 2024-11-13 16:49:13

我认为 app.config 是相当硬编码的(你可以尝试其他名称 xxx.config 但它不起作用)。

您无需构建后事件即可获得相同的结果,但使用为 .log4net 文件选择的自定义工具。请参阅以下示例:编写自定义工具来生成 Visual Studio .NET 代码开发 Visual Studio自定义工具

I think it's pretty hardcoded for app.config (you can try other names xxx.config and it does not work).

You could achieve the same result without a post build event, but with a custom tool that you would choose for your .log4net files. See these examples: Writing a custom tool to generate code for Visual Studio .NET and Developing a Visual Studio Custom Tool

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文