How can I exclude one of referenced assemblies from code analyze?

Question

How can I exclude one of referenced assemblies from code analyze?

I receive an error during code analyze, and I think problem related to this assembly internal structure:

MSBUILD : error : CA0001 : The following error was encountered while reading module 'BusinessObjects.ReportEngine': Could not resolve type reference: [BusinessObjects.Enterprise.Sdk]BusinessObjects.Enterprise.Security.Internal.ISecuritySession.

I would like to exclude this assembly from code analyze to setup TFS code analyze check-in policy.

Could you please help?

Answer 1

There are quite a few code analysis rules that will not function correctly if they cannot access information from referenced assemblies, so excluding it entirely would be counter-productive.

Is there a copy of the referenced assembly in the target project's bin directory?  If so, does the BusinessObjects.Enterprise.Security.Internal.ISecuritySession actually appear in this copy of the assembly?  If there is no local copy of the assembly, are you referencing it from a well-known location?

Answer 2

Of course there is copy of dll into bin folder, and also all .netmodules required for this dll.

I can do nothing with this dll, and only i can made is to exclude this reference dll from analyze.

I use MS recomended minimal rules set. If this error related to specific rule(s) could you please tell which ones should be turned off?

Answer 3

There is no way to exclude a directly referenced DLL from use in analysis.  Analysis will fail if any referenced DLL cannot be resolved.  I'm sorry if this was unclear in my earlier post.

That said, even if you cannot modify the referenced assembly, there may still be a way to resolve your problem.  If you're interested in trying, could you please answer the following questions?

1. If you look at the referenced assembly in Reflector, can you see the problem type?  Is its name exactly "BusinessObjects.Enterprise.Security.Internal.ISecuritySession", including casing?
2. If you run an analysis of your target assembly in stand-alone FxCop, do you get the same error?  Do you get asked to provide a location for any indirectly referenced assembly?

Answer 4

Stand-alone version of FxCop generate same error.

Ok. Let's try to understand what's wrong.
In our project we use BusinessObjects Enterprise XI SDK

And we use method
public CrystalDecisions.Enterprise.EnterpriseService GetService(string serviceName) from CrystalDecisions.Enterprise.Framework.dll
Next we use  public object Interface { get; } Member of CrystalDecisions.Enterprise.EnterpriseService
and cast Interface property to IReportEngine interface declared in BusinessObjects.ReportEngine.dll
Next our code works with this interface.

Using reflector, i found that we use implementation of this interface WIReportEngine, declared in BusinessObjects.ReportEngine.WI.dll
This class has internal IServerSession ServerSession { get; } property.
Implementation of this interface located in same dll in class internal sealed class CEServerSession : IServerSession
This class has property public ISecuritySession SecuritySession { get; }

ISecuritySession declared in BusinessObjects.Enterprise.Sdk.netmodule module, located in BusinessObjects.Enterprise.Sdk.dll
I found 2 impelmentations of this interface in same module, but don't really know which one used.

I can see all of this classes using Reflector.

May be problem related to multifile structure of  BusinessObjects.Enterprise.Sdk.dll assembly?

Answer 5

I can repro the problem with loading of an interface from a separate module file in an indirectly referenced assembly.  (The internal vs. public visibility of the interface does not seem to be relevant.)  Unfortunately, I can't see any way to address the core problem other than submitting a bug report at https://connect.microsoft.com/visualstudio/feedback.  On the good news front, I can't reproduce the problem in VS 2010 beta 2.

It might be worth trying to move the code that work with the IReportEngine to a separate assembly on which you do not run code analysis.  However, you would probably need to do some fiddling to ensure that FxCop does not run into the same problem when it tries to analyze the assembly that uses the split-off code.

Answer 6

Thank you.
Bug 520967 created.