Develop Reference

compiling a method as if it was part of another class

Im looking for something that can compile a method as if it was in a different class so that i can Inject a method that uses internal fields and types without having to manually change the Operand values.
For instance if we need to get a value for debugging:
class bla{
internal string importantValue;
...
public void onInitialize(){
...
//this is where the compiler should be made to think it is
}
}
and the code that goes into the compiler
public void onInitialize(){ //code to be compiled as if it were in that method
File.WriteAllText("usefulString.txt",importantValue.toString());
}
and then we can get the il of the compiled output and insert it into bla.onInitialize so that we now can get our value

With the example given, making onInitialize() protected, then constructing an override in another class would work.
Alternatively make the body of the method a delegate defined at class level - then set a different delegate in your code to make it do something else.

I really don't get what you want to achive and I think there is a simpler way.
But if I understand from your question title, you want to compile your class bla (for example) and you want that in method onInitialize will be added new code (that doesn't exit there) in compile time. It it true?
For this you have a several ways. I'll describe two of them.
You can use library like StaticProxy.Fody. This lib let you intercept method and inject into it whatever you want. So in your example, you intercept onInitialize method and you add to it this code File.WriteAllText("usefulString.txt",importantValue.toString());
All of this in compile time. After you compile the code your ouput dll will contain this injected code.
Second option is to compile your code regulary and after that you can use Mono.Cecil to read your compiled dll and write code that will add whatever you want to where you want, (in our example, add File.WriteAllText etc. to onInitialize) after you save this dll it will contain the new injected code.
Both of the options are simple way to add code in static manner (aka compile time and not runtime).

Is static context always single in C#?

I have a library that has a static field inside. I want to create an app and reference this library so I'd have two instances of this static field. .Net runtime does not allow to reference the same library twice, but I wonder is it possible to overcome this limitation?
I'm not allowed to change the library, but I can copy/rename it.

That's not as crazy as you think. In fact, you can achieve this using AppDomains.
Each AppDomain has its own storage location for static variables. So you can just create a second AppDomain in your process, and communicate between them using an object that inherits from MarshalByRefObject like in this MSDN example.

While Lucas' suggestion on AppDomains would work, alternatively you could create this effect using generics, as a class with different generic type arguments is treated as a different class, and therefore has its own static fields.
public class SomeClass<T>
{
public static string SomeField;
}
Then:
SomeClass<int>.SomeField = "A";
SomeClass<string>.SomeField = "B";
Console.WriteLine(SomeClass<int>.SomeField); // A
Console.WriteLine(SomeClass<string>.SomeField); // B
For example, the SomeClass<int> would be set in the library, whereas the SomeClass<string> would be your copy. Of course this would only work if you could change the library, or the library already used generics.

Both suggestions should work, but they are all terrific concerning architecture.
I a not aware about the context, but in your case is it possible to just create an aggregation class with a new property that is not static and just have two instances.
This sound like a better way for me.
Everytime I have smart code, an alert starts in my head. Smart code is always too clever for a developer.

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;

Interop with another function in a different class

I would have to call C++ code from .Net code via interop.
I just wonder whether is there anyway to interop with another function in a different class? For example, in C++, I have the following utility class:
class ConvertUtility
{
public:
static void Convert(PointList &ptList, const list<pts> &pts);
};
I wish to call it directly from .Net via interop, any idea how to do this?
Note: here's a related question asking about how to use namespace to distinguish between different method. But this time, I want nothing to do with namespace, only a class with static function.
Edit: Given that there are already too many functions in the C wrapper ( e.g, static extern "C" function that are callable from .Net, without class or namespace), I won't want to introduce an extra layer of wrapping, if I can help it.

In the related question you linked to, Ben Voigt says in a comment to the suggestion to write a C++/CLI wrapper:
This IS the correct answer. P/Invoke should only be used to call
functions with a "C" interface, which means extern "C" to prevent name
mangling, and also restrictions on parameter and return types.
Since the method is static, I see two options:
Write a simple C wrapper function that can be called with P/Invoke.
Write a C++/CLI wrapper that can be called directly from C#.

What is a Managed Prototype?

I just need clarification on what a managed prototype is.
I think it is a method that uses the DLLImport attribute and has a method like so:
[DllImport("user32.dll")]
private static extern int MessageBox(IntPtr hWnd, String text, String caption, uint type);
Does it always mean this i.e you must have a DLLImport attribute and then a method signiture which is a private static extern???
Cheers

A function prototype is a function that is declared solely as a way for the compiler to work out how to call some code, without necessarily having that "some code" available to look at, so without the prototype it would be flying blind related to argument types, etc.
So for P/Invoke functionality, ie. calling functions in native DLLs from a managed language like C#, yes, you need those prototypes, unless you can find an already existing class in .NET that either wraps that function, DLL, or implements similar functionality in pure managed code.
And yes, you need a [DllImport...] attribute to specify whith DLL that has the function, and it should be static and extern, but it does not necessarily have to be private, although it usually is, typically because you then wrap that function in a managed class to make it easier for the rest of your code to use it.