3

We have a lot of assemblies that contain internal classes which we are unit-testing by using InternalsVisibleTo to make the internal classes visible to the Unit Test assembly.

This works fine, but the problem is that as soon as you use InternalsVisibleTo, it prevents the Code Analysis CA1812 warning (Avoid uninstantiated internal classes).

It also prevents CA1811: "Avoid uncalled private code".

I've done some investigation, and I've found quite a lot of unused internal classes that we weren't being warned about because of this.

My solution for the moment is to hand-edit the "AssemblyInfo.cs" file in each assembly to temporarily comment-out the InternalsVisibleTo so that I can compile just that project and discover unused internal classes.

This is a huge hassle, and of course if something like that doesn't get done automatically, it frequently doesn't get done at all.

A solution would be to be able to tell Code Analysis to ignore the InternalsVisibleTo attribute.

Does anyone know if such a possibility exists?

Matthew Watson
  • 104,400
  • 10
  • 158
  • 276
  • Disregard my comment. I think I misread your question. – hawkke Oct 16 '13 at 13:56
  • The MSDN article for CA1812 specifically mentions this. And offers a workaround, use FxCop instead. – Hans Passant Oct 16 '13 at 14:03
  • @HansPassant Thanks, but unfortunately using FxCop is going to be too much of a major change. We have 530 assemblies I'd have to change to use FxCop. :( – Matthew Watson Oct 16 '13 at 14:22
  • Hmm, no, changing the assemblies doesn't make any sense. Creating the FxCop project shouldn't take you more than a minute, just Shift+Click the assemblies. Doesn't sound like you made any real effort. – Hans Passant Oct 16 '13 at 14:29
  • (I also added `It also prevents CA1811: "Avoid uncalled private code".` to my question) – Matthew Watson Oct 16 '13 at 14:30
  • @HansPassant Does FxCop integrate with the "Code Analysis" tab of the Project settings? (I discovered that it can use the same rulesets, so that part's ok) If so, it might be usable, but otherwise it's going to be a major hassle. Also "just shift-click the assemblies" isn't as straightforward as you think - they are spread out through ~300 solutions! – Matthew Watson Oct 16 '13 at 14:32
  • Yes, I've done some more looking and it doesn't seem that there's a default Check-In policy for FxCop like there is for the built-in Code Analysis. We have that check-in policy enabled for our TFS source control, so it looks like a fairly big change to use FxCop instead. (I expect there's a way to do it, I'll have to do a bit more research though) – Matthew Watson Oct 16 '13 at 14:41
  • @HansPassant Could you elaborate a bit about how to use the external FxCop like that, or point to a link that explains it? I'm having the _exact_ same situation here and if I could at least use the external tool on the build machine I'd be able to catch those warnings. At the moment, we are using the `Enable code analysis on build" for each project in the Release configuration. – julealgon Mar 27 '15 at 21:36
  • @HansPassant I actually don't even know what you are talking about here: `Creating the FxCop project ...` I never heard of a 'FxCop project' before. – julealgon Mar 27 '15 at 21:37

1 Answers1

2

Try this:

#ifdef CODE_ANALYSIS
#else
[InternalsVisibleTo(...)]
#endif
Kris Vandermotten
  • 10,111
  • 38
  • 49
  • Alas that doesn't help - the unit test project won't build without the InternalsVisibleTo. – Matthew Watson Oct 16 '13 at 14:24
  • That is obviously true, but the Unit Test project doesn't have to build for you to run Code Analysis on your library, does it? – Kris Vandermotten Oct 16 '13 at 15:16
  • Now I understand. You probably have "Enable Code Analysis on Build" turned on, right? Can you turn it off and run Code Analysis manually? Note that this is a good idea anyway, as the attribute to suppress code analysis warnings is conditional on this constant as well. – Kris Vandermotten Oct 16 '13 at 15:21
  • We have a check-in policy that requires Code Analysis to be turned on, so we cannot turn it off. However, I could create a build configuration which sets another #define which I use to control it, so I could just choose the appropriate configuration to run code analysis without InternalsVisibleTo without having to edit code. I think that would be an ok workaround, so I'll mark this as the answer. – Matthew Watson Oct 16 '13 at 15:36