change ContextExtensionMethods namespace

[brandonh-msft]

The ContextExtensions should be in Microsoft.Bot.Builder namespace; in order to use them, users need to see them. They don't see them if they have to import a completely separate namespace. In JS SDK, this hurdle doesn't exist; shouldn’t in .Net.

[brandonh-msft]

cc @cleemullins

[cleemullins]

The namespace of a file generally matches it's path. In this case, the path includes a /ContextExtensions/ segment. That means the namespace should match. Exceptions are certainly possible, but this doesn't seem like it's warranted.

Your comment calls out the typical C# Behavior:

in order to use them, users need to see them. They don't see
them if they have to import a completely separate namespace.

Typically in C#, developers DO import the namespaces to see extension methods. That way they only see what they want. That's pretty much what we've been doing to date.

The namespace and approach you see were deliberate.

For reference, here's the relevant C# "Docs":

One simple way to improve the robustness of your extension method library is to put extension methods into their own namespace. This is the strategy employed by the 3.5 version of the .NET Framework. By putting extension methods into their own namespace you enable consumers to include or exclude them separately from the rest of your library. This makes them pluggable, allowing users to easily replace extension method implementations with other implementations if they wish (which is at the heart of the LINQ provider model). This in turn then makes it easier for them to resolve any conflicts that may arise (see part 2 for information about extension method precedence levels).

Of course, the end of the docs there then say:

Please ignore this advice where it is not appropriate

Also note, the docs I'm reading are ancient. If best practices have evolved, please point me at them and I'll update accordingly.

To further confuse the issues, here's recent discussions on StackOverflow that are totally unhelpful! :)

In short, I'm open to be persuaded.

[brandonh-msft]

just to reiterate, this is actual customer feedback. They still don't think that C# has SendTyping and Delay due to this issue.

[tomlm]