重复的 AssemblyVersion 属性答案

【问题标题】：Duplicate AssemblyVersion Attribute重复的 AssemblyVersion 属性
【发布时间】：2012-05-05 21:11:18
【问题描述】：

我有一个项目在编译时产生以下错误：

错误 CS0579：重复的“AssemblyVersion”属性

我检查了文件AssemblyInfo.cs，看起来那里没有重复。

我发现this article on MSDN 解决了类似的问题，并且按照本文中的建议也可以解决问题。

谁能告诉我这里发生了什么？是否仅在两个或多个项目具有相似名称的类的情况下才会发生？还是别的什么？

【问题讨论】：

只是猜测，但您是否尝试关闭并再次打开解决方案？也许这可以解决它？
如果将项目转换为 .NET Core ，请参阅elanderson.net/2017/06/…
我在 Mac 上使用 Visual Studio 2017 社区版。我有一个控制台应用程序，然后我添加了对新类库项目的引用。当我进行构建时，这些错误开始出现。我所做的只是删除对类库项目的引用，然后将其添加回来，错误就消失了。

标签： c# compiler-errors

【解决方案1】：

从 Visual Studio 2017 开始，继续使用 AssemblyInfo.cs 文件的另一个解决方案是关闭自动程序集信息生成，如下所示：

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <GenerateAssemblyInfo>false</GenerateAssemblyInfo>
  </PropertyGroup>
</Project>

我个人觉得它对于需要同时支持 .NET Framework 和 .NET Standard 的项目非常有用。

【讨论】：

是的，这对我有用，删除 obj 和 bin 文件夹是不够的。
不幸的是，每次我使用其属性页（应用程序、构建、构建事件等）更改.csproj 文件时，带有GenerateAssemblyInfo 的PropertyGroup 都会消失：-(跨度>
将其移动到 Directory.Build.props 文件中
此解决方案是否存在任何风险或负面结果？
完美解决了我的问题！

【解决方案2】：

我过去也遇到过这个问题，所以我假设您的构建过程提供了单独的程序集信息以提供版本控制。这会导致重复，因为您的项目在 AssemblyInfo.cs 文件中也有该信息。所以删除文件，我认为它应该可以工作。

【讨论】：

那么，构建过程不应该覆盖现有的 AssemblyVersion 而不是创建新条目吗？我知道我们的构建过程会这样做，但我很好奇为什么它不会覆盖现有的。是执行不力还是限制？
我认为对于 .net 程序集，更好的方法是使用版本注入方法。但那是一个单独的故事。在您的情况下，问题是通过 cmdline 构建参数和 AssemblyInfo.cs 提供程序集版本的方式不同，您必须确保只有一种方法被用作属性重复是 .net 编译错误。跨度>
具体删除什么？
删除 AssemblyInfo.cs 文件解决了我的问题。

【解决方案3】：

将旧项目转换为 .NET Core 时，AssemblyInfo.cs 中的大部分信息现在可以在项目本身上设置。打开项目属性并选择 Package 选项卡以查看新设置。

Eric L. Anderson's post "Duplicate ‘System.Reflection.AssemblyCompanyAttribute’ attribute" 描述了 3 个选项：

从 AssemblyInfo.cs 文件中删除冲突项，
完全删除文件或
禁用 GenerateAssemblyInfo（如 another answer by Serge Semenov 中的建议）

【讨论】：

我发现在项目 (.csproj) 中指定这些属性更直观、更“Visual Studio”，因为它们是元数据而不是描述实际逻辑的代码。我希望将来可以在项目中指定所有内容！（目前我无法指定 COM 可见性，所以我将其留在AssemblyInfo.cs。）

【解决方案4】：

我有同样的错误，它强调了程序集版本和程序集文件版本，所以阅读 Luqi 答案我只是将它们添加为 cmets 并且错误已解决

// AssemblyVersion is the CLR version. Change this only when making breaking    changes
//[assembly: AssemblyVersion("3.1.*")]
// AssemblyFileVersion should ideally be changed with each build, and should help identify the origin of a build
//[assembly: AssemblyFileVersion("3.1.0.0")]

【讨论】：

我试过了，在我的情况下它没有任何改变:-(

【解决方案5】：

在我的例子中，项目中的一个子文件夹是它自己的项目文件夹：

文件系统：
- c:\projects\webapi\wepapi.csproj
- c:\projects\webapi\tests\wepapitests.csproj
解决方案
- webapi（文件夹和项目）
  - 测试（文件夹）
- 测试（文件夹和项目）

然后我不得不从“webapi”项目中删除子文件夹“tests”。

【讨论】：

我已经从解决方案中删除了子项目，但子目录和文件仍然存在。删除它们最终解决了问题。

【解决方案6】：

在我的例子中，编译期间生成的一些临时 *.cs 文件被意外添加到项目中。

这些文件来自obj\Debug 目录，因此绝对不应该将它们添加到解决方案中。 *.cs 通配符有点疯狂并错误地添加了它们。

删除这些文件解决了问题。

【讨论】：

【解决方案7】：

这里的项目中必须已经有一个 AssemblyInfo.cs 文件：

解决： - 删除任意一个AssemblyInfo.cs

【讨论】：

【解决方案8】：

我在尝试添加 GitVersion 工具以在 AssemblyInfo.cs 中更新我的版本时遇到了同样的问题。使用 VS2017 和 .NET Core 项目。所以我只是混合了两个世界。我的 AssemblyInfo.cs 仅包含由 GitVersion 工具生成的版本信息，我的 csproj 包含剩余的东西。请注意我不使用<GenerateAssemblyInfo>false</GenerateAssemblyInfo> 我只使用与版本相关的属性（见下文）。更多细节在这里AssemblyInfo properties。

AssemblyInfo.cs

[assembly: AssemblyVersion("0.2.1.0")]
[assembly: AssemblyFileVersion("0.2.1.0")]
[assembly: AssemblyInformationalVersion("0.2.1+13.Branch.master.Sha.119c35af0f529e92e0f75a5e6d8373912d457818")]

my.csproj 包含所有与其他程序集相关的属性：

<PropertyGroup>
   ...
  <Company>SOME Company </Company>
  <Authors>Some Authors</Authors>
  <Product>SOME Product</Product>
   ...
  <GenerateAssemblyVersionAttribute>false</GenerateAssemblyVersionAttribute>
  <GenerateAssemblyFileVersionAttribute>false</GenerateAssemblyFileVersionAttribute>
  <GenerateAssemblyInformationalVersionAttribute>false</GenerateAssemblyInformationalVersionAttribute>
</PropertyGroup>

【讨论】：

【解决方案9】：

对我来说，AssembyInfo.cs 和 SolutionInfo.cs 具有不同的值。所以也要检查这些文件。我刚刚从其中一个中删除了版本。

【讨论】：

【解决方案10】：

我的错误发生是因为不知何故，在我的控制器文件夹中创建了一个 obj 文件夹。只需在您的应用程序中搜索您的 Assemblyinfo.cs 中的一行。某处可能有重复。

【讨论】：

同样，我在属于另一个 .csproj (B) 的另一个文件夹中有一个 .csproj 文件 (A)。

【解决方案11】：

将核心升级到 VS2017 时的另一个解决方案是在 properties\assemblyinfo.cs 文件中删除它们。

因为它们现在存储在项目中。

【讨论】：

【解决方案12】：

如果我在 Visual Studio 2017 中编译项目，然后我尝试使用 .NET Core 使用命令行命令“dotnet run”重建并运行它，这通常会发生。

只需删除所有“bin”和“obj”文件夹 - 都在“ClientApp”内和直接在项目文件夹中 - 允许 .NET Core 命令“dotnet run”重新构建并成功运行。

【讨论】：

【解决方案13】：

我最近在没有更改源代码的情况下遇到了这个问题，但是在尝试了一些新的项目参考之后。即使在还原分支中的所有更改后，我也进入了出现此错误的状态。

清理分支为我解决了它：

git clean -xfd

【讨论】：

【解决方案14】：

您可以删除 bin 和 obj 文件并清除项目的缓存。我的问题由此得到解决。

【讨论】：

【解决方案15】：

我在 msdn 上找到了这个答案，它解释了将文件标记为内容，然后复制到输出 = 如果较新。见下文：

https://social.msdn.microsoft.com/Forums/en-US/8671bdff-9b16-4b49-ba9e-227cc4df31b2/compile-error-cs0579-duplicate-assemblyversion-attribute?forum=vsgatk

生长激素

【讨论】：

【解决方案16】：

编辑您的 AssemblyInfo.cs 和 #if !NETCOREAPP3_0 ... #endif

using System.Reflection;
using System.Runtime.CompilerServices;
using System.Runtime.InteropServices;
// General Information about an assembly is controlled through the following
// set of attributes. Change these attribute values to modify the information
// associated with an assembly.

#if !NETCOREAPP3_0  

[assembly: AssemblyTitle(".Net Core Testing")]
[assembly: AssemblyDescription(".Net Core")]
[assembly: AssemblyConfiguration("")]
[assembly: AssemblyCompany("")]
[assembly: AssemblyProduct(".Net Core")]
[assembly: AssemblyCopyright("Copyright ©")]
[assembly: AssemblyTrademark("")]
[assembly: AssemblyCulture("")]

// Setting ComVisible to false makes the types in this assembly not visible
// to COM components.  If you need to access a type in this assembly from
// COM, set the ComVisible attribute to true on that type.
[assembly: ComVisible(false)]

// The following GUID is for the ID of the typelib if this project is exposed to COM
[assembly: Guid("000b119c-2445-4977-8604-d7a736003d34")]

// Version information for an assembly consists of the following four values:
//
//      Major Version
//      Minor Version
//      Build Number
//      Revision
//
// You can specify all the values or you can default the Build and Revision Numbers
// by using the '*' as shown below:
// [assembly: AssemblyVersion("1.0.*")]
[assembly: AssemblyVersion("1.0.0.0")]
[assembly: AssemblyFileVersion("1.0.0.0")]

#endif

【讨论】：

【解决方案17】：

当我将 2 个项目放在同一个目录中时，我收到了这个错误。如果我有一个包含解决方案的目录，并且我在其中放置了一个单独的 Web 和 Data 目录，则编译正确。

【讨论】：

【解决方案18】：

当我的主项目与解决方案位于同一文件夹中时，我遇到了这个问题，然后我在位于子文件夹中的同一解决方案中有一个单独的项目，并且该单独的项目使用主项目作为参考。这导致主项目检测到创建重复引用的子文件夹 bin 和 obj 文件夹。

【讨论】：

这对我帮助很大！一个项目引用另一个作为构建时依赖项，但 csproj 中的一个错误导致 obj 文件夹不同，从而产生此错误。

【解决方案19】：

如果您在 Azure DevOps 的构建管道中遇到此问题，请尝试在 AssembyInfo.cs 文件属性中将构建操作作为“内容”并复制到输出目录等于“如果较新则复制”。

【讨论】：

【解决方案20】：

当您创建项目时，Visual Studio 会将其设置为编译并生成相应的 程序集。每个项目生成 1 个程序集，因此每个项目都有相应的程序集配置来生成其程序集。

问题是当您创建多个项目时，每个项目都可以生成自己的程序集，然后将其中一个项目包含在另一个项目中 em>。

在这种情况下，Visual Studio 会感到困惑并且不知道要使用哪个配置文件来生成项目的单个程序集——它会在 中找到第二个程序集配置>包含项目并说“嘿，重复！你给了我两套指令来生成我的程序集！”

但有时您仍然希望包含项目能够自行生成程序集，但当它被包含在另一个项目中时则不然。

为此，一种解决方案是将条件定义添加到包括项目（在项目属性中找到）。然后更改 included 项目中的程序集配置以查找此条件定义。如果它被定义（由包括项目），那么配置可以跳过它的内容——这将导致VS只找到1个配置——来自包括 em> 项目 -- 问题解决了！

【讨论】：

【解决方案21】：

我的错误是我还在我的项目中引用了另一个文件，该文件也包含属性“AssemblyVersion”的值。我从其中一个文件中删除了该属性，现在它可以正常工作了。

关键是确保在项目的任何文件中都不会多次声明此值。

【讨论】：

【解决方案22】：

obj\Debug\netstandard2.0\PacktLibrary.AssemblyInfo.cs(15,12): error CS0579: Duplicate 'System.Reflection.AssemblyConfigurationAttribute' attribute [c:\Users\John_Tosh1\Documents\C#8.0and.NetCore3.0\Code\Chapter05\PacktLibrary\PacktLibrary.csproj]
obj\Debug\netstandard2.0\PacktLibrary.AssemblyInfo.cs(16,12): error CS0579: Duplicate 'System.Reflection.AssemblyFileVersionAttribute' attribute [c:\Users\John_Tosh1\Documents\C#8.0and.NetCore3.0\Code\Chapter05\PacktLibrary\PacktLibrary.csproj]
obj\Debug\netstandard2.0\PacktLibrary.AssemblyInfo.cs(17,12): error CS0579: Duplicate 'System.Reflection.AssemblyInformationalVersionAttribute' attribute [c:\Users\John_Tosh1\Documents\C#8.0and.NetCore3.0\Code\Chapter05\PacktLibrary\PacktLibrary.csproj]
obj\Debug\netstandard2.0\PacktLibrary.AssemblyInfo.cs(18,12): error CS0579: Duplicate 'System.Reflection.AssemblyProductAttribute' attribute [c:\Users\John_Tosh1\Documents\C#8.0and.NetCore3.0\Code\Chapter05\PacktLibrary\PacktLibrary.csproj]
obj\Debug\netstandard2.0\PacktLibrary.AssemblyInfo.cs(19,12): error CS0579: Duplicate 'System.Reflection.AssemblyTitleAttribute' attribute [c:\Users\John_Tosh1\Documents\C#8.0and.NetCore3.0\Code\Chapter05\PacktLibrary\PacktLibrary.csproj]
obj\Debug\netstandard2.0\PacktLibrary.AssemblyInfo.cs(20,12): error CS0579: Duplicate 'System.Reflection.AssemblyVersionAttribute' attribute [c:\Users\John_Tosh1\Documents\C#8.0and.NetCore3.0\Code\Chapter05\PacktLibrary\PacktLibrary.csproj]

我相信我的库文件夹因无意创建另一个类库而损坏。我删除了库和所有相关文件，但问题仍然存在。我通过删除目录中的所有 bin 和 obj 文件夹找到了解决方法。之前构建没问题，但找到了一个具有相同 assemblyinfo.cs 文件的子文件夹。

【讨论】：

【解决方案23】：

此问题是 VS 2017 特有的参考冲突。

我通过简单地注释掉第 7 -14 行以及 AssemblyInfo.cs 页面底部的程序集版本代码解决了同样的错误

它删除了所有重复的引用，并且项目能够再次构建。

【讨论】：

【解决方案24】：

我刚从 .NET Framework 切换到 .NET Core 后出现错误。我的 Visual Studio 解决方案中有 2 个类库项目。我意识到其中 1 个项目有一个名为 AssemblyInfo.cs 的文件，而另一个项目没有该文件。该文件位于Properties 文件夹下。我只是删除了 Properties 文件夹，一切正常。

【讨论】：

【解决方案25】：

我一直在努力解决这个问题，但我的问题更容易解决。

我已将 OBJ 文件夹复制到“OBJ___”名称以进行一些编译测试。

所以，我不知道为什么，这个文件夹也在编译，造成程序集属性重复。

我只是删除了“OBJ___”文件夹，就可以编译成功了。

【讨论】：

【解决方案26】：

我刚刚通过将 repo 文件夹重命名为 re-cloning repo 来帮助团队成员解决了这个问题。这只是一个开发人员的问题，因为团队中的其他人都能够构建 master 而不会遇到此错误，因此我们知道问题不是源代码问题。

我们确实尝试删除 bin 和 obj 文件夹并执行git clean -xfd，但这些都没有解决问题。在这种情况下，从一个干净的 repo 副本重新开始就可以了。

【讨论】：

【解决方案27】：

我也一直在努力解决这个问题。在我的情况下，我把解决方案和项目放在同一个地方。所以我遇到了问题。在我选择了一个解决方案文件夹并将项目放在这个解决方案中之后，它就可以正常工作了。

【讨论】：

【解决方案28】：

对于遇到此问题的其他任何人，我为一位同事诊断它，她声称她没有更改任何内容，但结果是她不小心复制了一个代码文件夹并且没有意识到这一点。所以这很有趣。

课程：假设每个人都在撒谎。

【讨论】：

【解决方案29】：

就我而言，我的一位同事删除了一个用于测试目的的控制台应用程序，该应用程序与我们的 Api 放在同一目录中，然后提交给 Git。当我后来从 Git 中拉出时，控制台应用程序本身当然消失了，但它的 bin 和 obj 文件夹仍然存在，导致 AssemblyInfo.cs 文件同时存在于根应用程序目录和旧控制台应用程序的子目录中。只需删除旧控制台应用程序的 bin 和 obj 文件夹即可解决问题。

ASP.NET Core 3.1

【讨论】：

【解决方案30】：

我收到这些错误是因为我尝试将 obj 文件夹临时重命名为 obj_，然后它会自动包含在项目中。然后里面的assembly.cs就开始和后面生成的obj文件夹里面的那个打架了。

【讨论】：