It looks cool on MSDN:
Specifies that the method is declared, but its implementation is provided elsewhere.
So I tried it in a con
The usage of ForwardRef goes pretty much like this:
consumer.cs
using System;
using System.Runtime.CompilerServices;
class Foo
{
[MethodImplAttribute(MethodImplOptions.ForwardRef)]
static extern void Frob();
static void Main()
{
Frob();
}
}
provider.cs
using System;
using System.Runtime.CompilerServices;
class Foo
{
// Need to declare extern constructor because C# would inject one and break things.
[MethodImplAttribute(MethodImplOptions.ForwardRef)]
public extern Foo();
[MethodImplAttribute(MethodImplOptions.ForwardRef)]
static extern void Main();
static void Frob()
{
Console.WriteLine("Hello!");
}
}
Now the magic sauce. Open a Visual Studio command prompt and type:
csc /target:module provider.cs
csc /target:module consumer.cs
link provider.netmodule consumer.netmodule /entry:Foo.Main /subsystem:console /ltcg
This uses one of the lesser known functionality of the linker where we're linking managed modules together. The linker is able to gel together same-shaped types (they need to have the exact same methods, etc.). ForwardRef is the thing that actually lets you provide implementation elsewhere.
This example is kind of pointless, but you can imagine things getting more interesting if a single method is implemented in a different language (e.g. IL).
My understanding is that ForwardRef
acts in the same way as extern
, and is intended for guiding the runtime when the language you are using lacks direct support (via extern
in C#). As such, the usage should be very similar to the extern modifier, most notably using [DllImport(...)]
.