2

I am writing a software suite which is essentially composed of two separate applications in C# .Net using WPF. Although they may look a little bit different they essentially work like a lite version and a full version of the same software package. The full version contains all of the functionality of the lite version.

I had previously done this by creating two separate applications which share a class library where all the common user controls go. But i am now wondering if there is any better design for this kind of architecture.

I was even thinking of creating one application and at runtime let it decide which version it was going to work as.

Could anyone with any experience with this type of problem please point me in the right direction.

Timmoth
  • 480
  • 2
  • 18
  • 1
    How about single application which works in lite-mode by default and need some kind of authorization to become full? Nobody cares about MBs now. Search for trial version, it's pretty same problem as for me ([click](http://stackoverflow.com/a/1417872/1997232)). – Sinatr Mar 29 '16 at 13:21
  • 2
    If you can turn your application into modular one, then you can make two editions with different set of modules (plugins). – Dennis Mar 29 '16 at 13:24
  • Your idea in paragraph 3 sounds good. In WPF it would be fairly natural to have portions of the UI hide or modify themselves according to some global setting. You could also use a lot of template selectors and have duplicate templates with names like "FooTemplate_Full" and "FooTemplate_Lite" -- when the XAML wants `templateName`, you look for `templateName + "_" + App.VersionID` or some such thing. – 15ee8f99-57ff-4f92-890c-b56153 Mar 29 '16 at 13:25
  • @Sinatr This is what i was thinking as an alternative to using a shared class library. I am just hesitant to do this as i feel like it might be bad practice. what if the requirements of the lite version change in such a way that it will become very different to the full version. Then I will end up with lots of code specific to one application but irrelevant to the other. – Timmoth Mar 29 '16 at 13:26
  • @Dennis this is very appealing to me. I may do this, it feels like a better solution then packing all the code for both into the same class library. – Timmoth Mar 29 '16 at 13:29
  • @Timmoth, you should know requirements. In such case 2 different applications (without shared library) might be the best options because they are completely independent. How you organize it? Well, 2 solutions. Copy/paste changes (bugfixes) between them when needed. – Sinatr Mar 29 '16 at 13:29
  • @Sinatr I know the current requirements - I also know for this specific application they are guaranteed to change in the near future. I don't like the idea of copy / paste changes. It really triggers alarm bells in my head as an easy place for huge bugs to crawl in. I am going to look more into a modular solution as suggested by Dennis above. – Timmoth Mar 29 '16 at 13:33
  • I'd avoid to deploy both full and light version **unless they're both free**. Best security is to do not deploy what they didn't pay for. **You can't get a - serious - general answer** (sorry) because it depends on specific scenario and application architecture/features but take a look to what MEF offers. Composition should make your life (little bit) easier plus some license/features verification. Upgrade to full version? Deploy missing/changed modules and update license... – Adriano Repetti Mar 29 '16 at 13:47

1 Answers1

0

Keep it Simple

My rule of thumb is whenever possible keep solution as simple as possible. That being said I would use the same composition you are using.

Usually break up projects like this:

Application Logic: CompanyPrefix.ProjectPrefix.Core, CompanyPrefix.ProjectPrefix.Data...etc.

Applications : CompanyPrefix.ProjectPrefix.ApplicationType.App, so some examples :

  1. CompanyPrefix.ProjectPrefix.Web.App
  2. CompanyPrefix.ProjectPrefix.Console.App
  3. CompanyPrefix.ProjectPrefix.Wcf.App

Since you have two Wcf Apps might want to do something like

  1. CompanyPrefix.ProjectPrefix.Wcf.Lite.App
  2. CompanyPrefix.ProjectPrefix.Wcf.App

So in this example both CompanyPrefix.ProjectPrefix.Wcf.App and CompanyPrefix.ProjectPrefix.Wcf.Lite.App point back to CompanyPrefix.ProjectPrefix.Core or wherever your business logic is.

About Dynamically Loading Assemblies

There is a way to dynamically load your libraries at runtime, but unless you're dealing with a modularized system of independent components would recommend against it.

If your heart is set on it there are a lot of resources on MSDN, would probably start here. Article about loading assembly into current application domain.

Come Up with a Checklist

One thing I find helpful is to come up with a checklist to help me make decisions in case I ever get stuck. Usually ends up being something like:

  1. Does this have business value?
  2. Does this make debugging harder?
  3. What are the Pros and Cons of doing it a new way versus the way I have done this in the past?

This isn't my exhaustive list but explains the point. This can really help too when you have a group of people that are largely sticking with choices for personal reasons that don't have any grounding, as well as a tool to use when you get stuck to make a decision and go with it

Dealing with Application Logic Changing (Write Clean Code)

Coming up with an over-complicated "never need to recompile entire application again" is a mistake I have made in the past. You're still going to need to deploy and compile something.

Most important thing about dealing with changes in application is to

  1. Have Code on Source Control (most important)
  2. Write Clean Code
  3. Write Tests
  4. Write Documentation ( I know no one likes to do this )
  5. Write some more Tests

What will consume most of your time when dealing with application changes is debugging so focus on reducing the amount of time you spend debugging not a amount of time you spend compiling and deploying

For Deployment setup Continuous Integration

If you have the ability to setting up CI would eliminate 99% of the hassle of changing the application. You lose a day or two setting things up for the first time, but it is well worth it.

Check out TeamCity and Travis CI

konkked
  • 3,161
  • 14
  • 19