StefH/ProxyInterfaceSourceGenerator

Internal proxies/Proxy factory

FatSwords opened this issue · 4 comments

Hi,

Just a quick word on how we're using this now (in case you are interested!) as we've modified your implementation to better suit us.

We've added an extra control parameter which allows us to control whether the proxy classes are created as public or internal. This has then meant we can

  1. Take our horrid 3rd party API and create our "ProxyInterfaces.cs" file as you have in your documentation, with all our types laid out as
    [ProxyInterfaceGenerator.Proxy(typeof(SomeType), false, "internal")] public partial interface ISomeType{}

  2. This then gives us interfaces as normal, but internal proxy types.

  3. We then define a new interface/class "IProxyFactory/ProxyFactory" which then creates those proxies inside the same assembly - as a WIP I'm trying to get this autogenerated as well...

  4. This is packaged up as a nuget and distributed.

  5. Our users of the horrid 3rd party API are then forced to use ISomeType as ProxySomeType isn't actually available, therefore preventing them newing them up, they have to use the provided factory. Obviously they've been using the horrid API for some time, so changing the behaviour is really important to us to enable our codebase built on this 3rd party API to become DI friendly/testable.

Anyway - there's not really an issue here, I mostly just wanted to thank you for creating this library and the issue fixes you've released. they are much appreciated! I'll raise a PR for controlling the access modifiers on the proxies, lmk what you think.

just tried to raise that PR and got an access denied error, so nvm. let me know if you want to see the mods I've made and I'll sort some other way of getting them to you.

okay - I've stopped running out of talent, so there's a PR up to see if you like the look of it

StefH commented

@FatSwords See my PR #58

PR looks good to me - enum approach is better than my string approach