20

Related to this question is, how does the generation of the AssemblyInfo work?

I have been putting InternalsVisibleTo in the file of the first class of an assembly where I realize that it will be useful. It seems more appropriate to be in AssemblyInfo with the other assembly attributes, but I wouldn't want it to be overwritten inadvertently.

So, where should it go?

Lauren Rutledge
  • 1,195
  • 5
  • 18
  • 27
Berryl
  • 12,471
  • 22
  • 98
  • 182

3 Answers3

32

It is 2022 and with the introduction of SDK-style projects, another option to put the InternalsVisibleTo attribute is the project file. Add the following lines to your *.csproj file:

<ItemGroup>
  <InternalsVisibleTo Include="ProjectName.Tests" />
</ItemGroup>

Another case that can be useful is to use parametric project names like that:

<ItemGroup>
    <AssemblyAttribute Include="System.Runtime.CompilerServices.InternalsVisibleTo">
      <_Parameter1>$(MSBuildProjectName).Tests</_Parameter1>
    </AssemblyAttribute>
</ItemGroup>

Not sure but I assume you can use this feature for .NET 5+.

Lastly, I agree with @Tim Lloyd. Putting InternalsVisibleTo attribute in a central location (either in AssemblyInfo.cs or project file) in the assembly improves discoverability and eventually this is an assembly-level attribute.

Mustafa Özçetin
  • 1,893
  • 1
  • 14
  • 16
  • This question is 12 years old and it has an accepted answer – MD Zand Nov 29 '22 at 16:18
  • 12
    True but it is not uncommon in SO to provide up to date or more practical ways with new features or APIs. For instance, you can see tons of answers years after the original questions that are re-answered with the intro of C# async feature. Ultimately, this question is still relevant and the .NET 5+ way of using InternalsVisibleTo attribute is putting it in the project file. (And no need to create the AssemblyInfo.cs class.) – Mustafa Özçetin Dec 09 '22 at 08:13
  • It's a good indicator that, in about half a year, this answer caught up with the votes of the accepted answer. While that answer remains absolutely valid, we're always looking for more elegant and modern ways of doing things. – ANeves Jul 06 '23 at 14:40
22

Assembly-level attributes can appear in any code file; however, by convention they are placed in the AssemblyInfo file. This aids discoverability, as this is where people (or tools) will commonly look when investigating issues.

I have been using InternalsVisibleTo for many years and placing it in the AssemblyInfo file. I have never known it to be overwritten by tools i.e. Visual Studio (all editions).

General Grievance
  • 4,555
  • 31
  • 31
  • 45
Tim Lloyd
  • 37,954
  • 10
  • 100
  • 130
5

AssemblyInfo is really just a way of organising your Assembly-wide attributes.

There's no reason you can't put all your code in one giant .cs file, and pass it to MSBuild. You'll get the same end result.

I've had reason to have multiple AssemblyInfo files - AssemblyInfo.cs was specific to each assembly, but CommonAssemblyInfo was shared amongst many assemblies, and contained things like Version numbers and soforth that were generated by the build system.