C# use dll in various directory locations
-
I have a C# 2008/2010 application that is currently accessed as a dll file and I would like to change the application so that the dll is accessed though as a reference. The code that calls the dll is a process and the code looks like the following:
Process theProcess = new Process();
theProcess.StartInfo = new ProcessStartInfo("filename.ext");
theProcess.StartInfo.Arguments = "args here"
theProcess.WaitForExit();
theProcess.Start();
The problem is the dll is currently placed in various locations like unit test area, client acceptance testing, system testing, and then into production by the 5 applications that call it. The application currently obtains the various locations based upon values in the app.config file. If I add this dll has a reference to the programs that call it, how will I tell those calling programs where to obtain the 'correct' directory location? Would I use the app.config file? Can you show me code and/or explain to me how to solve this issue?
-
I have a C# 2008/2010 application that is currently accessed as a dll file and I would like to change the application so that the dll is accessed though as a reference. The code that calls the dll is a process and the code looks like the following:
Process theProcess = new Process();
theProcess.StartInfo = new ProcessStartInfo("filename.ext");
theProcess.StartInfo.Arguments = "args here"
theProcess.WaitForExit();
theProcess.Start();
The problem is the dll is currently placed in various locations like unit test area, client acceptance testing, system testing, and then into production by the 5 applications that call it. The application currently obtains the various locations based upon values in the app.config file. If I add this dll has a reference to the programs that call it, how will I tell those calling programs where to obtain the 'correct' directory location? Would I use the app.config file? Can you show me code and/or explain to me how to solve this issue?
Usually, the .DLL referenced will be in the same folder as the .EXE calling it. But, if that's not possible because of multiple applications refering to the same .DLL, you can put it in another location suiteable for the task, such as a folder under C:\Program Files\Common Files\companyName. Read this[^] for more information on your options. You could use a probing path in the app.config for all the applications, but all applications would have to be under the same folder under program files and the .DLL path would have to be under the base application path.
A guide to posting questions on CodeProject[^]
Dave Kreskowiak -
I have a C# 2008/2010 application that is currently accessed as a dll file and I would like to change the application so that the dll is accessed though as a reference. The code that calls the dll is a process and the code looks like the following:
Process theProcess = new Process();
theProcess.StartInfo = new ProcessStartInfo("filename.ext");
theProcess.StartInfo.Arguments = "args here"
theProcess.WaitForExit();
theProcess.Start();
The problem is the dll is currently placed in various locations like unit test area, client acceptance testing, system testing, and then into production by the 5 applications that call it. The application currently obtains the various locations based upon values in the app.config file. If I add this dll has a reference to the programs that call it, how will I tell those calling programs where to obtain the 'correct' directory location? Would I use the app.config file? Can you show me code and/or explain to me how to solve this issue?
Question seems confusing to me. A dll is not an executable so you are not using Process to run it. So what is the exact form that it exists in now? What is the exact form that it will be? And why do you think you need to access it dynamically? Although the answer to that might be explict by the answer to the previous two questions. But that said you can't answer how to dynamically load anything until you first decide how it will be delivered into production.
-
Usually, the .DLL referenced will be in the same folder as the .EXE calling it. But, if that's not possible because of multiple applications refering to the same .DLL, you can put it in another location suiteable for the task, such as a folder under C:\Program Files\Common Files\companyName. Read this[^] for more information on your options. You could use a probing path in the app.config for all the applications, but all applications would have to be under the same folder under program files and the .DLL path would have to be under the base application path.
A guide to posting questions on CodeProject[^]
Dave KreskowiakIf I place the dll in the same directory path for all 5 programs to access, that would be a good idea! Currently each program executes the dll by the value placed in the app.config file for each of the 5 applications. Would I be able to continue to use the same logic? If not,what would need to change?
-
Usually, the .DLL referenced will be in the same folder as the .EXE calling it. But, if that's not possible because of multiple applications refering to the same .DLL, you can put it in another location suiteable for the task, such as a folder under C:\Program Files\Common Files\companyName. Read this[^] for more information on your options. You could use a probing path in the app.config for all the applications, but all applications would have to be under the same folder under program files and the .DLL path would have to be under the base application path.
A guide to posting questions on CodeProject[^]
Dave KreskowiakIf I place the dll in the same directory path for all 5 programs to access, that would be a good idea! Currently each program executes the dll by the value placed in the app.config file for each of the 5 applications. Would I be able to continue to use the same logic? If not,what would need to change?
-
If I place the dll in the same directory path for all 5 programs to access, that would be a good idea! Currently each program executes the dll by the value placed in the app.config file for each of the 5 applications. Would I be able to continue to use the same logic? If not,what would need to change?
sc steinhayse wrote:
If I place the dll in the same directory path for all 5 programs to access, that would be a good idea!
Since I have no idea where these apps are installed and what your business requirements are, I have no idea! But, if your requirement is that every app has the exact same version of the .DLL, it would probably be a bad idea to have 5 copies of it running around.
sc steinhayse wrote:
Currently each program executes the dll by the value placed in the app.config file for each of the 5 applications. Would I be able to continue to use the same logic? If not,what would need to change?
This means absolutely nothing. I have no idea what you mean by "executes the DLL by the value placed in app.config". What value?? What does it describe?
A guide to posting questions on CodeProject[^]
Dave Kreskowiak -
sc steinhayse wrote:
If I place the dll in the same directory path for all 5 programs to access, that would be a good idea!
Since I have no idea where these apps are installed and what your business requirements are, I have no idea! But, if your requirement is that every app has the exact same version of the .DLL, it would probably be a bad idea to have 5 copies of it running around.
sc steinhayse wrote:
Currently each program executes the dll by the value placed in the app.config file for each of the 5 applications. Would I be able to continue to use the same logic? If not,what would need to change?
This means absolutely nothing. I have no idea what you mean by "executes the DLL by the value placed in app.config". What value?? What does it describe?
A guide to posting questions on CodeProject[^]
Dave KreskowiakHere is an example of the code that I am referring to in my question:
strConsoleAppLocation = ConfigurationManager.AppSettings["dll_location"];
string Process_Arguments = null;
Process RPT_Process = new Process();
RPT_Process.StartInfo.FileName = strConsoleAppLocation;
Process_Arguments = " 7 " + strCUSTID + " 1";
RPT_Process.StartInfo.Arguments = Process_Arguments;
RPT_Process.Start();
RPT_Process.WaitForExit();
RPT_Process.Dispose(); -
sc steinhayse wrote:
If I place the dll in the same directory path for all 5 programs to access, that would be a good idea!
Since I have no idea where these apps are installed and what your business requirements are, I have no idea! But, if your requirement is that every app has the exact same version of the .DLL, it would probably be a bad idea to have 5 copies of it running around.
sc steinhayse wrote:
Currently each program executes the dll by the value placed in the app.config file for each of the 5 applications. Would I be able to continue to use the same logic? If not,what would need to change?
This means absolutely nothing. I have no idea what you mean by "executes the DLL by the value placed in app.config". What value?? What does it describe?
A guide to posting questions on CodeProject[^]
Dave KreskowiakI am sorry about the confusion in the terminology. Each of the 5 program calls an exe and passes parameters to the exe. What I am suppose to do is not call an 'exe'. I am suppose to have call each 'exe' in a faster manner. what would a faster manner be? callin a dll?
-
I am sorry about the confusion in the terminology. Each of the 5 program calls an exe and passes parameters to the exe. What I am suppose to do is not call an 'exe'. I am suppose to have call each 'exe' in a faster manner. what would a faster manner be? callin a dll?
If you're talking about the length of time it takes to launch an external .EXE, then you have no choice but to move the code that's in the .EXE into the code that's launching it. This will, of course, require you to rework your code in all 5 apps. You could put the code you're using in the .EXE into a Class Library project, which compiles to a .DLL, and then you've got the code in one place which you can use in any other .EXE.
A guide to posting questions on CodeProject[^]
Dave Kreskowiak -
If you're talking about the length of time it takes to launch an external .EXE, then you have no choice but to move the code that's in the .EXE into the code that's launching it. This will, of course, require you to rework your code in all 5 apps. You could put the code you're using in the .EXE into a Class Library project, which compiles to a .DLL, and then you've got the code in one place which you can use in any other .EXE.
A guide to posting questions on CodeProject[^]
Dave KreskowiakI have a question about your following statement, "You could put the code you're using in the .EXE into a Class Library project, which compiles to a .DLL, and then you've got the code in one place which you can use in any other .EXE." If I do what you suggest above and place the code into a .DLL, that means the dll would not take parameters correct? If this is true, is there another way i can share the code between all the programs and pass the parameter values?
-
I have a question about your following statement, "You could put the code you're using in the .EXE into a Class Library project, which compiles to a .DLL, and then you've got the code in one place which you can use in any other .EXE." If I do what you suggest above and place the code into a .DLL, that means the dll would not take parameters correct? If this is true, is there another way i can share the code between all the programs and pass the parameter values?
sc steinhayse wrote:
If I do what you suggest above and place the code into a .DLL
DLL's don't take parameters, period. They are containers for classes and modules, which contain methods, which can take parameters. You SERISOULY need to pickup a beginners book on C# and work through it.
A guide to posting questions on CodeProject[^]
Dave Kreskowiak -
sc steinhayse wrote:
If I do what you suggest above and place the code into a .DLL
DLL's don't take parameters, period. They are containers for classes and modules, which contain methods, which can take parameters. You SERISOULY need to pickup a beginners book on C# and work through it.
A guide to posting questions on CodeProject[^]
Dave Kreskowiakthanks!