【问题标题】: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?

【问题讨论】:

    标签: .net assemblies attributes assemblyinfo


    【解决方案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 到 &lt;Compile Include="$(MSBuildThisFileDirectory)..\Common\CommonAssemblyInfo.cs"/&gt; 中,这是一个 MSBuild 指令,甚至可能位于共享的 Common.targets 文件中。是的代码重用。
              【解决方案8】:

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

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

              【讨论】:

              • 如果您有 20 多个项目怎么办?这需要我在构建配置中维护 20 多个条目,仅用于版本控制。这似乎真的很蹩脚。如果我添加 2 或 3 个新项目怎么办?这肯定会破坏构建过程......有什么想法可以解决这个问题吗?
              • @D3vtr0n 我认为这个想法是动态生成相关程序集,而不是为每个项目维护单独的配置。我认为社区任务可以处理这种情况。
              猜你喜欢
              • 2010-10-30
              • 1970-01-01
              • 1970-01-01
              • 1970-01-01
              • 2019-01-25
              • 2018-03-13
              • 1970-01-01
              • 1970-01-01
              • 1970-01-01
              相关资源
              最近更新 更多