OMG Becky...

OMG Becky...

Old forum URL: forums.lhotka.net/forums/t/7070.aspx


jasona22 posted on Wednesday, June 10, 2009

<subject is a reference to "I like big butts" by Sir Mix-a-lot>

I am verclempt.  What follows is an explaniation of what I have and what I am running into.   The question is "WHY?"

I am a team member for a product.  One of my tasks is to build a Windows Service that reads a table that contains the data required to execute process listed in the table on a time schedule.  Each record is a separate process.

The process record contains:

Start Date Time, Frequency, Process Function To Execute and some other fields that are not necessary for this discussion.

So for each record in the table, I create a process class.

In the process class, as many as 2 timers are created.  First timer (a single shot) executes a delta from "now" to the Start Date Time value.  When that timer executes,  the "process function" is called and it creates a second timer that then handles the "frequency" (once a day, once an hour etc) for on going process function calls -- I know there is a timer that does this sort of thing already, but there are other features that this gives that I am using that the other timer does not.

When the process executes, it uses reflection to create an assembly, an instance of the assembly and then invokes a method on that assembly passing a single string parameter.

For all intents and purposes, that is all this service does.  I do not explicitly use CSLA or anything fancy.  I added no references (other than System.Configuration) for app config handling.

Running against my stub, I execute fine.  I have ran against the stub at 100 milliseconds for up to 5 timed processes and never even hic-uped. 

Changing my app config to point to the DLL that I am to actually reference... a DLL that actually does use CSLA and suddenly the Windows Service starts erroring.

The error is something to the effect of "Object not Found" and the inner exception complains about a missing CSLA 3.0.4.0 reference.  I look at the other guys install directory and the CSLA file is there... longer story short, it turns out that it is complainging about my Windows Service not containing a reference to CSLA.

I add a CSLA reference to my Windows Service and that series of erros goes away.  This breaks all coding logic I have ever been involved with. 

So, the question is: Why does my windows service need to reference CSLA (as in right click References and select Add Reference and browse to the CSLA.dll) even though I never create anything out of it, never follow the frameworks structure or otherwise use it directly? 

Never before can I recall needing to add an external reference to any dll just because one that I was referencing used it.

In testing this, I went back to my Stub application, removed the CSLA reference from my service and ti worked fine.  Added a reference to CSLA in the Stub and the Windows Service stopped working again... added a reference to CSLA back into my Windows Service and it was happy once more.

Very strange behavior and I would love to understand it.

Thank you for your knowledge and willingness to share it.

 

Jason

 

 

RockfordLhotka replied on Wednesday, June 10, 2009

Often the trick is to just make sure that Csla.dll is in the right folder so the .NET type loader can find it.

If your service itself isn't using Csla.dll, then you shouldn't need to reference it. But if some other assembly is using Csla.dll, you must make sure Csla.dll is in the EXE's folder.

Often the easiest way to get a DLL into a folder is to have the host project (the EXE, web project or whatever) reference that DLL. But you can manually copy the DLL into place, or use a post-build operation to do the copy if you want to avoid using a reference.

jasona22 replied on Wednesday, June 10, 2009

Thanks.  It just seems a little more tightly coupled than I would expect.  It would seem that if you are reflecting a dll (based on data in a app.config file), that needing to add a reference or move dll's would make the service know too much about what it is reflecting.

But I do see your point, since the service is technically the app domain for the call, the execution will be with the exe and need the dependencies of the called dll as well.

Hmmm...

 

Thanks again

 

 

RockfordLhotka replied on Wednesday, June 10, 2009

All I'm saying, is that if you want Visual Studio to automatically ensure that your DLLs are in the folder, then you need the references.

If you come up with some other scheme to get the DLLs into the folder before the service is running, then you can do that instead - but VS won't help you unless you use references.

So you can choose to be less tightly coupled, and I think that's fine, you just need to come up with your own infrastructure to make that work.

Copyright (c) Marimer LLC