C++ 在 Visual Studio 2010 中，为什么会创建 .NETFramework,Version=v4.0.AssemblyAttributes.cpp 文件，我可以禁用它吗？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/3104356/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
In Visual Studio 2010 why is the .NETFramework,Version=v4.0.AssemblyAttributes.cpp file created, and can I disable this?
提问by Michael Repucci
I've recently upgraded to Visual Studio 2010. Now when I build projects I get a line that reads:
我最近升级到了 Visual Studio 2010。现在当我构建项目时，我看到一行：
1> .NETFramework,Version=v4.0.AssemblyAttributes.cpp
I've learned that this is the result of the new build engine, msbuild.exe, but this file is actually auto-created and placed in my local temp directory (c:\Documents and Settings\me\Local Settings\Temp). Does anyone know why this file is created, and whether I can disable its creation?
我了解到这是新构建引擎 msbuild.exe 的结果，但该文件实际上是自动创建的，并放置在我的本地临时目录 (c:\Documents and Settings\me\Local Settings\Temp) 中。有谁知道为什么创建这个文件，以及我是否可以禁用它的创建？
BTW, it doesn't seem to have anything useful in it, to my mind. See below:
顺便说一句，在我看来，它似乎没有任何用处。见下文：
#using <mscorlib.dll>
[assembly: System::Runtime::Versioning::TargetFrameworkAttribute(L".NETFramework,Version=v4.0", FrameworkDisplayName=L".NET Framework 4")];
And occasionally, as reported http://social.msdn.microsoft.com/Forums/en-US/vcgeneral/thread/15d65667-ac47-4234-9285-32a2cb397e32, it causes problems. So any information on this file, and how I can avoid its auto-creation would be much appreciated. Thank you!
有时，正如http://social.msdn.microsoft.com/Forums/en-US/vcgeneral/thread/15d65667-ac47-4234-9285-32a2cb397e32报道的那样，它会导致问题。所以关于这个文件的任何信息，以及我如何避免它的自动创建，将不胜感激。谢谢！
采纳答案by Brian
This is common to all languages (C#, VB, and F# have something similar too).
这对所有语言都是通用的（C#、VB 和 F# 也有类似的东西）。
One way you can disable it is to override the GenerateTargetFrameworkMonikerAttribute target thusly:
禁用它的一种方法是覆盖 GenerateTargetFrameworkMonikerAttribute 目标：
<!-- somewhere after the Import of Microsoft.somelanguage.targets -->
<Target Name="GenerateTargetFrameworkMonikerAttribute" />
in your project file.
在您的项目文件中。
回答by Hans Passant
Take a look at c:\program files\msbuild\microsoft.cpp\v4.0\microsoft.buildsteps.targets. It contains the GenerateTargetFrameworkMonikerAttribute target, that's the one that generates the file. The Condition element determines when it runs, GenerateTargetFrameworkAttribute is the value. That will always be true if the project settings ask for a /clr build. The comment in the target is verymisleading, the hoopla about precompiled header files has nothing to do with the purpose of the target.
查看 c:\program files\msbuild\microsoft.cpp\v4.0\microsoft.buildsteps.targets。它包含 GenerateTargetFrameworkMonikerAttribute 目标，即生成文件的目标。Condition 元素确定它何时运行，GenerateTargetFrameworkAttribute 是值。如果项目设置要求 /clr 构建，则始终如此。目标中的注释非常具有误导性，关于预编译头文件的喧嚣与目标的目的无关。
The [TargetFrameworkAttribute] it generates in the .cpp helper file is important, that tells the CLR on the machine on which the program runs what minimum version of .NET needs to be present to successfully execute the program. Its primary use is to automatically launch the installerfor the .NET version that's needed, very nice feature.
它在 .cpp 帮助文件中生成的 [TargetFrameworkAttribute] 很重要，它告诉运行程序的机器上的 CLR 需要存在什么最低版本的 .NET 才能成功执行程序。它的主要用途是自动启动所需的 .NET 版本的安装程序，这是一个非常好的功能。
LNK4221 is common and has no teeth, you can ignore it. Sadly the linker does not provide a documented way to suppress warnings, basic issue is that it cannot be specific enough to suppress onlythis one. Suppressing the helper .cpp would require editing the .targets file and breaks the auto-install feature, I cannot recommend that.
LNK4221很常见，没有牙齿，可以无视。可悲的是，链接器没有提供一种记录的方式来抑制警告，基本问题是它不能足够具体以仅抑制这个警告。抑制助手 .cpp 需要编辑 .targets 文件并破坏自动安装功能，我不建议这样做。
回答by swaminathan
I resolved this problem with the following steps:
我通过以下步骤解决了这个问题：
- Clean the solution
- Close the solution
- Type in run command
%temp%, delete all the files - Open the solution by clicking the project solution file from the folder where the project has been saved.
Do a rebuild on one of the projects. Then close Visual Studio 2010 (yes the entire development environment), and then re-open the solution file.
It seems that the rebuild, recreates the missing file, but Visual Studio doesn't notice it, so you have to close it down and re-open it for it to properly see the file again.
- 清洁溶液
- 关闭解决方案
- 输入运行命令
%temp%，删除所有文件 - 通过单击保存项目的文件夹中的项目解决方案文件打开解决方案。
对其中一个项目进行重建。然后关闭Visual Studio 2010（是的整个开发环境），然后重新打开解决方案文件。
似乎重建会重新创建丢失的文件，但 Visual Studio 没有注意到它，因此您必须关闭它并重新打开它才能再次正确地看到该文件。
回答by Ruben Bartelink
Firstly, @Brian's answer remedies the condition and I issued 4x+1s for the other helpful answers which assisted in a speedy diagnosis and resolution of an issue I experienced.
首先，@Brian 的回答解决了这个问题，我为其他有用的回答发布了 4x+1s，这有助于快速诊断和解决我遇到的问题。
Wanted to include a dump of a problem I diagnosed in my context based on this.
想要包含我基于此在上下文中诊断的问题的转储。
This feature synthesizes a source file in the project's language which creates an assembly:attribute into the compilation stream.
此功能以项目语言合成一个源文件，assembly:在编译流中创建一个属性。
This file/process is necessarywhen WAS or other hosting environments need to be able to infer a target framework and other such cases. Example MSDN article (relating to usage with WAS). It's only an attribute, so it's inert and not much to worry about...
当 WAS 或其他托管环境需要能够推断目标框架和其他此类情况时，此文件/进程是必需的。MSDN 文章示例（与 WAS 的使用有关）。它只是一个属性，所以它是惰性的，不用担心......
In cases where no such reliance will come into play, it gets more interesting. Aside from being redundant, making larger binaries and heating the processor, in TeamCity, the cleaning procedures when configured for incremental builds remove this file before a re-build. However the unfortunate side effect is that the build's dependency checking then incorrectly infers that a rebuild is necessary as illustrated by this sample message when turning the logging up by specifying /v:d[etailed]:-
在没有这种依赖发挥作用的情况下，它会变得更有趣。除了冗余、制作更大的二进制文件和加热处理器之外，在 TeamCity 中，为增量构建配置的清理过程会在重新构建之前删除此文件。然而，不幸的副作用是，当通过指定/v:d[etailed]来打开日志记录时，构建的依赖项检查会错误地推断需要重建，如本示例消息所示：-
[CoreCompile] Input file "C:\BuildAgent\temp\buildTmp.NETFramework,Version=v4.0,Profile=Client.AssemblyAttributes.cs" is newer than output file "bin\Debug\DLLNAME.xml".
[CoreCompile] 输入文件“C:\BuildAgent\temp\buildTmp.NETFramework,Version=v4.0,Profile=Client.AssemblyAttributes.cs”比输出文件“bin\Debug\DLLNAME.xml”新。
Bottom line is that CSC gets invoked inappropriately (and in our case there are significant downstream effects from there)
底线是 CSC 被不恰当地调用（在我们的例子中，有显着的下游影响）
Other notes:
其他注意事项：
Must look in the MS Targets to see if this only applies to particlar Profiles [as alluded to in @AlainA's answer] (my specific case was a use of .NET 4.0 Client Profile)
As illustrated in the above message, one subtlety that may be involved is the presence or absence of XML docs, which is the case in my context.
必须查看 MS Targets 以查看这是否仅适用于特定配置文件 [如@AlainA 的回答中所提到的]（我的具体情况是使用 .NET 4.0 客户端配置文件）
如上述消息所示，可能涉及的一个微妙之处是 XML 文档的存在与否，在我的上下文中就是这种情况。
回答by dan
The file is there to embed TargetFrameworkMoniker .NET assembly attribute. That is to (in future) help hosts work correctly with the appropriate CLR. (Sorry for vagueness I can't remember someone else is the expert). Ie', there's actually a reason for it :-)
该文件用于嵌入 TargetFrameworkMoniker .NET 程序集属性。也就是说（将来）帮助主机使用适当的 CLR 正常工作。（抱歉含糊不清，我不记得其他人是专家）。即'，实际上是有原因的:-)
I don't know why there's a warning -- looking into it.
我不知道为什么会有警告 - 正在调查它。
Dan/MSBuild
丹/MSBuild
回答by AlainA
Close VS
关闭VS
Open each .vbproj file with notepad and remove the following line : <TargetFrameworkProfile />
用记事本打开每个 .vbproj 文件并删除以下行：<TargetFrameworkProfile />
It's over !
结束了 ！
