Develop Reference

How to specify which extension method to call when ambigous call is found [duplicate]

I am making the following call to an extension method:
database.ExecuteScalar(command).NoNull<string>(string.Empty);
I get an error that the extension method is ambiguous .
I have two dlls with the same code that implement NoNull(string str) under different namespaces.
How can I explicitly refer to one namespace?
How would I have it done if it was the same namespace?
Update: I cannot rewrite the 3rd party dlls.

Remove the ambiguity by redefining or eliminating one of the methods at the source. You don't need redundancy.
If you do not control the source, include only one of them in your class file via the using directive.
If you still need both namespaces in the given class file, invoke the version you wish simply as a static class call, unambiguously identifying the method via the (potentially fully qualified) class name.
Abc.Xyz.ExtensionsClass.NoNull(database.ExecuteScalar(), string.Empty);
// <Abc.Xyz.> is only necessary if the classes themselves match names
// if not, only <ClassName>.<MethodName> is needed

Just in case somebody will need this...
Ambiguity can be resolved if concurrent namespaces which have extension methods with same name, are included at different levels (most inner included namespace will have priority).
For example:
using Namespace1;
namespace MyApplication
{
using Namespace2;
...
db.Execute(); // Namespace2 Execute() will be called
}

I would strongly suggest that you rename one of the extension methods. Depending on what else you do, you could possibly just remove the using directive for one of those namespaces, but that won't help if you need both namespaces for other things. (This leads to a suggestion to put extension methods in their own namespace, of course.) Renaming is likely to simplify things in general though.

You should change the signature of one (or both of them) to differentiate what it does. This seems like duplication of code somewhere unless these do different things. Though if they do different things I would think you would differentiate that in the names. I'd recommend creating some sort of enumeration (a flag maybe) to pass as an extra argument to one of the methods.

In my case the problem was, that both extension methods had the same namespace like Some.Namespace.Extensions, that i didn't have control over and thus couldn't change.
They were each located in a separate class, though. So I solved it by writing
using static Some.Namespace.Extensions.HostExtensions
instead of
using Some.Namespace.Extensions as using a using statement with a static class is not possible.

Can I restrict the visibility of C# extension methods to classes in the same assembly?

Say I have these files:
MyCode.cs
namespace MyCodeNamespace
{
public class MyClass
{
//OMITTED
}
internal static class MyExtensions
{
internal static void Foo(this string str)
{
//OMITTED
}
}
}
OtherCode.cs
using MyCodeNamespace;
namespace OtherCodeNamespace
{
//OMITTED
}
The two files are part of the same assembly. Is there any way I can make Foo accessible to MyCode.cs but not to OtherCode.cs? My question is similar to this question:
C# Extension Methods only visible and accessible within one class ("private")
But its accepted answer isn't really what I'm looking for. I want to make an extension method that's only visible to the code I'm working on, and according to the answer to the above question, someone could still access it by adding a "using" statement. Is there a way I can create an extension method that is only visible to my code, and nowhere else, not even by another class in the same assembly?
I ask because the syntax for calling an extension method is handy and would be useful for what I'm working on (otherwise I'd just create a private method instead), but I don't want others to see it and use it from their code in case it doesn't do what they assume it does. And thanks to Visual Studio's intellisense, my extension methods are currently showing up in the list of available methods (along with the option to add the namespace they're in).

There is no such thing as a namespace-limited access modifier in the .NET platform. From the docs
public : Access is not restricted.
protected : Access is limited to the containing class or types derived from the containing class.
Internal : Access is limited to the current assembly.
protected internal: Access is limited to the current assembly or types derived from the containing class.
private : Access is limited to the containing type.
That's all you have to work with. So the answer is no.

Extension methods are just semantic sugar that compile to the same IL as calling the static helpers directly.
MyExtensionMethods.DoSomething(myObject);
myObject.DoSomething();
You cannot restrict it from being called, but you can remove its visibility from Intellisense.
Simply move your extension methods to a different namespace, add a using statement in your MyCode.cs and don't include that namespace in OtherCode.cs
[update]
If you really need to restrict the caller, you could try using reflection to determine and restrict, but this is a bit overkill. Best to simply use a private static helper instead of doing this.
var frame = new System.Diagnostics.StackFrame(1, false);
var method = frame.GetMethod();
var type = method.DeclaringType;
// allow|deny type

I had a similar problem. I did not want the programmer to see my inner extension methods when configuring services in ASP.NET Core.
The solution for me was to add all extension methods to namespace Microsoft.Extensions.DependencyInjection that is used in Startup.cs and the user can see those methods. (As you would always do.)
If I wanted to "hide" something I added the extension method to MyNamespace.Extensions. If the user writes the correct name the helper for add using will show up but by default it won't be listed.
I know this is not a solution but might help someone.

think about similar thing;
c# assembly, friend assembly
will try InternalsVisibleTo;
if your classes is closed maybe will not helpfull but you can try it;

Is it possible to be using a library in a method but not outside the method?

For example:
private void MethodName()
{
Using System.OI;
}
I only need this library in this one method. Is there any way I can do this?
The reason I don't have it up top is the it creates ambiguous references.

There is no need at all to use a using statement when using a given type. You can simply use the fully qualified name when you want to use the type:
var lines = System.IO.File.ReadLines("temp.txt");
The using statement is merely syntactic sugar to avoid needing to do this for every single use of a type.

Use partial classes. Create two source files for the same class, one that imports System.IO (and contains your special method) and one that doesn't (and contains all the remaining methods).
using System.IO;
public partial class MyClass
{
private void MethodName()
{
...
}
}

This line from MSDN makes me suspect not:
The scope of a using directive is limited to the file in which it appears.
Note that it doesn't say scope. However, you can always reference an object without a using directive:
public void MyMethod()
{
System.IO.StreamWriter myWriter;
}
The partial class idea is another clever way around the problem. Here's the documentation I reference: MSDN

While most answers here about avoiding using statement and full qualified type name, I want to comment on this one:
I only need this library in this one method. Is there any way I can do this?
In .Net, adding using or adding reference to a library doesn't mean that this library will be loaded at all. Library is being loaded to application domain in runtime only then it is really used.
So adding using to a file don't hurt anyone; executing particular method will load necessary libraries if required.
Once library is loaded in application domain - it will never be unloaded.
So most probably - you won't need what you are asking for, just use using on file level or namespace aliases in case of names conflicts.

Where to put extensions to a static class in a library? (in C#)

Although my question is about C# in general, I'll ask it by giving a concrete example.
I have written a function EnsureDirectoryPresent, which is an extension of the System.IO.Directory class in .NET's BCL library. Where can I best put this new function?
Conceptually the method is an extension method to the Directory class. Regrettably, it is a static class, so I cannot use the feature.

The .NET Framework Design Guidelines (2nd edition) say to put in a class (or classes) in a child namespace (e.g. "...Extensions"). This is to allow the programmer to control usage, not having the using directive will block extensions that might not be desired:
DO NOT put extension methods in the same namespace as the extended type unless it is for adding methods to interfaces or for dependency management. Of course, in the latter case, the type would be in a different assembly.
However the framework breaks the spirit of this guideline in places (e.g. System.Xml.XPath.Extensions class would be in scope if you were using XPathDocument etc. and then starting using XML to LINQ).

You can't extend System.IO.Directory, as it is a static class. But you can extend System.IO.DirectoryInfo - this is a non-static counterpart to System.IO.Directory.
Then you'll be able to use it like this:
(new DirectoryInfo(#"C:\Foo\Bar\Baz").EnsureDirectoryPresent();

You've worked out that you can't use extension methods to tack on a static method to the Directory class. The next best thing in my opinion would be to simply create a new static class for directory related functions. Typically the Utils suffix is used. I think this is the simplest thing you could do.
static class DirectoryUtils
{
public static void EnsureDirectoryPresent(string dir) { }
}
DirectoryUtils.EnsureDirectoryPresent(someDirectory);
The only difference in terms of syntax there (as opposed to a static method of the same name in Directory) is the text 'Utils'. However, 'discoverability' is not the same as using an extension method - you have to know about the DirectoryUtils class.

Extension methods only extend instance methods. You cannot extend class's static methods. The reason is static methods are on the type itself when assembly is loaded onto memory so really you cannot extend them.
Also extension method is more of a compiler/IDE/Language feature than the framework.
UPDATE
I got a negative here - unwarrantedI believe - but here is the clarification:
Extension methods are achieved by using static methods, but you access them from your objects not from the type. Hence the first parameter is always "this".

Is it ok to write my own extension methods in the system namespace?

I've been using extension methods quite a bit recently and have found a lot of uses for them. The only problem I have is remembering where they are and what namespace to use in order to get the extension methods.
However, I recently had a thought of writing the extension methods in the System namespace, System.Collections namespace or some other system namespace that makes sense. So for example, I've implemented the following.
namespace System
{
/// <summary>Various array extensions</summary>
public static class ArrayExtensions
{
/// <summary>Converts the array to a hex string</summary>
/// <param name="value">The value.</param>
/// <returns>The array as a hex string</returns>
public static string ToHexString(this byte[] value)
{
var hex = new StringBuilder(value.Length * 2);
foreach (byte b in value)
{
hex.AppendFormat("{0:X2}", b);
}
return hex.ToString();
}
}
}
Is this the correct thing to do?

From the Framework Design Guidelines (2nd Edition):
DO NOT put extension methods in the same namespace as the extended type, unless it is for adding methods to interfaces, or for dependency management.
While this doesn't explicitly cover your scenario, you should generally avoid extending a Framework namespace (or any namespace you have no control over) and opt instead to put those extensions in their own namespace. If you feel strongly about "grouping" the extensions (such that the collection extensions are together, etc.) then you could introduce a subnamespace. In your scenario, extension to the collections would go in a System.Collection.Extensions namespace or a Company.Collections or even a Company.Collections.Extension namespace.
In order to use extension methods the namespace containing the sponsor class (the class that defines the extension methods) must be imported. If you add extension methods to one of the standard .NET Framework namespaces they will always (and implicitly) be available.

You should avoid augmenting namespaces over which you do not have primary control as future changes can break your code (by introducing duplicates, for example).
I tend to mimic the standard namespaces with a different root namespace that identifies all child namespaces as belonging to my work. The root namespace could be your name, your organisation's name, or something else that identifies the contents of that namespace as being yours.
For example, if you want to extend System.Collections, you could use NickR.Collections or NickR.System.Collections.

The only thing that the namespace really affects with extension methods is visibility and discoverability - so it depends on whether you want the extension methods to always appear on that type or not. The framework design guidelines are intended primarily for public APIs and so, while it's generally a good idea to follow them, the rules are very much there to be broken for internal APIs when it makes sense.
For example, we do a lot of work with TimeSpan objects throughout the codebase and there are no methods to multiply or divide these in the framework so we have added MultiplyBy and DivideBy extension methods, amongst others, and put them in the System namespace because we want them accessible and discoverable wherever a TimeSpan is used.
On the other hand we also do quite a bit of reflection work, operating on Type objects, and there are a whole lot of extension methods that are very useful in specific areas but not generally, so these live in a OurCompany.Reflection namespace so they have to be specifically imported.
So for internal APIs the decision boils down to "do I want this method to be available everywhere the type is available in our codebase?". If the answer is yes, then put it in the same namespace, otherwise put it somewhere else.

Not sure if it's wrong (or right, for that matter), but why not have your own 'Extensions' namespace? Then put all your extension methods in that namespace and be consistent about it.
I don't think the real problem is where to put them or what to name it (system or any other namespace), but to be consistent and always use the same to avoid your problem (forgetting where they are).

I put my extention methods in a namespace depending on the visibility I want them to have. That way they are easier to discover, and I usually get fewer namespace imports.