项目<PROJECT NAME>不是最新的。缺少输入文件'netframework，version = v4.0，profile = client.assemblyattributes.cs'。

Question

我有一个包含50多个项目的sln文件，在最近转移到VS2013后，每次按F5进行编译时，即使我只是执行了一次构建，它也会重新构建所有项目。诊断显示，每个项目都被标记为不是最新的，并出现以下错误：

Project <PROJECT NAME> is not up to date. Missing input file 'c:\users\USER\appdata\local\temp\2\.netframework,version=v4.0,profile=client.assemblyattributes.cs

我已经阅读了以下主题：

• 在Visual Studio 2010中，为什么会创建.NETFramework，Version = v4.0.AssemblyAttributes.cpp文件，我能禁用它吗？

• https://social.msdn.microsoft.com/Forums/vstudio/en-US/15d65667-ac47-4234-9285-32a2cb397e32/migration-from-vs2008-to-vs2010-and-netframeworkversionv40assemblyattributescpp?forum=vcgeneral

但建议在proj文件中添加以下行：

  <Target Name="GenerateTargetFrameworkMonikerAttribute" />

我尝试了但未成功。按照微软的建议来抑制警告也行不通，因为项目仍然会保持“不是最新的”状态。

我正在使用VS2013、C#和VB项目。但是，使用相同的项目和VS2012时，不会引发此类错误，并且项目是最新的。

有什么建议吗？

更新：或许值得提及的是，我的解决方案中有一些构建定义，其中所有项目都是为AnyCPU构建的，除了一个：http://screencast.com/t/fuw9k4IubN

- checho

---

两个问题，您的所有项目是否都设置为在配置管理器设置中构建（右键单击解决方案->配置管理器）？您是否使用任何在以前版本的.NET下编译的第三方库或DLL文件？我指的是任何不在您的解决方案中编译的库，即使它们来自您公司的其他项目？我之前也遇到过同样的问题，原因是我们使用的静态库是在以前版本的VS下编译的。 - Semicolons and Duct Tape

1. 是的，所有项目都已设置为构建。
2. 我认为我在项目中没有无法构建的外部库。

- checho

Answer 1

我之前也遇到了同样的问题，最终通过更新*.csproj文件中的ToolsVersion属性来解决：
将ToolsVersion="4.0"替换为ToolsVersion="16.0"
（我使用的是Visual Studio 2019，在内部是v16.x）。

- picrap

---

非常奇怪，这对我起作用了。我会尽力抽出时间使用 该项目转换工具。 - sebkraemer

你真是个救命恩人。我自己也遇到了这个问题。我的ToolsVersion是15.0，将其更改为16.0效果很好。我不得不对我所有的21个项目都进行这样的更改。我想这是在我升级到Visual Studio 2019 v16.6.1时开始发生的。我想我跳过了v16.6。 - Greg Veres

我的工具版本是12.0，将其更改为16.0后，所有项目都被彻底解决了。这个好建议可以每天至少节省我20分钟的时间。 - jon morgan

这个解决方案在VS2015的解决方案上也有效。谢谢！ - Danimal111

Answer 2

<Target Name="GenerateTargetFrameworkMonikerAttribute" />

这并不是一个好主意，它实现了你试图解决问题的完全相反的效果。它强制MSBuild创建AssemblyAttributes.cs文件，不可避免地需要重新构建项目，因为该文件是新的。你发现的问题与此完全不同，那些是C++程序员试图应对VS2010中的新链接器警告。他们讨厌从不属于其项目的文件中出现的警告。嗯，我们都是这样。那个SO问题上标记的答案非常邪恶，顺便说一句，那个人发布了一个更好的答案:)

Missing input file 'c:\users\USER\appdata\local\temp\2\.netframework...

这条信息中有一个信号，请注意路径名中的\2子目录的存在。这是一个很大的警告信号，它不是正常的。这个自动生成的.cs文件通常位于TEMP目录内，而不是该文件夹的子目录中。这肯定与你真正的问题有关。

MSBuild没有做任何特殊处理，只是使用System.IO.Path.GetTempPath()生成文件夹名称。这个方法也不是特殊的，它只是将工作委托给GetTempPath() winapi函数。因此，诊断结果是在这台构建机上，该操作系统函数有时会生成一个奇怪的路径，选择TEMP文件夹的子目录。并且它并不总是生成相同的路径，从而导致您的项目被重新构建。

至少有一种好的理论可以解释这种行为，由评论者@Darran Rowe提到this blog post：

不，这是终端服务在工作。当您通过远程桌面登录时，Windows会将登录会话的临时目录设置为%LOCALAPPDATA%\Temp\<session id>。

听起来熟悉吗？

- Hans Passant

---

谢谢您的回复，我发现这篇帖子很有用，因此我点了个赞。我非常自信之前测试过这个标志，但它并没有起作用。我曾使用VS2015企业版，现在使用的是专业版，这可能是唯一的区别，但这不应该有影响。不确定为什么今天它起作用了。 关于终端服务的问题，我经常远程登录到我的机器上，并且有时会构建这个特定的解决方案，所以这可能是原因，但是在这个页面上建议重新创建已删除的文件夹的解决方案并没有帮助。 - checho

“我经常远程记录到我的机器上”是一个非常简单易懂的解释。不过听起来你似乎没有理解到重点，使用远程桌面的一个副作用是整个解决方案需要被重新构建，因为TEMP目录不一样。每次重新连接时都会获得主机机器上不同的会话ID，所以这很可能发生。一个简单的解决方法是启动命令提示符，覆盖TEMP环境变量并启动devenv.exe。但这样做有风险，因为它可能会干扰其他人连接该机器。” - Hans Passant

据我所知，TEMP目录仅在远程会话期间不同。因此，如果我曾经在远程会话期间使用过该项目，由于它正在使用会话的子目录，该项目将不断重建。但是，当我在本地机器上时，TEMP目录是正确的，因此如果我从我的机器启动项目，它不应干扰TEMP中的子文件夹，而应使用正确的文件夹，但实际上并没有。此外，手动创建\1文件夹也没有帮助。 - checho

当以管理员身份运行VS2013时，会发生类似的情况：使用%LOCALAPPDATA%\Temp\1文件夹并且项目总是被重建。如果没有提升权限，一切都正常工作。 - Aleksandr

这篇文章也对此提供了一些见解。 - Jimenemex

Answer 3

这对我有用：

关闭 Visual Studio 并从项目中删除 .sou 文件。

- Dongolo Jeno

Answer 4

尝试删除隐藏的.vs文件夹，该文件夹与解决方案文件位于同一文件夹中。

- Lumo

Answer 5

我曾经遇到过同样的错误，解决方法是将项目从我的解决方案中移除并重新添加。这很麻烦，因为你还需要重新添加项目之间的引用。

- user2882190