Member access call does not compile but static call does

Question

So today I faced interesting problem while trying to build our company solution and I wanted to ask you guys do you know why is this happening. I've been told that it might be from my machine/visual studio because other people did not have same problem.

So we have a method in project A:

private static string RpcRoutingKeyNamingConvention(Type messageType, ITypeNameSerializer typeNameSerializer)
{
   string queueName = typeNameSerializer.Serialize(messageType);

   return messageType.GetAttribute<GlobalRPCRequest>() != null || AvailabilityZone == null
        ? queueName
        : queueName + "_" + AvailabilityZone;
}

where GetAttribute<GlobalRPCRequest>() is defined in public static class ReflectionHelpers

 public static TAttribute GetAttribute<TAttribute>(this Type type) where TAttribute : Attribute;

then we have project B which have method:

public static string GetAttribute(this XElement node, string name)
{
   var xa = node.Attribute(name);
   return xa != null ? xa.Value : "";
}

I have to point out that we have reference to project B in project A. Now what happens is that when I try to build I get compile error:

Error 966 The type 'System.Xml.Linq.XElement' is defined in an assembly that is not referenced. You must add a reference to assembly 'System.Xml.Linq, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'. D:\Repositories\website\website\submodules\core\src\A\Extensions\Extensions.cs 37 13 A

Whats happening is that compiler thinks that I am actually using GetAttribute method from project B(in my opinion!). Why this is happening? Since when I try to navigate to GetAttribute VS leads me to the right method (the one that is in ReflectionHelpers). Could it be because of the reflection? NOTE: I fixed this issue by calling the method statically or adding reference to System.Xml.Linq in my project A, but I am curious of the strange behavior of VS/syntax-checking feature.

Sigma

Are you referencing the assembly containing XElement? Cuz its telling you thats the problem; no method names mentioned. I mean did you try adding System.xml.linq? – Caliber

Yes , I tried this actually fix the problem , but as I said we found the solution of this , but the strange behavior remains and I got curious. Plus adding reference to System.XML.LINQ it DOES solve the problem, but it is strange that compiler gets confused before that cause it is obvious(well maybe not that obvious to him) that I do not use any XElements. – Sigma

But you do in project B? – Caliber

No, I added the reference in project A. Project B was building with no problem. – Sigma

Ah. Interesting. Editing what you told me in these comments into the question would greatly clarify for others – Caliber

I am not sure but if you say so... its not like I am asking for solution of the error rather than asking for an explanation of the strange behavior. What does it matter how exactly I fixed it? – Sigma

??? It might spark some ones memory idk. I see it as potentially useful; you dont. Its your question. – Caliber

https://mcmap.net/q/1168763/-extension-method-call-does-not-compile-but-static-method-call-to-same-code-does-compile – Sokotra

Thanks man , that was exactly what was going on. – Sigma

Answer 1

It's a guess, but I think your function:

private static string RpcRoutingKeyNamingConvention(Type messageType, ITypeNameSerializer typeNameSerializer) does not match your helper method signature because you try returning a string:

public static TAttribute GetAttribute<TAttribute>(this Type type) where TAttribute : Attribute; which expects a TAttribute return type.

Maybe, you can try modifiying your function RpcRoutingKeyNamingConvention to return GlobalRPCRequest and check if the compiler continues to go crazy.

Glennglenna

does not match your helper method signature because you try returning a string: what do you mean it doesn't match my helper method because I am trying to return string .. this is outrageous to state? – Sigma

@Yann REANAUDIN He is not trying to return a string, look at ? queueName : queueName + "_" + AvailabilityZone; – Dorfman

Answer 2

Visual Studio gets confused all the times! I tried to reproduce the scenario in my VS 2015 (.NET 4.6) and it compiles just fine. I didn't have to add reference to System.Xml.Linq in my Project A.

My guess is that it might be a cache issue. You might want to try this:

1. Remove reference to Project B
2. Clean then rebuild both solutions
3. Add the reference back
4. Rebuild and voila!! Well.. hopefully

Hope it helps, let me know :)

Thynne

Answer 3

I guess that's going on:
- B has reference to System.Xml.Linq
- B is built without a problem.
- You are referencing B in A
- A hasn't got a reference to System.Xml.Linq
- A seem to consume the function defined in B
- When you try to build project A, it produces that error

Am I right?

If that's the case, it is totally normal. Because a project which consumes a reference (A) must have a reference to what is referenced (System.Xml.Linq) by what it references (B).

Think like this: When you try to add a nuget package to your project if it has a dependency, nuget will install it too. Why? Because of this situation.

This is completely normal if I understand your answer correctly.

Darcie

The question was why the compiler get confused that it will use function in project B when the navigation of visual studio clearly knows which one is the right method(the one in project A) ? When you answer this answer you will find answer to the original post answer at least that's how I got it. Check out the link in the comments below my question it pretty much answer all I am asking and wondering. – Sigma

hahaha! sorry about my poor english (both for my answer and my confusion). You had right to do that :-) – Darcie

By the way, which version of vs you are using? – Darcie

do you have both versions namespaces in using block? did you try to call the method by providing the whole path? (ex: A.ReflectionHelpers.GetAttribute) – Darcie

Yes , I fixed the confusion of compiler with providing the whole path(a.k.a calling it statically.) The question is about the confusion not how to solve it. – Sigma