Programming Languages – What Language is the CLR Written In?

SQL CLR integration was developed mainly because, implementing logic through T-SQL was really hard. .NET Framework if filled with thousands of useful libraries, to which you have no access at SQL engine level. Thus, any logic should be implemented from scratch. For example, a simple foreach loop should be implemented with cursors, which are honestly, far less productive.

I have experience of working with SQL CRL integration. I did it for date-time conversion at database engine level. Date-time conversion at the level of database engine is really really hard, while .NET, has System.Globalization which facilitates the work.

The main point of this method, is to follow the step exactly as described (like extension methods in which, methods should be static functions inside static classes inside first-level namespace). If you fail to do something exactly as you're told, things simply fail.

There are two drawbacks to keeping just the managed DLL:

a) you will need the .NET Framework on the target machine

b) there will be two layers of marshaling between an unmanaged caller and the code you've wrapped: a COM Callable-Wrapper between the native caller and the COM interface of your .NET Assembly, and the managed-unmanaged transition between your wrapper and the inner code - this may be a serious performance hit if you're marshaling a lot, and it may be complex if your interface to the callers is wide.

If neither of these is a real problem (i.e. adding the CCW in terms of performance and complexity), then you have no other direct incentive that I can see to modify your current solution.

As far as extensibility goes, if you plan to add managed code to the wrapper - if you need to complement the solution you're wrapping and need to add stuff to it at the low-cost of managed code, then you're pretty much stuck with the managed DLL, because presumably both the VB6 callers and the managed callers would need the new functionality. If, on the other hand you need to add native code, then you could still add it to the unmanaged CLI part of the managed DLL.