Commandline and UI tool from the same codebase?

Question

0.00/5 (No votes)

See more:

.NET2.0

What is the best (or usual) way to tackle this?

I currently have a working codebase, with a UI frontend. I have been tasked to create a commandline version of the same tool. This will of course require some codechanges to allow for commandline parameters and such, but how can I work with the same backend classes in both versions of the program?
Should I use conditional compilation somehow?

This is to be done in Visual Studio Express 2008 (or 2010) without any form of source control (yeah, I know I should use it, but unfortunately that is not an option right now, because of security issues, I cannot install anything on my machine myself, and my request for a freeware tool like subversion has been turned down because 'freeware is bad', and the Express versions don't work with TFS, and I don't get a full version of VS)

Thanks for any advice...

Posted 4-Feb-12 23:06pm

Hermanito72

Add a Solution

Comments

Amir Mahfoozi 5-Feb-12 5:33am

Maintain application layers and create two separate projects one for command line(console application) and one for UI. What is the relation of this matter with source control and other software?

2 solutions

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

OriginalGriff · Accepted Answer · 2012-02-04T23:16:00

Solution 1

Hopefully, your project is already written properly, with the Presentation layer separate from the Business Layer. If it isn't then it will become a nightmare - so separate them now.

Ideally, you want the Business Lay in a DLL project, which is accessed from the Presentation layer (in a separate WinForms project) via a Reference. In this case it is a relatively simple matter to create a new CommandLine project which also accesses the Business Layer DLL.

If you don't have them well separated, then you are in for a world of pain!

Posted 4-Feb-12 23:16pm

OriginalGriff

Comments

Sergey Alexandrovich Kryukov 5-Feb-12 5:29am

OP commented:

OriginalGriff, thanks for your comments.

I did not separate the layers into different projects right now, but the code is separated in different classes. For instance: updating progress in the UI is driven by events from the business classes, so that can easily be cut loose just by not subscribing to the events in the commandline version.
There might be a few errors where the layers are not fully separated, but those can be fixed relatively easy, I think.

So, if I understand correctly, I need to:

- split up my current code into 2 projects: the BL and the UI
- add a third project which is the Console frontend
- both frontend projects reference the BL project

But it is still unclear to me how I build two separate EXE's from that. Should I simply switch my startup project to the frontend I want to build for, and then create the EXE? Or can I somehow configure it to always build the two separate EXE's each time I make a new build?
Or should I create only one EXE where the UI can be started via one of the commandline parameters?

OriginalGriff 5-Feb-12 5:48am

That's the idea, yes!

When you do a build in a solution, it builds all the projects - Winforms, DLL and Console - no matter how many of them there are. The "Startup Project" selection just picks which will run when you use F5 or SHIFT+F5 to run the solution.
Note that you can select (at least) Debug and Release builds too - so you can do a Release Build to temporarily issue the Winforms exe for testing / production, and keep the Debug build for testing while you develop the Console app. Debug builds do not affect the Release EXE or DLL files at all.

Sergey Alexandrovich Kryukov 5-Feb-12 5:31am

Right, a 5.
--SA

Hermanito72 5-Feb-12 5:55am

Okay, so when I have the three projects, and I create a full build, it should create two EXE's and one DLL?
For simplicity of installation however, I think they would like to get a commandline tool that is just the EXE, and doesn't need to also have a separate DLL file. Is this possible as well?

OriginalGriff 5-Feb-12 6:13am

You can - but it is a retrograde step. The problem is that once you recombine the BL and PL into one file, you end up with multiple sources, which have to be maintained in step. This always raises the possibility of a change in one set which has not been mirrored in the other. Much better to keep one source from both projects.
Don't forget that both the GUI and command line versions will need to have the .NET framework installed, so a setup program of some sort is going to be pretty much a necessity anyway. It can install a DLL automatically, so it isn't very much extra work for a lot less hassle and maintenance trouble in the long run to keep a single DLL referenced by both projects.

Hermanito72 5-Feb-12 6:51am

Thanks for the explanation. I should be able to figure out what to do now...

Sergey Alexandrovich Kryukov · Accepted Answer · 2012-02-04T23:27:00

First of all, it looks like you are mixing up two different notions: console application and command line. You can always use command line, event without console. You can even develop console and windowed application using exact same code processing command line parameters.

You can use conditional compilation, of course, but this is not the best option, and not the best way to organize software in a form good for maintenance.

I would advise to abstract out user interface so your application could use two different front ends as two (or more) different applications; one of them could be a console application, another one a WPF or System.Windows.Forms application. You need to put them all in one solution. Most of the code should be in the class libraries used by two or more applications.

By the way, you can use my easy-to-use library for processing command line parameters: Enumeration-based Command Line Utility[^].

As to the Revision Control: doing even the simplest work without Revision Control is just silly. I would stop everything and implement proper development procedures with Revision Control system.

Please see:
http://www.joelonsoftware.com/articles/fog0000000043.html[^].

See also this discussion: Revision control systems, which to choose from?[^].

Please also see my past answers on this topic:
Needs some words of wisedom to set up and/or use a server[^],
Make an unclickable form[^],
How can i structured to arrange source code when i create a new solution[^].

If you read these answers, you will probably understand my point of view I going to tell you below.

Subversion is not "freeware", not at all. It is Open Source, which is absolutely different thing. Will somebody tell you that "Open Source is bad"? Even it they won't tell you than, based just on the fact they already told you: the ugly truth is this: you are working with extreme idiots.

Therefore, I don't know how to help you. Certain things are not curable. If you want, show them my post. They can easily contact me through CodeProject and discuss this problem, but I doubt they will. :-)

—SA