While C# supports COM Interop in both directions, from COM to .NET and vice versa, it only supports P/Invoke calls and not P/Invoke callers.
What’s odd about this is that unmanaged calls are supported in IL Assembler and the .NET runtime. So, why did the C# team provide support for only three out of the four permutations of unmanaged interop ?
In all likelihood it was just never a priority and yet… Consider how easy it would have been to add the support – probably just an attribute to decorate the method you wanted to export with a few options like the calling convention to use. In fact, rather like Robert Giesecke’s Unmanaged Exports MSBuild task.
So why didn’t Microsoft do it ? There’s a number of possible reasons but my guess is that making it easy for legacy application code to call managed code wasn’t something that aligned with Microsoft’s marketing stragegy for .NET. It’s one thing to allow your new development platform to interoperate with legacy code but quite another to have legacy code interoperate with managed code. The first case is a real world compromise that recognises that legacy server code is going to be around for a while yet but the second just makes it too easy for customers and third parties to continue developing and using (i.e. investing, which means dollars) systems written in unmanaged code.
Like this:
Like Loading...
Related
Conspiracy theory: Why doesn’t C# support unmanaged externs ?
leave a comment »
While C# supports COM Interop in both directions, from COM to .NET and vice versa, it only supports P/Invoke calls and not P/Invoke callers.
What’s odd about this is that unmanaged calls are supported in IL Assembler and the .NET runtime. So, why did the C# team provide support for only three out of the four permutations of unmanaged interop ?
In all likelihood it was just never a priority and yet… Consider how easy it would have been to add the support – probably just an attribute to decorate the method you wanted to export with a few options like the calling convention to use. In fact, rather like Robert Giesecke’s Unmanaged Exports MSBuild task.
So why didn’t Microsoft do it ? There’s a number of possible reasons but my guess is that making it easy for legacy application code to call managed code wasn’t something that aligned with Microsoft’s marketing stragegy for .NET. It’s one thing to allow your new development platform to interoperate with legacy code but quite another to have legacy code interoperate with managed code. The first case is a real world compromise that recognises that legacy server code is going to be around for a while yet but the second just makes it too easy for customers and third parties to continue developing and using (i.e. investing, which means dollars) systems written in unmanaged code.
Like this:
Related
Written by Sea Monkey
February 25, 2010 at 9:00 pm
Posted in Comment
Tagged with C#, Comment