Generate .net dll wrapper around existing .net library

Question

I have a dll named ExpensiveAndLargeObfuscatedFoo.dll. Lets says it defines a type named ExpensiveAndLargeObfuscatedFooSubClass. It's been compiled for .NET.

Are there any tools (free, paid, whatever) that will generate c# or vb class files that will do nothing but wrap around everything defined in this expensive dll? That way I can add functionality, fix bugs (that CorpFUBAR won't fix), add logging, etc?

Literally, I want output that looks like this

namespace easytoread {
    public class SubClass {
        private ExpensiveAndLargeObfuscatedFoo.SubClass _originalSubClass;
        public SubClass() {
            this._originalSubClass = new ExpensiveAndLargeObfuscatedFoo.SubClass ();
        }
        public string StupidBuggyMethod(string param1,int param2) {
            return _originalSubClass.StupidBuggyMethod(param1, param2);
        }
    }
}

It would have to handle custom return types as well as primitives

namespace easytoread {
    public class SubFooClass {
        private ExpensiveAndLargeObfuscatedFoo.SubFooClass _originalSubFooClass;
        public SubFooClass() {
            this._originalSubFooClass= new ExpensiveAndLargeObfuscatedFoo.SubFooClass ();
        }
        private SubFooClass(ExpensiveAndLargeObfuscatedFoo.SubFooClass orig) {
            this._originalSubFooClass = orig;
        }
        public SubFooClass StupidBuggyMethod(string param1,int param2) {
            return new SubFooClass(_originalSubFooClass.StupidBuggyMethod(param1, param2));
        }
    }
}

And so on and so forth for every single defined class.

Basically, poor mans dynamic proxy? (yay, Castle Project is awesome!)

We'd also like to rename some of our wrapper classes, but the tool doesn't need to do that.

Without renaming, we'd be able to replace the old assembly with our new generated one, change using statements and continue on like nothing happened (except the bugs were fixed!)

It just needs to examine the dll and do code generation. the generated code can even be VB.NET, or ironpython, or anything CLR.

This is a slippery slope and I'm not happy that I ended up here, but this seems to be the way to go. I looked at the Castle Project, but unless I'm mistaken that won't work for two reasons: 1) I can't rename anything (don't ask), 2) none of the assemblies methods are declared virtual or even overridable. Even if they were, there's hundreds of types I'd have to override manually, which doesn't sound fun.

Ashford

I doubt a tool already exists but you could do that using reflection, folders miroring namespaces etc... – Inextricable

I don't know if it'll help, but you may want to look into Type forwarding in the CLR. – Unintentional

Answer 1

It seems the best answer is "There is no such tool". So, I'll be taking a stab at writing my own later as an off-hours project. If I ever get something useful working I'll github it and update here.

UPDATE Visual Studio 2012 Fakes seem to be promising. http://msdn.microsoft.com/en-us/library/tfs/hh549175(v=vs.110).aspx - we've moved on but I might try creating a fake and then dropping it in as a replacement dll sometime in the future

Ashford

Answer 2

ReSharper can do much of the work for you.

You will need to declare a basic class:

namespace easytoread {
    public class SubClass {
        private ExpensiveAndLargeObfuscatedFoo.SubClass _originalSubClass;
    }
}

Then, choose ReSharper > Edit > Generate Code (Alt+Ins), select "Delegating Members", select all, and let it generate the code.

It won't wrap return values with custom classes (it will return the original type), so that would still have to be added manually.

Shaniqua

This would be a great option if I only needed to wrap a few things, unfortunately I'm talking hundreds and hundreds of classes. – Ashford

Answer 3

1. If you have access to the source code, rename and fix in the source code.
2. If you don't have access (and you can do it legally) use some tool like Reflector or dotPeek to get the source code and then, goto to the first point.

Andromede

Not sure why it was down voted. It is probably only solution that have chance to work as creating proxy for some/all classes will not normally impact how library work with its own classes (i.e. MyInnerClass.MyInnerMethod() will still continue calling the same code irrespective of external proxies). NOTE, that doing so is likely against license. – Georgiana

An excellent suggestion, but I would have to examine the legal issues surrounding decompiling, especially since the assembly is obfuscated. Obfuscation would suggest to me they made an effort to prevent this, as their code isn't in "plain view" anymore. – Ashford