5

I want to remove AssemblyInfo.cpp, because of some metadata errors that sometimes come up.

Is AssemblyInfo.cpp useful for anything? Or can it be removed without any problem?

demoncodemonkey
  • 11,730
  • 10
  • 61
  • 103

3 Answers3

4

I've discovered one distinction for this file: it has to do with values reported under calls to Assembly.GetReferencedAssemblies. I was working on tracking version numbers of our binaries from our SVN repository by embedding the revision numbers into them. Initially I too was updating AssemblyInfo.cpp and found nothing reported in the file property details tab for the binary. It seemed this file did nothing for me in terms of updating those details, which was not the case with similar updates to a csproj's AssemblyInfo.cs. Why the difference right?

Now in one such csproj we happen to reference a vcxproj and that csproj dumps to a log the versions of all its referenced assemblies using the .NET Assembly.GetReferencedAssemblies method. What I discovered was that the number that was being reported in that log was not the vcxproj's version as given by the VS_VERSIONINFO resource I added (which does get the version details into the file properties details tab). Instead the number reported was actually matching that defined in the AssemblyInfo.cpp.

So for vcxproj files it looks like VS_VERSIONINFO is capable of updating the contents you find under the file properties details tab but AssemblyInfo.cpp is capable of exposing the version to GetReferencedAssemblies. In C# these two areas of reporting seem to be unified. Maybe there's a way to direct AssemblyInfo.cpp to propagate into the file details in some fashion, but what I'm going to wind up doing is duplicating the build info to both locations in a prebuild step. Maybe someone can find a better approach.

bluish
  • 26,356
  • 27
  • 122
  • 180
jxramos
  • 7,356
  • 6
  • 57
  • 105
2

So far I never had the AssemblyInfo.cpp in my managed c++ dlls, so I don't think it is necessary.

(I just added the file to have version information for my c++ dlls).

Sam
  • 28,421
  • 49
  • 167
  • 247
1

Why not just fix the errors? On that note, what errors are you getting?

This file provides information such as a version number which is definitely needed in order to use the assembly you have built.

bluish
  • 26,356
  • 27
  • 122
  • 180
NotMe
  • 87,343
  • 27
  • 171
  • 245
  • The errors are described in http://stackoverflow.com/questions/810827/lnk2022-metadata-operation-failed-driving-me-insane ... as for how the file is "definitely needed", well it seems to work fine without it?!? – demoncodemonkey May 01 '09 at 09:58
  • Without that information the compiler can't determine if the assembly is 1. the right one and 2. out of date or not. The problem you linked to boils down to a mismatch between builds of the assembly. By neutering it you no longer get the mismatch error because the compiler can't tell that there is a difference. – NotMe May 01 '09 at 14:25
  • So, in effect, you haven't solved the problem. Instead you've just hidden it. – NotMe May 01 '09 at 14:26
  • I'm not so sure. With or without the assemblyinfo, if I make a significant change to the shared DLL, the referencing DLL gets rebuilt, and with an unsignificant change the referencing DLL does not get rebuilt. So I can't see any difference in that respect, other than that nonsensical error disappears. – demoncodemonkey May 01 '09 at 14:58