22

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!

Michael Repucci
  • 1,633
  • 2
  • 19
  • 35

6 Answers6

19

This is common to all languages (C#, VB, and F# have something similar too).

One way you can disable it is to override the GenerateTargetFrameworkMonikerAttribute target thusly:

<!-- somewhere after the Import of Microsoft.somelanguage.targets -->
<Target Name="GenerateTargetFrameworkMonikerAttribute" />

in your project file.

Cody Gray - on strike
  • 239,200
  • 50
  • 490
  • 574
Brian
  • 117,631
  • 17
  • 236
  • 300
  • 2
    I edited the vcxproj file by hand and added that line, as you suggested, and it worked. But is there a setting or place to add that in the project property pages? And even more importantly, is it safe? What am I losing? – Michael Repucci Jun 25 '10 at 14:19
  • 2
    See here for what the TargetFrameworkAttribute feature supports: http://msdn.microsoft.com/en-us/library/dd456789.aspx – Brian Jun 25 '10 at 16:37
  • Interesting. Since the project doesn't contain any WCF, IIS, or Web anything, I guess it'd be safe to override as you suggested. But I'm rather surprised that this ever came up. Any ideas why it might have arisen? – Michael Repucci Jun 25 '10 at 17:35
  • I agree it's safe to omit. I know nothing about the C++ linker, so I've no clue about the warning. – Brian Jun 25 '10 at 19:19
  • +1 for the very important comment about placement - def needs to go late on in the file. See also my answer from some more detail appropriate to my context – Ruben Bartelink Jun 30 '12 at 00:28
  • I love this hack - thanks (using it in a VSMonoTouch build now) – Stuart Sep 25 '12 at 11:53
  • 6
    Unfortunately, disabling the *GenerateTargetFrameworkMonikerAttribute*, as proposed above, has the side effect, that none of the C# projects ever become up to date again. If you set the output verbosity of Visual Studio to *Diagnostic*, you'll get the following line as first entry of your build log if you build a C# Project: > Project 'FooBar' is not up to date. Missing input file > 'c:\users\\appdata\local\temp\.netframework,version=v4.5.assemblyattributes.cs'. – Dr. Frank Heimes Sep 17 '13 at 15:04
13

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 very misleading, the hoopla about precompiled header files has nothing to do with the purpose of the target.

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 installer for the .NET version that's needed, very nice feature.

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 only this one. Suppressing the helper .cpp would require editing the .targets file and breaks the auto-install feature, I cannot recommend that.

Community
  • 1
  • 1
Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
  • Thank you very much for all that information! Is there somewhere that I could read up more about msbuild and these XML files it uses that is perhaps clearer than http://msdn.microsoft.com/en-us/library/0k6kkbsd.aspx? I couldn't even find the GenerateTargetFrameworkMonikerAttribute target in the MSDN documentation. As for the warning, my company has a policy that builds must be warning free, as they often point to code stink. – Michael Repucci Jun 25 '10 at 14:28
  • No, these are implementation details, not unlike the internals of link.exe. They just happen to be readable, not a bad thing. Getting link.exe completely warning-free is difficult, you cannot suppress warnings. Nor can you fail the build with them so few programmers care. Maybe VS2010 is not quite ready for prime time at your company. Post to connect.microsoft.com to ask for feature changes. – Hans Passant Jun 25 '10 at 14:34
  • +1 for the guesses. @Brian's comment on his answer provides a link to what it's for: http://msdn.microsoft.com/en-us/library/dd456789.aspx – Ruben Bartelink Jun 30 '12 at 00:27
  • For Visual Studio 2013 I successfully suppressed the LNK4221 warning by adding `/IGNORE:4221` to the Additional Options box of the Project Properties->Linker->Command Line. Be aware that suppresses all occurrences of that warning, but that was okay for me. – GrahamS May 13 '20 at 17:46
5

I resolved this problem with the following steps:

  1. Clean the solution

  2. Close the solution

  3. Type in run command %temp%, delete all the files

  4. Open the solution by clicking the project solution file from the folder where the project has been saved.

  5. 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.

Community
  • 1
  • 1
swaminathan
  • 51
  • 1
  • 1
  • As far as I know the Temp folder may contain files that are required by currently running applications or files that will be required next time Windows (or application that created it) starts. So it is not safe to delete all the files from %temp%. – Artemix Jul 22 '13 at 09:55
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.

Ruben Bartelink
  • 59,778
  • 26
  • 187
  • 249
1

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

I don't know why there's a warning -- looking into it.

Dan/MSBuild

dan
  • 56
  • 1
1

Close VS

Open each .vbproj file with notepad and remove the following line : <TargetFrameworkProfile />

It's over !

AlainA
  • 11
  • 1