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 <[email protected]> wrote: > On 10 December 2015 at 11:10, Arjang Assadi <[email protected]> > 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 > >
