Click here to Skip to main content
14,302,071 members
Rate this:
Please Sign up or sign in to vote.
See more:
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
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?
Rate this:
Please Sign up or sign in to vote.

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!
   
Comments
   
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.
   
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...
Rate this:
Please Sign up or sign in to vote.

Solution 2

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
   
v2
Comments
Hermanito72 5-Feb-12 5:41am
   
SAKryukov, thanks for your elaborate answer.

I will surely look into your commandline parameters library, that way I don't need to reinvent that part :-)

I totally agree on your point of view on version control. Unfortunately I tend to agree that I work with moderate idiots (I won't go as far as qualifying them as extreme :-))
The company does have proper development procedures and source control (Visual Studio Ultimate clients on Visual Studio Team Foundation Server), but the tool I am creating is not deemed important enough to give me a license to VS Ultimate. So I have to make do with the Express version.

About subversion: you are right that it is open source, but there are many implementations that are also freeware, of course there are also commercial implementations. But anyway, it is not trusted, and they will not install it just for me.
   
I'm glad to hear that your idiots are only moderate :-)

In my opinion I tried to explain in other posts, Revision Control should be Open Source. This way, you really are not on mercy of developers of any proprietary code. Now, commercial implementation of Subversion is nonsense. I always used non-commercial one; and it is very good. There are also Git, Bazaar or Mercurial.

If you cannot get a special server for Revision Control and other needs, at least install Subversion on your work computer and keep everything in your own code base. One day it will save you and your company a million.

--SA
Hermanito72 5-Feb-12 5:43am
   
Also, thanks for editing my incorrectly posted followup to OriginalGriff, I now think I understand the posting and replying system...
   
Also keep in mind: when you post a comment to a question, answer, other comment or any other post, original author of the post and every one in the middle get e-mail notification of your post.

You are very welcome.
Good luck, call again.

--SA

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




CodeProject, 503-250 Ferrand Drive Toronto Ontario, M3C 3G8 Canada +1 416-849-8900 x 100