1

I need to provide a copy of the source code to a third party, but given it's a nifty extensible framework that could be easily repurposed, I'd rather provide a less OO version (a 'procedural' version for want of a better term) that would allow minor tweaks to values etc but not reimplementation using the full flexibility of how it is currently structured.

The code makes use of the usual stuff: classes, constructors, etc. Is there a tool or method for 'simplifying' this into what is still the 'source' but using only plain variables etc.

For example, if I had a class instance 'myclass' which initialised this.blah in the constructor, the same could be done with a variable called myclass_blah which would then be manipulated in a more 'flat' way. I realise some things like polymorphism would probably not be possible in such a situation. Perhaps an obfuscator, set to a 'super mild' setting would achieve it?

Thanks

Mark Williams
  • 13
  • 2
  • I really don't recommend trying to use C# in a non-OO way. C# is purely OO, so don't try to use it any other way. – Kendall Frey Jan 10 '12 at 01:22
  • 1
    @kendfrey: C# started out as a fairly pure OO language, but it's since borrowed a large number of ideas from other paradigms, including functional programming. – Ben Voigt Jan 10 '12 at 01:29
  • @kendfrey: You misunderstand, OP wants to un-OO source he has to give away, not source he uses. – Daniel Fischer Jan 10 '12 at 01:29
  • 1
    So you're looking to provide a 'copy' of the source code without having to actually provide a copy of the source? – M.Babcock Jan 10 '12 at 01:33
  • @DanielFischer: By 'use it in any other way', I meant, 'create, read, modify, compile, run, or otherwise treat as normal code, code which is not OO'. Giving away the code is 'using' it, the way I see it. – Kendall Frey Jan 10 '12 at 02:10
  • Ben has the gist - my understanding is that IL doesn't understand the various OO abstractions that exist within c#. So the desired process would be something like C# -> IL -> Basic code that achieves same thing. Might not be possible - but that's the nature of the question! – Mark Williams Jan 10 '12 at 02:10
  • 1
    @Mark, actually, IL is fully object-oriented. The main difference is that it works with an operation stack with label-based branching rather than using nice high-level constructs like loops and evaluated arithmetic/logical expressions. This is why IL can be decompiled to code that looks remarkably like the C# used to compile it. – Dan Bryant Jan 10 '12 at 02:25

3 Answers3

6

My experience with nifty extensible frameworks has been that most shops have their own nifty extensible frameworks (usually more than one) and are not likely to steal them from vendor-provided source code. If you are under obligation to provide source code (due to some business relationship), then, at least in my mind, there's an ethical obligation to provide the actual source code, in a maintainable form. How you protect the source code is a legal matter and I can't offer legal advice, but really you should be including some license with your release and dealing with clients who are not going to outright steal your IP (assuming it's actually yours under the terms you're developing it.)

Dan Bryant
  • 27,329
  • 4
  • 56
  • 102
  • Thanks Dan. In this case, the framework is a large superset of what the actual customer facing tool performs. In theory I could get in there and refactor it, but I thought perhaps there was a crafty tool or method that would help. It is sounding less likely based on the discussions though :) – Mark Williams Jan 10 '12 at 02:12
  • 1
    @Mark, it's possible you can extract the 'customer-specific' code and include your own code as binary dependencies, but that can get a bit tricky. It's really up to the relationship you have with the client and what they're expecting. – Dan Bryant Jan 10 '12 at 02:54
3

As had already been said, if this is a requirement based on restrictions of contracts then don't do it. In short, providing a version of the source that differs from what they're actually running becomes a liability and I doubt that it is one that your company should be willing to take. Proving that the code provided matches the code they are running is simple. This is also true if you're trying to avoid license restrictions of libraries your application uses (e.g. GPL).

If that isn't the case then why not provide a limited version of your extensibility framework that only works with internal types and statically compile any required extensions in your application? This will allow the application to continue to function as what they currently run while remaining maintainable without giving up your sacred framework. I've never done it myself but this sounds like something ILMerge could help with.

M.Babcock
  • 18,753
  • 6
  • 54
  • 84
  • Thanks M. That last part about static compilation of extensions sounds interesting - I will look into it. Thanks for the other points also. – Mark Williams Jan 10 '12 at 02:17
1

If you don't want to give out framework - just don't. Provide only source you think is required. Otherwise most likely you'll need to either support both versions in the future OR never work/interact with these people (and people they know) again.

Don't forget that non-obfuscated .Net assemblies have IL in easily de-compilable form. It is often easier to use ILSpy/Reflector to read someone else code than looking at sources.

If the reason to provide code is some sort of inspection (even simply looking at the code) you'd better have semi-decent code. I would seriously consider throwing away tool if its code looks written in FORTRAN-style using C# ( http://www.nikhef.nl/~templon/fortran/fortran_style ).

Side note: I believe "nifty extensible frameworks" are one of the roots of "not invented here" syndrome - I'd be more worried about comments on the framework (like "this code is @#@#@ because it does not use YYY pattern and spacing is wrong") than reuse.

Alexei Levenkov
  • 98,904
  • 14
  • 127
  • 179
  • "If you don't want to give out framework - just don't." That may not be possible depending on the contract. We always put a specific exclusion in our contracts for our common code where we want to keep IPR. – Rup Jan 10 '12 at 09:53