Develop Reference

How can I change the behavior of a static method at runtime?

Is there a way to modify the behavior of a static method at runtime?
for example:
Say I have this class
public class Utility {
public static void DoSomething(string data){
//...
}
}
Is there a way to do something like this:
typeof(Utility).SetMethod("DoSomething", (data) => { /*Do something else...*/ });
Such that if you call Utility.DoSomething it executes the new code?

What you want to do is pass the behavior you want as another parameter into the function.
public static void DoSomething(string data, Action<string> operation)
{
operation(data);
}
This is an oversimplified example, of course. What you actually wind up doing in your own code is going to depend on what operation actually does.
If you're trying to modify the behavior of an existing, compiled, in-production method, and cannot overload or override the method in the usual ways, the only way I know of to do that is CIL Rewriting, possibly using an Aspect Weaver.

Sure.
public class Utility {
public static Action<String> _DoSomething;
public static void DoSomething(string data){
if (_DoSomething != null) {
_DoSomething();
return;
}
// default behavior here.
}
}
And to mask the default behavior:
Utility._DoSomething = (data) => { /* do something else */ };

I don't see why you wouldn't just create a new class that inherits from Utility and define a new function that does what you want.
public class Program
{
static void Main(string[] args)
{
if (true)
{
Utility.DoSomething("TEST");
} else
{
Util1.DoSomething("TEST");
}
}
}
public class Utility
{
public static void DoSomething(string data)
{
//Perform some action
}
}
abstract class Util1 : Utility
{
public static new void DoSomething(string data)
{
//Perform a different action
}
}

I think although it is possible to do this you should ask yourself: "Why do I need this functionality"? Usually a method stays as is, and does what it is supposed to do according to its interface which is given by its name and signature. So while you can add additional logic by adding an Action<T>-parameter to your signature you should ask yourself if this won´t break the contract of the interface and therefor what the method was designed for.
Having said this you should consider either overwrite your method if the functionality you need is some kind of "making the same things differently then the parent-class" or extend it by adding a dependency into your consuming class and add some methods to that class that extent the functionality provided by the contained class (see also favour composition over inheritance)
class MyClass {
Utility MyUtility;
void ExtraMethod() { /* ... */ }
}
EDIT: As you´re using a static method the opportunity on overwriting is obsolete. However IMO that sounds like a great design-flaw.

Calling helper functions without calling the static class they live in

I am making a DLL of helper functions and I want to call them without calling the class they live in. For example:
namespace HelperFunctions
{
public static class Greetings
{
public static void greet()
{
Console.WriteLine("hello!");
}
}
How to I modify the above code so that I can do this:
using HelperFunctions;
namespace MyConsoleApp
{
class Program
{
static void Main()
{
greet();
}
}
}
Assumptions/Understandings:
I understand I can call Greetings.greet() but I dont want to.
I understand I will have to come up with unique names for my functions that won't clash with anything from the System namespace (or whatever other references I am using)

Presently, you can't.
When the next version of C# is released, you'll be able to write:
using HelperFunctions.Greetings;
and it will work.

C#: Giving access to private members without 3-fold code duplication

I have a class
public class Foo{
public Foo{...}
private void someFunction(){...}
...
private Acessor{
new Acessor
}
}
with some private functionality (someFunction). However, sometimes, I want to allow another class to call Foo.SomeFunction, so I have an inner class access Foo and pass out that:
public class Foo{
public Foo{...}
private void someFunction(){...}
...
public Acessor{
Foo _myFoo;
new Acessor(Foo foo){_myFoo = foo;}
public void someFunction(){
_myFoo.someFunction();
}
}
}
With this code, if I want a Foo to give someone else pemission to call someFunction, Foo can pass out a new Foo.Accessor(this).
Unfortunately, this code allows anyone to create a Foo.Accessor initiated with a Foo, and they can access someFunction! We don't want that. However, if we make Foo.Accessor private, then we can't pass it out of Foo.
My solution right now is to make Acessor a private class and let it implement a public interface IFooAccessor; then, I pass out the Foo.Accessor as an IFooAccessor. This works, but it means that I have to declaration every method that Foo.Accessor uses an extra time in IFooAccessor. Therefore, if I want to refactor the signature of this method (for example, by having someFunction take a parameter), I would need to introduce changes in three places. I've had to do this several times, and it is starting to really bother me. Is there a better way?

If someFunction has to be accessible for classes in the same assembly, use internal instead of private modifier.
http://msdn.microsoft.com/en-us/library/7c5ka91b(v=vs.71).aspx
If it has to be accessible for classes which are not in the same assemble then, it should be public. But, if it will be used by just a few classes in other assemblies, you probably should think better how you are organizing you code.

It's difficult to answer this question, since it's not clear (to me at least) what exactly you want to achieve. (You write make it difficult for someone to inadverdantly use this code in a comment).
Maybe, if the method is to be used in a special context only, then explicitly implementing an interface might be what you want:
public interface ISomeContract {
void someFunction();
}
public class Foo : ISomeContract {
public Foo() {...}
void ISomeContract.someFunction() {...}
}
This would mean, that a client of that class would have to cast it to ISomeContract to call someFunction():
var foo = new Foo();
var x = foo as ISomeContract;
x.someFunction();

I had a similar problem. A class that was simple, elegant and easy to understand, except for one ugly method that had to be called in one layer, that was not supposed to be called further down the food chain. Especially not by the consumers of this class.
What I ended up doing was to create an extension on my base class in a separate namespace that the normal callers of my classes would not be using. As my method needed private access this was combined with explicit interface implementation shown by M4N.
namespace MyProject.Whatever
{
internal interface IHidden
{
void Manipulate();
}
internal class MyClass : IHidden
{
private string privateMember = "World!";
public void SayHello()
{
Console.WriteLine("Hello " + privateMember);
}
void IHidden.Manipulate()
{
privateMember = "Universe!";
}
}
}
namespace MyProject.Whatever.Manipulatable
{
static class MyClassExtension
{
public static void Manipulate(this MyClass instance)
{
((IHidden)instance).Manipulate();
}
}
}

UnitTesting static Class (Theoretical Question)

I know when is ok to use a Static Class, but my simple question is:
If there's a big problem when we're Unit-Testing our code that has some Static Class?
Is better just using a regular instances class?
Thanxs (i know there's some questions that talk about this, but all are based in particular case I just want to have a general opinion about it)

What I do is take the existing static class use as a seam, and provide an alternative implementation in a different namespace. This means that you can get the code under test with as few changes as possible -- just namespace changes. Typically I've had to do this to get round C# filesystem ops -- File.Exists etc.
Say your method basically does this:
using System.IO;
public void SomeMethod()
{
...
if(File.Exists(myFile))
{
...
}
...
}
then I'd replace that implementation of File with an alternative. The alterntive implementation should stub out any existing methods, and make calls to delegate implementations under the covers -- e.g.
namespace IO.Abstractions
{
public static class File
{
public static Func<string, string, string> ExistsImpl =
System.IO.File.Exists;
public static string Exists(string path)
{
return ExistsImpl (path);
}
}
}
Then I'd modify the original code so that it uses the new namespace:
using IO.Abstractions;
public void SomeMethod()
{
...
if(File.Exists(myFile))
{
...
}
...
}
Then, in your test, you can just provide an alternative implementation of the behaviour for File.Exists, something like:
[Test]
public void SomeTest()
{
// arrange
...
File.ExistsImpl = (path) => true; // to just default to true for every call
...
// act
someClass.SomeMethod();
// then assert
...
}
I wrote a blog with some more details recently here.

Can there be stand alone functions in C# without a Class?

In C/C++, I have a bunch of functions that I call from main(), and I want to rewrite this in C#. Can I have stand alone functions(methods) or do I have to put them in another class? I know I can have methods within the same class, but I want to have a file for each function/method.
Like this works:
using System.IO;
using System;
class Program
{
static void Main()
{
House balls = new House();
balls.said();
}
}
public class House
{
public void said()
{
Console.Write("fatty");
Console.ReadLine();
}
}
But then I have to create an instance of House and call said(), when in C I can just call said().

For reference, I want to add the using static addition of C# 6 here.
You can now use methods of a static class without having to type the name of that class over-and-over again. An example matching the question would be:
House.cs
public static class House
{
public static void Said()
{
Console.Write("fatty");
Console.ReadLine();
}
}
Program.cs
using static House;
class Program
{
static void Main()
{
Said();
}
}

No. Make them static and put them in a static utility class if they indeed don't fit within any of your existing classes.

If using C# 9 it is now kinda possible, thanks to the top-level statements feature.
In your executable project, the following syntax is now allowed:
using SomeNamespace;
// The following statements are seemingly defined without even a method,
// but will be placed inside a "Main" static method in a "$Program" static class
SayHello();
var classFromSomeNamespace = new SomeClass(); // from SomeNamespace
classFromSomeNamespace.SomeMethod();
// This function is seemingly defined without a class,
// but on compile time it will end up inside a "$Program" static class
void SayHello()
{
Console.WriteLine("Hello!");
}
// Here the "traditional" syntax may start
namespace SomeNamespace
{
public class SomeClass
{
public void SomeMethod()
{
Console.WriteLine("SomeMethod called");
}
}
}
It should be noted, that the above syntax is valid only for a single file in a project, and the compiler actually still wraps this all inside a $Program static class with static methods. This feature was introduced specifically to avoid boilerplate code for the program entry point, and make it possible to easily write "scripts" in C#, while retaining the full .NET capabilities.

There is no concept of standalone functions in C#. Everything is an object.
You can create static methods on some utility class, and call those without creating an instance of a class eg
class Program
{
static void Main()
{
House.said();
}
}
public class House
{
public static void said()
{
Console.Write("fatty");
Console.ReadLine();
}
}

You have to put them in a class, but the class can be static as others mentioned. If you REALLY want to have a separate file for each method, you can mark the class as partial to get the following:
Program.cs
----------
class Program
{
static void Main()
{
House.said();
House.saidAgain();
}
}
House-said.cs
-------------
public static partial class House
{
public static void said()
{
Console.Write("fatty");
Console.ReadLine();
}
}
House-saidAgain.cs
------------------
public static partial class House
{
public static void saidAgain()
{
Console.Write("fattyAgain");
Console.ReadLine();
}
}
I wouldn't recommend separating each one out, however. Partial classes are mostly used so that designer-generated code won't overwrite any custom code in the same class. Otherwise you can easily end up with hundreds of files and no easy way to move from one method to another. If you think you need a partial class because the number of methods is getting unmaintainable, then you probably need to separate the logic into another class instead.

Although the concept of stand-alone functions exists in .NET, C# doesn't allow you to specify such functions. You need to stick them inside a static Utils class or similar.

If you declare your method as static (that is: public static void said()) then you can just call it with House.said(), which is as close as you'll get in C#.

You could add all your methods to the Program class, but this would quickly become an unmaintainable mess, commonly referred to as the God Class or Ball of Mud anti-pattern.
Maintaining a single file for each function would similarly become a huge mess. The questions "Where do I put my methods" and "What classes should I create" are answered by Design Patterns. Classes aggregate behavior (functions) and should do one thing (Single Reponsibility.)