Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
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!
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.
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.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 8 years ago.
Improve this question
I want to build websites in a modular fashion, so I can get better code reuse and abstract away some implementation details. I'm looking for advice on how to code such a website with ASP.NET and Visual Studio, and modules for such a website, because at the moment my websites don't have this nice property.
At the moment I'm working on a web-app that's providing a pretty straight-forward internally facing contact manager for a company. We plan on using identical contact managers (pointing to different databases) for each of our independent customer-facing websites (each for one of the company's businesses). I'm using ASP.NET MVC in C# with EntityFramework. What I'd like, is to be able to simply drop this contact manager package/project/class-library into a Visual Studio solution for an ASP.NET MVC Website, and then just add whatever 'wiring' I need to get them working together. I've seen the use of "areas" within MVC apps, that basically function as mini MVC applications, but it's been messy and actually less maintainable because of configs and different areas wanting different versions of assemblies (this is not code I wrote, and I want to avoid writing code like this). I have an idea of what this would look like in terms of data-objects and box&line diagrams; unfortunately, I don't know what this looks like in terms of views, controllers, projects, or assemblies.
The thing is, as a relatively unseasoned programmer, I've never done this before, so need advice on how to proceed. I'm unfamiliar with the patterns/idioms I need to implement this. So while I have the theoretical knowledge of how to write nice modular software architectures, I don't know they end up looking like in-terms of their actual classes, namespaces, and Visual Studio Projects/Solutions.
My question is, how do I build a website that's more modular than your standard MVC? And, if you have experience doing this (or attempting to), could you please share it? Or even better, can you offer a concrete example of such an architecture? (note this will probably require a link to something not on stack overflow, since you can't copy and paste an entire code-base to stackoverflow).
Apologies for not having a specific question, but this is a bit more complicated than a simple query of "how to traverse a b-tree", "why isn't my code compiling", "does anyone have a regex to do the thing I want", "I wrote some terrible code and now it broke", and "I haven't read the documentation (assuming there is any) and now I'm getting an exception that I don't understand". There likely isn't a single answer, because programming is complicated, solving real-world problems takes thought, and writing good code can be hard. Also, I can't exactly post the code I'm working with because of this thing in my contract known as a confidentiality clause, and not that anyone would read through 100's of thousands of lines of code and tell me how to make it better. \end_rant
I think you are looking for the "Onion Architecture".
Here's a live implementation of the Onion Architecture over on GitHub that uses Web API, MVC etc. It uses the all familiar Northwind database. So you can browse through the code and solution after you learn about this architecture and make sense of it and incorporate the parts you need in your project / solution.
Also, here's a nice tutorial on how to develop using this approach.
Finally, a Channel 9 Video that was what I originally found a few years back when I was researching the same thing, and found it very useful.
ASP.NET MVC Solution Best Practices
This video also takes an existing monolithic project and turns it into an Onion Architecture implementation, along with reasoning on why we are doing what at every step.
First of all you have to direct yourself in implementing your systems based on an approach that can provide complex systems that will not make everyone furious in waiting.
This is commonly known as the Domain-Driven design.
Then comes SOLID. SOLID represents architectural choices that will make your system easy to maintain and extend.
See SOLID in action using C#
All these along with Patterns of Enterprise Application Architecture can keep you busy for all your career and yet it could not be enough.
trying to follow the above in your programming will give you eventually a "less-monolithic" system and modular.
In ASP.NET MVC terms the above could mean:
Keep the MVC paradigm. Do not feed your controllers more than they should eat. Keep them only for what they are. Traffic cops. Also do not put logic in your views in order to keep them abstracted.
Maintain your logic in a separate "space". By the word "space" i mean a separate project, solution, assembly....whatever you think fits to your application size that you are building.
Use MVC Areas for what they are supposed to be. They fit perfectly for the FrontEnd / Admin case. You want to have a frontend that looks and operates differently from the backend, but obeys some general system rules.
Use Web API to make your application open and expendable. This will bring Javascript into play which itself needs to be addressed regarding SOLID e.t.c..
Do not overdose your application with javascript frameworks just for the shake of it. Use what you really need.
Use IoC container like Ninject to manage your dependencies..Marry your interfaces and let IoC resolve your implementations
If you going deep in javascript , take your time to define your viewmodels correctly. They are the contracts between 2 different worlds so they must be clear.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
As we are going to developing some public API for other applications to integrate with, someone suggests that we should delay the security stuff until the methods of the API have been done, so the third party application will have something to work with! Is it a good approach to resolve the issue, or should we put security in place and then develop the API itself?
EDIT:
The issue here is the cost.Let's say that if you have it in the first place, I think that you won't have to revisit the APIs to make changes due to security stuff, especially with the third party application, which is maintained by another team.
If we delay it until everything has been done and integrated, then the other team has to modify and change code as well.
So from your experience, what will cost less?
You should have the design complete from the start, including security. Changing the design later will cost much more. Implementation may well be either delayed or incomplete at first.
If you don't e.g. know the granularity of access rights you will have to do a lot of redesign when you later find out that it must go beyond table access or beyond SIDU and in fact work a row level..
Putting in dummy functions and working out the details of how to implement the real thing later is more or less free but to do that you first need to know what the customer needs and plan for it!
It depends on...
The overall risk as it relates to the security for your API. We talking banking/life-and-death or cat pics? The more risk, the more I'd want to address that upfront.
The general level of skill and experience of your team. Folks with more experience are less likely to paint themselves into a corner.
Applicable experience securing an API. If it's everyone's first go at this, I'd at least do detailed planning upfront.
I'm all for kicking the can on security, secure authentication, ACLs, etc. when possible. But don't just say, "Let's do it later" without getting a good handle on the risk that decision might incur. In all likelihood those discussions will yield a viable path forward should you have to start to implement the security concerns sooner than planned.
Security is a CROSSCUTTING concern, which means, it penetrates(and should) every level of the architecture. Why not use Basic Auth and share the key with your third party app developers instead?
Security must always be a concern. It won't help delaying if your APIs are flawless and your security system is flawed.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
I've been working for a couple of years on a small project, almost by myself, with the eventual help of some colleagues. The project is getting out of my hands, because the size of the code is growing (around 20K lines now) and the initial expectations I had for it have outgrown my own ability and time. So now I want to open source it, with the hope to attract some contributors. My motivations for going open source are these:
The project is rather academic (a library of algorithms for scientific computing), and I don't really have any economic interest in it.
The project is getting too big for me to handle it by myself, and the number of features I've planned are enough to keep a small team motivated (I think).
It needs a lot of testing, not just unit testing, but testing in the real world to see if the API is easy to use, the performance is as expected, etc.
I'm sure it has a lot of bugs, but I can only find a few, since its me alone testing it.
It needs proper documentation, because the API is getting a bit complex.
Other than that, I think that the project could benefit from a comunity in terms of deciding which features are most needed, and creating a set of guidelines for the future development.
I'm using Git, so my first thought was to publish it on Github and/or Codeplex. Besides that, what would be the steps to help to slowly grow a community of users and perhaps developers around it? Do I need a domain of my own, or should I stick to Github/Codeplex? How do I set up a platform for collaboration between developers potentially geographically separated? Should I set up a mailing list? And most important, how do I attract people to use it and collaborate with it?
The project is a .NET library for optimization and machine learning, written in C#.
There is only one piece of advice I can give here; use Github. It is common, (pretty much) everyone knows about it, it is easy to use, and the community who you are trying to attract is already on it. It has a ton of tools which you may not have even thought about, but may come in handy. It it pretty much the perfect solution for what you're looking to do, so don't overthink it.
As for attracting people to use it and contribute, if it is something that is useful and good, people will find it. I have found a ton of obscure projects with a simple google. If someone googles for something related to your project (and it is appropriate named and such) they will likely find it. There isn't really much you can do to force a demand though, just let it happen. As for contributors, people who are using it will likely contribute they're additions back. Just be sure to stay actively involved in managing it (monitoring pull requests, etc). If no one is accepting requests or managing versions, contributors will likely start to give up on your project.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
First of all, I understand that almost all applications can be cracked (especially written in C#). My question here is to make it a little bit harder to crack.
Suppose that the user has saved the License file under the Application.StartupPath, where all users can read.
And then, every time when the application starts, it will check if it can find and verify the license file.
If the application can find and verify, we let the user to continue with full functionalities.
If not, we prompt a MessageBox showing "Unlicensed, continue to use with trial version, functionalities limited."
My question is, if I'm a hacker/cracker, I would try to get around or bypass the licensing check instead of cracking the license file, because, if we use RSA signature, it's very difficult to crack a license file.
So where should we put the license check?
P.S.: and also, is it safe if I put a global variable IsLicensed (true / false) to limit the functionalities? Is it easy for a hacker to change IsLicensed = true?
The #1 law of software licensing: You don't control your software once you allow it to be installed on a computer you don't control.
If you want to keep control over your code, you need to make it a web service and give the end user just a thin client that interfaces to that web service.
In many scenarios, this is unacceptable, because users want to be able to use their software even when they don't have an internet connection.
In almost all cases, you should focus on making the user experience better, and all forms of copy protection make it worse instead. Once you get to the point where the experience of downloading from a warez site and running it through several virus scans is better than doing the license setup for the legit version, you've lost.
You can obfuscate the code (make it harder to decompile/use the reflector on it), but with enough energy and knowledge, it will get broken, after that it's quite easy to change the bytecode of the assembly, thus circumventing the license check. Also, you could invest the money to make it possible for you to sign your assemblies, which would make it harder to change the assembly itself, but with enough energy (more than just breaking the obfuscation) this can also be circumvented.
Your goal shouldn't be to make the license process unbreakable, but to make your software itself worth to buy. This is a much better protection. Crackers (and only them, hackers are something completely different, see this article for more) won't be hindered by that, but with the software being worth it, much more people would buy it.
I think that check should be done in several different places in the source code; it is much harder to catch all of them than only one. Also, if wants to protect program written in C# (or any other .NET language), one should consider to use some obfuscator. In counterpart a cracker or even lamer will be able to crack a program using some software like .NET Reflector
As mentioned previously, one can simply use .NET reflector to get the entire source code of your software (in fact, it can even get it in VB.NET or other languages even if you're written it in C#!). You must obfuscate your assembly if you hope to have even a chance at slowing a cracker's progress.
What is to stop people from directly copying licenses? If you have a license which is signed, it will then just be signed in two places -- what have you put in place to stop this? Never mind whether a global variable would further weaken your protection without taking into account trivial "cracks."
There really is no good answer to this as Ben Voigt pointed out. If you need something that is uncopyable, make it a closed-source web application. Astalavista will show you that most things have been cracked. Adobe products which cost thousands of dollars have been cracked and I'm sure their employees are quite well versed in copy protection techniques.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
We have a desktop application which needs to expose API.
Some people say: API should have an abstraction layer so actual implementation can change in future versions.
Others say: API should be version specific. So an API which uses version X will only work with it. Version X+1 will also deploy the dll's of version X in order not to break existing usage. This is claimed to be aligned with how frameworks like .Net or Silverlight works.
What is your opinion?
Some questions that you should consider:
What's the likely expectations of your users?
Are you likely to need to make breaking changes between versions?
How much would it cost you in development effort to maintain compatibility across versions, based on any roadmap you currently have?
My opinion is that you should maintain API compatibility across versions if at all possible. Microsoft have achieved it, mostly, with Office and it's why there are so many add-ins, accessories and LOB applications built around them. I, for example, wrote an application on-top of Access XP that used Excel automation quite heavily and it works without error in Office 2010. That's what I call compatibility!
I have found that versioning an interface is a useful tool to implement breaking changes.
You should do your best to get your API interfaces right the first time.
When you have a breaking change (changing existing signatures, so client code must be recompiled), you must change the interface, and when you do so you can change the version. Non-breaking changes (e.g. adding new features to a different class) shouldn't change the version, if you can avoid it.
Use the idea of closed for modification, open for extension. Any parts of the API you expose should not change in future versions if at all possible. (Parts you don't expose can be modified, provided they still function the same). A programmer expects to use an API and have that code work for it's lifetime, without worrying about the version he is referencing.
Consider that in later versions of the API, you might expose new features that each user of your API might want to adopt - but he already has code written against the old version of the API. He should be able to plug in the new parts without rewriting his old code (Assuming the new parts don't rely on the breaking changes).
If there are breaking changes to be made, you should not remove the old way of doing it, but mark it [Obsolete], and give a clear message on how it should be updated to the newer API.
If you are using Net as a reference you should notice that they take a hybrid approach, they use a bit of both, do not confuse CLR version with NET version.
You should consider your app uses in order to find the answer for you.
My money is on mantaining API compatibility accross all versions as possible.
However there are drawback to that as well.
Regards
If you do decide to go version specific make sure you're very up front with your users. I've missed deadlines half a dozen times do to my vendors changing their web services without notifying me and having to scramble to come up with a solution