locked
EXE passing variables to Classes within DLL RRS feed

  • Question

  • Morning All,

     

    I have a rather simple problem which I am afraid might have a complex answer. I have multiple EXE's as part of a suite that is accessible through a login screen. After the user is logged in, a class "RunString" is instantiated (lets call it LoginRunString) with variables unique to that user, lets say for example, m_Username, and m_SqlConnectionString.

     

    Then the user launches of the EXE's. LoginRunString is encrypted and passed into the EXE constructor. The EXE links to it a DLL that houses many (around 20) classes. For our purposes lets say there are two classes, myClass and ConnectDB.

     

    myClass uses an instance of ConnectDB, called sqlConn. ConnectDB sets up an SqlConnection object and allows data to be saved to and retrieved from an SQL Server database.

     

    My query is:

     

    How do I get the m_SqlConnectionString and m_Username variables that are set in LoginRunString to be used as the variables that sqlConn uses to do the database connectivity?

     

    I gather a possible solution would be to pass LoginRunString to myClass (say in its constructor), which is then used to instantiate ConnectDB's sqlConn. However, that becomes a very daunting task as there are multiple EXE's and multiple classes that use ConnectDB.

     

    Is there another (easier, cleaner) way?

     

    Thanks heaps for your consideration.

     

    Shai

     

    Wednesday, March 5, 2008 10:59 PM

Answers

  • I think the previous posts are still relevant. You'd be *much* better off with a single shell-like exe, look at MVC, MVP, CAB examples.
    Thursday, March 27, 2008 6:35 AM

All replies

  • Do you need to have separate exes? It appears that there is a hard dependency that login and connection strings are set dynamically at run time through a specific program. Can you execute those programs without going through the login screen?

    Thursday, March 6, 2008 12:36 AM
  • Yes the login is the only place the connection string is set up. One cannot open the other EXEs without going through the login, these allow for layered access control.

    Thursday, March 6, 2008 2:08 AM
  •  shai_au wrote:

    Yes the login is the only place the connection string is set up. One cannot open the other EXEs without going through the login, these allow for layered access control.

     

    This tells me that the functionality shouldn't be grouped in separate executables. Consider combining them into one program (with the classes in their appropriate dlls, of course).

    Thursday, March 6, 2008 4:07 PM
  • I'd take a look at creating your own Domain and at cross process communication, lots of ways to skin that cat. But I do agree that it all sounds a bit odd.


    Thursday, March 6, 2008 9:24 PM
  • The whole things smells, a little like a work-in-progress work-around?  That tells me that if at all possible, you should reconsider how this whole thing is designed, to work properly with your login functionality, and also if there is some out of the box way to get around this, such as using windows integrated logins, and storing only the connection details for the database in the server code?  That would then mean that you could allow your user to connect given that they are added to the database server, and allowed to access the database.  The username could then be taken from IPrinciple and the WindowsIdentity class. 

     

    That aside, here's some other information:

     

    Okay, so the connection and username are passed around as some sort of authorization token then?

     

    First, I'd like to comment on the design, which you may not have control over, but here it is anyway.  The connection string is a database construct, and is effectively meaning that your login is tightly coupled to your data implementation through the fact that login could imply a SqlConnectionString.  If it's some different technology at the backend, then that's a bad design.

     

    I would imagine that you'd want to have a proper login design where you pass around a token that can then be used to calculate, construct or read the connection string in the sql database provider class.

     

    That aside, let's assume that you have a class represented by ILoginToken, you could surely inject that into your executables.  the comes with having to load seperate executables.  Which would be the next question, why have seperate executables?

     

    If there was a need for seperate assemblies, to lead to a seperation of concerns, then why not use dlls instead?  If you need seperate AppDomains, you can still create those within Dlls, but passing in-process information is much simpler.

     

    I know this doesn't give you a concrete solution, but should give you some ideas that you can look into, to decide what to do?

     

    Good luck,

     

    Martin Platt.

     

    Thursday, March 6, 2008 10:54 PM
  • Hi Guys,

     

    Sorry I havnt got back in touch, my wife has been rather sick.

     

    Unfortunately, you are right, the way in which this software suite was set up was/is out of my hands. Though I am thinking maybe I have not explained myself too well either.

     

    Maybe if I am more specific...

     

    Lets say the software runs a doctors office. The login is used by all staff, however only certain modules are used by certain staff. I login as administrator and have access to all modules, Accounts, Patient Management, and Reports for example. Accounts staff login and use the Accounts module only, nurses log in and use the patient management module etc etc.

     

    There is far too much functionality to put all this into one executable with multiple DLLs. Again, though, this is not the problem.

     

    What I need to do is construct a input parameter (lets say a myString) in the login module, and pass it to an EXE, lets say the Accounts module. The accounts module then needs to draw on DLLs that need access to this myString.

     

     

    Am I making any more sense?

     

    Shai

    Wednesday, March 26, 2008 11:13 PM
  • I think the previous posts are still relevant. You'd be *much* better off with a single shell-like exe, look at MVC, MVP, CAB examples.
    Thursday, March 27, 2008 6:35 AM