0

Overview

  • Over the last 3 years we've built a full-featured software package in C#
  • Our software was architected in such a way that it handles a lot of the low-level plumbing required for the application so that our developers can focus on the specific problem they are trying to solve rather than all the minutiae. This has improved development and release times significantly
  • As such, the code is broken out into various projects to give us logical separation (e.g. a front-end MVC app, a services layer, a core framework layer, etc)
  • Our core framework project has a lot of functionality built into it (the main 'guts' of the application) and it has been carefully organized into various namespaces that would be familiar to all (e.g. Data Access, IO, Logging, Mail, etc)
  • As we initially built this, the intent was always for our team to be the target audience, our developers coding the various new pieces of functionality and adding to the framework as needed.

The Challenge

  • Now the boss wants to be able to open our codebase up to 3rd party developers and teams outside of our own company. These 3rd party folks need to be able to tap directly into our core libraries and build their own modules that will be deployed along with ours on our servers. Just due to the nature of the application it is not something we could solve by exposing functionality to them via REST or SOAP or anything like that, they need to work in an environment much like our own where they can develop against our core library and compile their own DLLs for releases
  • This raises many concerns and challenges with regard to intellectual property (we have to be able to protect the inner workings of our code), distribution, deployment, versioning and testing and releases and perhaps most important how we will shape the framework to best meet these needs.

What advice would you offer? How would you approach this? What kind of things would you look to change or what kind of design approach would you look to move towards? I realize these questions are very open-ended and perhaps even vague but I'm mainly looking for any advice, resources/tutorials or stories from your own background from folks who may have faced a similar challenge. Thanks!

bruiseruser
  • 343
  • 4
  • 12
  • 2
    MEF, MEF and more MEF! Create `interface`s for all your libraries and let the third parties implement those interfaces. then load these "plug in"s via MEF. – Federico Berasategui Mar 18 '13 at 17:46
  • @HighCore - yup, fortunately we're already there for probably the largest piece of the puzzle we chose to implement it with MEF because the added flexibility/extensibility was highly desirable (that decision looks better and better every day ;) Part of the challenge though is that there are a lot of helper classes and logic that we need to make available to them and I'm not sure how best to do that for everything, thanks! – bruiseruser Mar 18 '13 at 18:28

2 Answers2

2

I'm not sure the MEF answer really solves your problem. Even using Interfaces and MEF to separate the implementation from the contracts, you'll still need to deliver the implementation (as I understand your question), and therefore, MEF won't keep you from having to deliver the assemblies with the IP.

The bottom line is that if you need to distribute your implementation assemblies, these 3rd parties will have your IP, and have the ability to decompile them. There's no way around that problem with .NET, last I checked. You can use obfuscation to make it more difficult, but this won't stop someone from decompiling your implementation, just make it harder to read and understand.

As you've indicated, the best approach would be to put the implementation behind a SaaS-type boundary, but it sounds like that's out of the question.

What I will add is that I highly recommend developing a robust versioning model. This will impact how you define your interfaces/APIs, how you change them over time, and how you version your assemblies. If you are not careful, and you don't use a combination of both AssemblyVersion and AssemblyFileVersion for your assemblies, you'll force unnecessary recompiles from your API clients, and this can be a massive headache (even some of the big control vendors don't handle this right, sadly). Read up on these, as they are very important for API/Component vendors in my opinion.

NDAs and/or License Agreements are another way, as @trailmax indicates, if you feel your users will respect such agreements (individuals vs. companies may view these type of agreements differently).

Oh, also make sure that you Sign your Assemblies with a Strong Name. And to do this, you'll probably need to establish a strategy to protect your Signing Keys. This seems simple at first, but securing your signing keys adequately is not as easy as it appears at first blush. You often have to have multiple sets of keys for different environments, need to incorporate the keys into CI/CD systems, and need to insure access to the release keys is tightly held.

Community
  • 1
  • 1
Brian S
  • 5,675
  • 1
  • 22
  • 22
  • see my comment to HighCore above. We do have MEF as part of our solution and fortunately it is implemented for the main part of the framework that our 3rd parties will interface with. The challenge will be for us to provide access to all the various helper objects that are needed to develop against our library, a lot of which we wish to keep private and 'black-boxed'. Thank you for your comments, very helpful, I would vote you up if it let me but it's a new account – bruiseruser Mar 18 '13 at 18:36
  • +1 for assemblies signing and file visioning – trailmax Mar 18 '13 at 18:57
  • +1 for SaaS. With it and authentication-generated code, the common API used by web API's. – Fendy Mar 19 '13 at 09:10
0

As @HighCore already said, implement interfaces for all the stuff you want to expose. Put them into a separate project/repository and give read-only access to the project/repository. But your interfaces must be properly documented, otherwise it might be painful for other guys.

This way your code is not really visible to them, and they can still work on it.

If that does not work-out, and you are forced to show them your code, get them to sign NDA. NDA should state that your code is yours and they can't redistribute it in any way.

I guess my answer is as vague as the question, but gives you some ideas.

trailmax
  • 34,305
  • 22
  • 140
  • 234
  • thanks for the comments, I agree it is a difficult question to give a proper answer to, it's actually quite difficult to describe without giving any details away (and since i'm bound by NDA myself, it is tricky!) thanks tho – bruiseruser Mar 18 '13 at 18:38