Alex Rivera | Logout

In Visual Studio 2010 why is the .NETFramework,Version=v4.0.AssemblyAttributes.cpp file created, and can I disable this?

Asked 2010-06-23T18:17:54.233
25

I've recently upgraded to Visual Studio 2010. Now when I build projects I get a line that reads:

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?

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!

.net c++ visual-studio-2010
Edit
Report

1 Answer

2

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.

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.

This file/process is necessary when 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...

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]:-

[CoreCompile] Input file "C:\BuildAgent\temp\buildTmp.NETFramework,Version=v4.0,Profile=Client.AssemblyAttributes.cs" is newer than output file "bin\Debug\DLLNAME.xml".

Bottom line is that CSC gets invoked inappropriately (and in our case there are significant downstream effects from there)

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.

    answered 2012-06-30T00:40:40.573

Your Answer