|
Yes, you could allow each app to take an optional parameter to execute a particular method then exit -- and that may be a good idea. Using a switch is OK, but may be more maintenance than you want.
Additionally, you could have the MENU app have references to the other apps and call their methods directly rather than using a Process. You could even use the other apps as plug-ins if you want.
Granted, this kind of thinking leads to a fairly complex framework with its own maintenance issues, so you need to use your own judgement about how you predict the system will grow in the future.
|
|
|
|
|
I would just recommend MEF for the plug-in architecture, but I know how you like to re-invent everything .
|
|
|
|
|
|
I can solve using reflection:
I instantiate an Assembly aP1 the assembly P1, then I can easily call methods...
It is a good idea?
|
|
|
|
|
|
|
No, it's hacked up work around for a bad design.
What you should have done is put all the functionality you wanted to call into a class library. Then you can call that functionality from either the console applications OR from your menu driven application. The menu app would use the class library directly and not bother with teh console apps at all.
|
|
|
|
|
Oky, but in this way each project can not also used as stand alone Console Project (a functionality that I need)
|
|
|
|
|
There isn't a webservice connected in this chain somewhere is there?
|
|
|
|
|
Willing to bet your life on that??
YES, you can still use the Console apps seperately from the menu driven version. You would just need to ship the library .DLL with the console .EXE's.
|
|
|
|
|
There are many paths to a solution and you should not consider using Process or Reflection if you are writing all the code.
Another thought to go with Dave's is to split the library into sections and have the smaller apps only include the parts they need.
Definitely give it more thought before writing anything.
|
|
|
|
|
If you want P1 and the like to be plugins, i.e. you can add or remove them at runtime and have the application work out which ones are present, then you need to do something like this, though there are frameworks that could possibly help you with it.
If you are just trying to create a multi-part application, you should statically link the assemblies together at compile time, by setting P1, P2 etc as references in your top level application (either in your IDE or by using /r:P1.dll etc on the command line to csc). Think about whether they even need to be separate projects/assemblies; unless you're planning to reuse some of the components in another application, there's not really any need for them to be.
|
|
|
|
|
I have added a excel spreadsheet with 2 columns. Could anyone be kind enough to point me in the direct of how to loop through each of the cells in the first column, or even provide the code to do it.
Thanks in advance.
|
|
|
|
|
|
I want to point the best alternative in my experience is to use NPOI library you dont need excel installed.
There are several examples in the codeplex site.
AUS Enrique Ferreyra
(Pachu)
|
|
|
|
|
You should have sent this reply to the original questioner, rather than to me.
One of these days I'm going to think of a really clever signature.
|
|
|
|
|
Thanks for that. Do you have any links relating to the syntax for referencing the resource file itself?
|
|
|
|
|
What do you mean by "resource file"? Your question asked about accessing Excel columns.
One of these days I'm going to think of a really clever signature.
|
|
|
|
|
|
Sorry, I don't know how you would access the content from there, you would probably need to write it to disk first. However, since resources are constant data I see no benefit in putting an Excel formatted file into your resources, it would be much easier to convert it to XML or similar.
One of these days I'm going to think of a really clever signature.
|
|
|
|
|
It's a data of data that I use to do lookups on. I was doing this project in Access, but am now using Visual Studio. I was only putting the data in an Excel spreadsheet because I thought it would be easier to access.
For this type of information (2 columns (lookup A, bring back B), can you suggest an alternative method of storing the data within the solution for retrieval?
You mentioned XML - would that be suitable?
|
|
|
|
|
The first question you need to answer is: what is this data for, and why is it necessary to hold it in a resource, rather than as a constant table in the program? If you are certain that this is the best way to store it then you should choose a storage medium that is easy to access from within the program. You could use XML, a text or binary stream etc. It all depends on how much data and what you need to use it for.
One of these days I'm going to think of a really clever signature.
|
|
|
|
|
As for the data I have, it's around 2000 x 2 "cells".
As I'm unfamiliar with how to approach this, a resource file was just one option. Currently I'm having the user select my original database, and then importing the table to a datatable via OLEDB.
Whilst this works, ideally I'd like the data embedded so I don't have to distribute a database with the actual application.
|
|
|
|
|
If it is constant data then it should be embedded into the program rather than held as an external database, that just adds unnecessary work.
One of these days I'm going to think of a really clever signature.
|
|
|
|
|
Ok, thank you.
If anyone can propose the best way of doing this, I'd be most grateful, as I know nothing on the subject. Many thanks.
|
|
|
|