ChatGPT解决这个技术问题 Extra ChatGPT

使用程序集属性的最佳实践是什么?

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

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


H
Hakan Fıstık

我们正在使用一个名为 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 值得更好的解释。该属性最好完全不存在(除非这是附属程序集)。在大规模使用附属程序集时,可能需要三个而不是两级程序集信息文件(全局、主程序集和附属程序集,在这种情况下只指定文化)。
K
Krishna

在我的例子中,我们正在构建一个产品,我们有一个 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 文件中。是的代码重用。
S
Scott Dorman

@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 资源管理器显示的“ProductVersion”值。


S
Simon

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


J
Jack Ukleja

在我看来,使用 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>

我认为您正在寻找一个不存在的问题,因为您可以使用简单的 Directory.Build.props 文件轻松注入 GlobalAssemblyInfo.cs,该文件还涵盖了您将来添加的所有项目。
G
Glorfindel

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

https://i.stack.imgur.com/w4Ka4.png

至于在共享文件中放置什么,我建议放置将跨程序集共享的东西。诸如版权,公司,也许是版本之类的东西。


K
Kurt Van den Branden

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

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

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

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

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


S
SaguiItay

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

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


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