Thank you Thomas ,
I am off to code generation for me then, I hate doing handcrafted code when
all the ingredients are already there to generate the next step
I just got tired of having a shadow class, so I can separate the COM
consumption intended classes from the rest of BL, my shadow classes are
almost 1-1 to the original BL class, with COM required attribute
decorations. I used Automapper to go from one to the other, keeping my code
SOLID compliant.
Code generation is interesting to look into, I must have missed the Code
Gen Mails on this list, I do a seach see what I find.
Regards
Arjang
On 14 December 2015 at 11:50, Thomas Koster wrote:
> On 10 December 2015 at 11:10, Arjang Assadi
> wrote:
>
>> Does Anyone know about any Autogeneration tool to Wrap Existing Classes
>> and Generate COM exposed objects? I am doing it by hand, it tedious and
>> error prone, looks like an ideal use case for Roslyn or Resharper.
>>
>
> .NET can generate COM proxies all on its own: just regasm any assembly
> with anything "ComVisible(true)" in it, even without any other COM
> attributes. However, the result is quite ugly and generally only consumable
> from C++. VB6 only understands a subset of COM, and VBScript an even
> smaller subset. Also, I believe clsids are basically randomized in this
> mode so you may encounter dependency hells and dreaded diamonds when
> building/deploying new releases. As I'm sure you have discovered, long-term
> maintenance requires proper COM attributes.
>
> One way (that I have never tried) is to write COM interface files [1] and
> compile them into a typelib file with midl.exe [2]. Once you have the
> typelib, you can generate C# proxies using tlbimp.exe [3]. You can use this
> generated model directly or you can write some mapping functions between
> this generated model and your existing "nice" model.
>
> I personally found that hand-crafted proxies were still the simplest way
> to export classes that were VB6-friendly, and idiomatic VB. This was
> important to us because our VB6 programmer is not a .NET programmer. Also,
> all the "quirks" could be isolated in these proxies and documented there.
> No cross-contamination: the C# side was idiomatic C# and the VB side was
> idiomatic VB.
>
> Code generation also has other issues in .NET, but my views on this are
> known to the list and you can generally assume an anti-codegen stance from
> me. Poor build-system integration -> no hermetic builds -> randomly broken
> builds -> "works for me" bugs.
>
> [1] https://msdn.microsoft.com/en-us/library/windows/desktop/aa378712.aspx
> [2] https://msdn.microsoft.com/en-us/library/windows/desktop/aa367084.aspx
> [3] https://msdn.microsoft.com/en-us/library/tt0cf3sx.aspx
>
> --
> Thomas Koster
>
>