使用程序集属性的最佳实践是啥？

Posted 2023-02-16

【中文标题】使用程序集属性的最佳实践是啥？

【英文标题】：What are the best practices for using Assembly Attributes?使用程序集属性的最佳实践是什么？

【发布时间】：2010-09-08 21:46:48

【问题描述】：

我有一个包含多个项目的解决方案。我正在尝试通过链接一个解决方案范围的程序集信息文件来优化 AssemblyInfo.cs 文件。这样做的最佳做法是什么？哪些属性应该在解决方案范围的文件中，哪些是项目/程序集特定的？

---

编辑：如果你有兴趣，有一个后续问题What are differences between AssemblyVersion, AssemblyFileVersion and AssemblyInformationalVersion?

【参考方案1】：

要在多个项目之间共享文件，您可以添加现有文件作为链接。

为此，添加一个现有文件，然后单击文件选择器中的“添加为链接”。_{（来源：free.fr）}

至于在共享文件中放置什么，我建议放置将跨程序集共享的东西。版权、公司、版本等信息。

【参考方案2】：

我发现有用的一件事是通过在预构建阶段应用令牌替换来生成 AssemblyVersion 元素（等）。

我使用 TortoiseSvn，很容易使用它的SubWCRev.exe 将模板AssemblyInfo.wcrev 转换为AssemblyInfo.cs。模板中的相关行可能如下所示：

[assembly: AssemblyVersion("2.3.$WCREV$.$WCMODS?1:0$$WCUNVER?1:0$")]

第三个元素是修订号。我使用第四个元素来检查我没有忘记提交任何新的或更改的文件（如果一切正常，第四个元素是 00）。

顺便说一句，将AssemblyInfo.wcrev 添加到您的版本控制中，如果您使用它，请忽略 AssemblyInfo.cs。

【参考方案3】：

我们正在使用一个名为 GlobalAssemblyInfo.cs 的全局文件和一个名为 AssemblyInfo.cs 的本地文件。全局文件包含以下属性：

 [assembly: AssemblyProduct("Your Product Name")]

 [assembly: AssemblyCompany("Your Company")]
 [assembly: AssemblyCopyright("Copyright © 2008 ...")]
 [assembly: AssemblyTrademark("Your Trademark - if applicable")]

 #if DEBUG
 [assembly: AssemblyConfiguration("Debug")]
 #else
 [assembly: AssemblyConfiguration("Release")]
 #endif

 [assembly: AssemblyVersion("This is set by build process")]
 [assembly: AssemblyFileVersion("This is set by build process")]

本地 AssemblyInfo.cs 包含以下属性：

 [assembly: AssemblyTitle("Your assembly title")]
 [assembly: AssemblyDescription("Your assembly description")]
 [assembly: AssemblyCulture("The culture - if not neutral")]

 [assembly: ComVisible(true/false)]

 // unique id per assembly
 [assembly: Guid("xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx")]

您可以使用以下过程添加 GlobalAssemblyInfo.cs：

在项目的上下文菜单中选择

Add/Existing Item...

选择 GlobalAssemblyInfo.cs 通过单击右侧的小向下箭头来展开添加按钮 在按钮下拉列表中选择“添加为链接”

【讨论】：

保留旧的 AssemblyInfo.cs 文件的目的是什么？当我在 GlobalAssemblyInfo.cs 中自动化构建版本标记时，如何更新我的解决方案中的 AssemblyInfo.cs 文件？

@Devtron 各个 AssemblyInfo 文件应提供它们所在的程序集独有的信息（例如，标题、描述和文化，如上例所示）。应删除常见条目，例如产品名称和版本信息（如果重复，则会导致编译器错误）。理想情况下，AssemblyInfo 文件不会被构建过程更新。

AssemblyCultureAttribute 值得更好的解释。该属性最好完全不存在（除非这是一个附属程序集）。在大规模使用附属程序集时，可能需要三个而不是两级程序集信息文件（全局、主程序集和附属程序集，在这种情况下只指定文化）。

【参考方案4】：

在我看来，使用 GlobalAssemblyInfo.cs 麻烦多于其价值，因为您需要修改每个项目文件并记住修改每个新项目，而默认情况下您会得到一个 AssemblyInfo.cs。

对于全局值（即公司、产品等）的更改，这些更改通常很少且易于管理，我认为 DRY 不应该是一个考虑因素。当您想一次性手动更改所有项目中的值时，只需运行以下 MSBuild 脚本（依赖于 MSBuild Extension Pack）：

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" DefaultTargets="UpdateAssemblyInfo" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">

    <ItemGroup>
        <AllAssemblyInfoFiles Include="..\**\AssemblyInfo.cs" />
    </ItemGroup>

    <Import Project="MSBuild.ExtensionPack.tasks" />

  <Target Name="UpdateAssemblyInfo">
    <Message Text="%(AllAssemblyInfoFiles.FullPath)" />
    <MSBuild.ExtensionPack.Framework.AssemblyInfo 
        AssemblyInfoFiles="@(AllAssemblyInfoFiles)"
        AssemblyCompany="Company"
        AssemblyProduct="Product"
        AssemblyCopyright="Copyright"
        ... etc ...
        />
  </Target>

</Project>

【参考方案5】：

MSBuild Community Tasks 包含一个名为 AssemblyInfo 的自定义任务，您可以使用它来生成您的 assemblyinfo.cs。它需要对您的 csproj 文件进行一点手工编辑才能使用，但这是值得的。

【参考方案6】：

@JRoppert 提出的解决方案与我所做的几乎相同。唯一的区别是我将以下几行放在本地 AssemblyInfo.cs 文件中，因为它们可能因每个程序集而异：

#if DEBUG
[assembly: AssemblyConfiguration("Debug")]
#else
[assembly: AssemblyConfiguration("Release")]
#endif
[assembly: AssemblyVersion("This is set by build process")]
[assembly: AssemblyFileVersion("This is set by build process")]
[assembly: CLSCompliant(true)]

我还（通常）为每个解决方案使用一个通用装配信息，并假设一种解决方案是单个产品线/可发布产品。通用程序集信息文件还有：

[assembly: AssemblyInformationalVersion("0.9.2.0")]

这将设置 Windows Explorer 显示的“ProductVersion”值。

【参考方案7】：

在我的例子中，我们正在构建一个产品，我们有一个 Visual Studio 解决方案，在他们自己的项目中包含各种组件。共同的属性去。在解决方案中，大约有35个项目，以及一个通用的程序集信息（CommonAssemblyInfo.cs），它具有以下属性：

[assembly: AssemblyCompany("Company")]
[assembly: AssemblyProduct("Product Name")]
[assembly: AssemblyCopyright("Copyright © 2007 Company")]
[assembly: AssemblyTrademark("Company")]

//This shows up as Product Version in Windows Explorer
//We make this the same for all files in a particular product version. And increment it globally for all projects.
//We then use this as the Product Version in installers as well (for example built using Wix).
[assembly: AssemblyInformationalVersion("0.9.2.0")]

其他属性，例如 AssemblyTitle、AssemblyVersion 等，我们基于每个程序集提供。构建程序集时，AssemblyInfo.cs 和 CommonAssemblyInfo.cs 都内置到每个程序集中。这为我们提供了两全其美的优势，您可能希望为所有项目提供一些共同属性，并为其他一些项目提供特定值。

希望对您有所帮助。

【讨论】：

您的构建配置中有超过 35 个条目来处理这个问题吗？显得比较多余。如果您添加 2 或 3 个新项目，在您将它们添加到版本控制任务之前，这会破坏您的构建吗？

@D3vtr0n，为什么“构建配置”（你的意思是什么）需要这么多条目？我假设此文件包含在每个 .csproj 到 <Compile Include="$(MSBuildThisFileDirectory)..\Common\CommonAssemblyInfo.cs"/> 中，这是一个 MSBuild 指令，甚至可能位于共享的 Common.targets 文件中。是的代码重用。

【参考方案8】：

不建议对多个项目使用单个 AseemblyInfo.cs 文件。 AssemblyInfo 文件包含可能仅与该特定程序集相关的信息。最明显的两条信息是AssemblyTitle 和AssemblyVersion。

更好的解决方案可能是使用由 MSBuild 处理的 targets 文件，以便将程序集属性“注入”多个项目。

【讨论】：

如果您有 20 多个项目怎么办？这需要我在构建配置中维护 20 多个条目，仅用于版本控制。这似乎真的很蹩脚。如果我添加 2 或 3 个新项目怎么办？这肯定会破坏构建过程......有什么想法可以解决这个问题吗？

@D3vtr0n 我认为这个想法是动态生成相关程序集，而不是为每个项目维护单独的配置。我认为社区任务可以处理这种情况。