我有一个项目，在编译时产生以下错误:
重复'AssemblyVersion'属性
我检查了文件AssemblyInfo.cs，看起来没有重复。
我在MSDN上找到了这篇文章，它解决了一个类似的问题，并按照这篇文章中的建议解决了这个问题。
有人能告诉我这是怎么回事吗?这种情况是否只发生在有两个或多个类名称相似的项目的情况下?还是其他原因?
当前回答
以我为例，我的一个同事删除了一个用于测试的控制台应用程序，它与我们的Api放在同一个目录下，然后提交给Git。 当我后来从Git中退出时，控制台应用程序本身当然已经消失了，但它的bin和obj文件夹仍然在那里，导致AssemblyInfo.cs文件出现在根应用程序目录和旧控制台应用程序的子目录中。简单地删除旧控制台应用程序的bin和obj文件夹就解决了这个问题。
ASP。NET Core 3.1
其他回答
我也有同样的错误，它在程序集版本和程序集文件版本下划线，所以阅读Luqi答案，我只是把它们作为注释添加了进去，错误就解决了
// 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")]
如果我在Visual Studio 2017中编译项目，然后尝试用. net Core用命令行命令“dotnet run”重建并运行它，通常会发生这种情况。
简单地删除所有“bin”和“obj”文件夹——包括在“ClientApp”内部和直接在项目文件夹中——允许. net Core命令“dotnet run”重新构建并成功运行。
对我来说，AssembyInfo.cs和SolutionInfo.cs有不同的值。所以也检查一下这些文件。我只是把其中一个版本删除了。
当我的主项目与解决方案位于同一文件夹中时，我就遇到了这个问题，然后我在同一解决方案中有一个位于子文件夹中的独立项目，并且该独立项目使用主项目作为参考。这导致主项目检测到子文件夹bin & obj文件夹创建重复的引用。
以我为例，我的一个同事删除了一个用于测试的控制台应用程序，它与我们的Api放在同一个目录下，然后提交给Git。 当我后来从Git中退出时，控制台应用程序本身当然已经消失了，但它的bin和obj文件夹仍然在那里，导致AssemblyInfo.cs文件出现在根应用程序目录和旧控制台应用程序的子目录中。简单地删除旧控制台应用程序的bin和obj文件夹就解决了这个问题。
ASP。NET Core 3.1
