Re: C# use dll in various directory locations - C# Discussion Boards

Re: how create a setup of a c# project to run on a server

29-May-13 4:58

OK, so you can either create two seperate installers, one for the database and one for the clients, or you can combine the two and the first client to install would go through the process to install the database on whatever SQL server the user specifies.

You REALLY have to be careful with record locking. It's just about never a good idea. The primary question is what happens if a client locks a record and then the client machine hangs?? How do you recover from a locked record that shouldn't be locked any more??

Concurrency issues are not easy to solve and you have to do research into what you're options are and how they affect your business process code.

A guide to posting questions on CodeProject[^]

Dave Kreskowiak

User349029-May-13 6:40

User3490

29-May-13 6:40

the setup process for the server it is the same with the setup process on laptop ?
or i have to follow different way to make the setup process for server?

Re: how create a setup of a c# project to run on a server

Dave Kreskowiak29-May-13 8:20

Re: how create a setup of a c# project to run on a server

29-May-13 8:20

What did i say? IT'S NO DIFFERENT. Windows Server is still frickin' Windiws! Everything works the scant same way.

A guide to posting questions on CodeProject[^]

Dave Kreskowiak

Clifford Nelson29-May-13 9:17

Clifford Nelson

29-May-13 9:17

You probably do want to create a service. Here is an article: A Windows Service Application[^]

C# use dll in various directory locations

sc steinhayse28-May-13 4:42

28-May-13 4:42

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?

Dave Kreskowiak28-May-13 5:04

28-May-13 5:04

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

sc steinhayse28-May-13 8:55

28-May-13 8:55

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?

Dave Kreskowiak28-May-13 9:14

28-May-13 9:14

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 steinhayse28-May-13 9:29

28-May-13 9:29

Here 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 steinhayse28-May-13 9:43

28-May-13 9:43

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?

Dave Kreskowiak28-May-13 12:34

28-May-13 12:34

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

sc steinhayse28-May-13 14:14

28-May-13 14:14

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?

Dave Kreskowiak28-May-13 16:14

28-May-13 16:14

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 steinhayse28-May-13 17:29

28-May-13 17:29

thanks!

C# obtain paramter values for dll

jschell28-May-13 8:43

jschell

28-May-13 8:43

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.

sc steinhayse28-May-13 4:41

28-May-13 4:41

Process theProcess = new Process();
 
theProcess.StartInfo = new ProcessStartInfo("filename.ext");
 
theProcess.StartInfo.Arguments = "args here"
 
theProcess.WaitForExit();
 
theProcess.Start();

I want to be able to pass argument values to the dll when it becomes a reference in the 5 programs that call it.
My problem is that I do not know how to pass the parameter values when the code is accessed as a reference. Thus can you tell me how to pass argument values to the application when it is accessed as a reference. Is it something in the reference call? Can you show me code and/or tell me how to acoomplish my goal?

Dave Kreskowiak28-May-13 4:56

28-May-13 4:56

First things first. Vocabulary.

A .DLL does not take parameters nor is it an application. A .DLL is a library of classes and methods that an application can use. Screwing up the terminology confuses people.

You always use a .DLL either by adding a reference to it in another application project, or depending on the .DLL type, can be accessed with P/Invoke (no reference required).

If referenced, you usually stick a using statement at the top to import the namespace of the classes you want to use in the .DLL. What you do after that depends on how you've written the code contained in the .DLL. Usually, you create an instance of a class with the code you want to use, then call the methods you need in that class.

A guide to posting questions on CodeProject[^]

Dave Kreskowiak

sc steinhayse28-May-13 9:14

28-May-13 9:14

Each program basically calls the dll with the paramters that is needed for the current run of the dll. The parameters change depending upon what the dll is expected in call.

Here is an example of a call that is made:

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();

Thus do you have any suggestions on how to change the code listed above so that I can attach the dll to each program as 'project reference'?

modified 28-May-13 15:27pm.

Dave Kreskowiak28-May-13 9:18

28-May-13 9:18

This is such a CF...

The path returned by "dll_location" is not a "DLL" but an .EXE. You're passing a few parameters to it in the StartInfo.Arguments. You can't do that with a .DLL, so you're really not using the correct terminology. This means we're having a really hard time figuring out what talking about and what's going on.

A guide to posting questions on CodeProject[^]

Dave Kreskowiak

sc steinhayse28-May-13 9:44