Assembly depolyment

  • Thread starter Thread starter Abdul
  • Start date Start date
A

Abdul

I am working on a .net project and need some help. The project
contains different components. Each component is in its privated
assembly. For e.g Component1 is a C# library project in VS.net and
compiles to a dll. Similarly Component2. All components implement an
interface IService which has a Start() method. Now each component is
configured through a config file. The components are created by a
ServiceFactory. Each component has to be run as a window's service. So
I want to write a single Windows Service which then creates the right
component by using the ServiceFactory and the config file. The windows
service is just a wrapper around these components. It would call the
components Start() method at regular interval. My question: How do I
deploy this desgin so I dont have to write individual services for
each component instead of a generic service that instantiates the
right component accordingly and each component can read a different
config file. Can I use the same dll(may be in different folders) for
each component to read different config files?
Or do I have to write different service wrappers for a component and
use the dll as a reference?

I hope I was able to explain my problem. Thanks in advance.
 
Hi Abdul,

The ServiceFactory can load the assemblies containing the components
dynamically at run time according to its configuration file. The
System.Reflection.Assembly class should have a LoadFrom method loading an
assembly from a disk file into current application domain. Then, provided
the type names of the components are also known from the configuration file,
you can just call Assembly.CreateInstance and then cast the returned
instance to the IService interface.

You will however most likely have to resort to a single configuration file
for the components, just providing various sections for each component. In
this case, there should be no differences in how the components are
distributed among physical DLLs.
 
Hi Dmitriy,

Thanks for your reply. So I have to write a different service for each
component? I wanted to avoid this because it would be redundant code
(basically all service are doing the same thing except instantiating
the correct component). Also some components do not require the config
file thats why I wanted to leave the configuration of the components
inside their constructors without the ServiceFactory knowing about
them. ServiceFactory would just call GetInstance() of each component
to get the instance. I hope I am making sense. I Wonder if I can
attach an image to this post, that way I could send some sequence
diagrams to better explain things. Appreciate your feedback.

Dmitriy Lapshin said:
Hi Abdul,

The ServiceFactory can load the assemblies containing the components
dynamically at run time according to its configuration file. The
System.Reflection.Assembly class should have a LoadFrom method loading an
assembly from a disk file into current application domain. Then, provided
the type names of the components are also known from the configuration file,
you can just call Assembly.CreateInstance and then cast the returned
instance to the IService interface.

You will however most likely have to resort to a single configuration file
for the components, just providing various sections for each component. In
this case, there should be no differences in how the components are
distributed among physical DLLs.

--
Dmitriy Lapshin [C# / .NET MVP]
X-Unity Test Studio
http://x-unity.miik.com.ua/teststudio.aspx
Bring the power of unit testing to VS .NET IDE

Abdul said:
I am working on a .net project and need some help. The project
contains different components. Each component is in its privated
assembly. For e.g Component1 is a C# library project in VS.net and
compiles to a dll. Similarly Component2. All components implement an
interface IService which has a Start() method. Now each component is
configured through a config file. The components are created by a
ServiceFactory. Each component has to be run as a window's service. So
I want to write a single Windows Service which then creates the right
component by using the ServiceFactory and the config file. The windows
service is just a wrapper around these components. It would call the
components Start() method at regular interval. My question: How do I
deploy this desgin so I dont have to write individual services for
each component instead of a generic service that instantiates the
right component accordingly and each component can read a different
config file. Can I use the same dll(may be in different folders) for
each component to read different config files?
Or do I have to write different service wrappers for a component and
use the dll as a reference?

I hope I was able to explain my problem. Thanks in advance.
Click to expand...
Click to expand...
 
Nope, you don't have to write many services - a single one is enough. The
service will host all componets and instantiate them on demand. You can
design a component factory that will ensure only one instance of each
component exists.

--
Dmitriy Lapshin [C# / .NET MVP]
X-Unity Test Studio
http://x-unity.miik.com.ua/teststudio.aspx
Bring the power of unit testing to VS .NET IDE

Abdul said:
Hi Dmitriy,

Thanks for your reply. So I have to write a different service for each
component? I wanted to avoid this because it would be redundant code
(basically all service are doing the same thing except instantiating
the correct component). Also some components do not require the config
file thats why I wanted to leave the configuration of the components
inside their constructors without the ServiceFactory knowing about
them. ServiceFactory would just call GetInstance() of each component
to get the instance. I hope I am making sense. I Wonder if I can
attach an image to this post, that way I could send some sequence
diagrams to better explain things. Appreciate your feedback.

"Dmitriy Lapshin [C# / .NET MVP]" <[email protected]> wrote
in message news: said:
Hi Abdul,

The ServiceFactory can load the assemblies containing the components
dynamically at run time according to its configuration file. The
System.Reflection.Assembly class should have a LoadFrom method loading an
assembly from a disk file into current application domain. Then, provided
the type names of the components are also known from the configuration file,
you can just call Assembly.CreateInstance and then cast the returned
instance to the IService interface.

You will however most likely have to resort to a single configuration file
for the components, just providing various sections for each component. In
this case, there should be no differences in how the components are
distributed among physical DLLs.

--
Dmitriy Lapshin [C# / .NET MVP]
X-Unity Test Studio
http://x-unity.miik.com.ua/teststudio.aspx
Bring the power of unit testing to VS .NET IDE

Abdul said:
I am working on a .net project and need some help. The project
contains different components. Each component is in its privated
assembly. For e.g Component1 is a C# library project in VS.net and
compiles to a dll. Similarly Component2. All components implement an
interface IService which has a Start() method. Now each component is
configured through a config file. The components are created by a
ServiceFactory. Each component has to be run as a window's service. So
I want to write a single Windows Service which then creates the right
component by using the ServiceFactory and the config file. The windows
service is just a wrapper around these components. It would call the
components Start() method at regular interval. My question: How do I
deploy this desgin so I dont have to write individual services for
each component instead of a generic service that instantiates the
right component accordingly and each component can read a different
config file. Can I use the same dll(may be in different folders) for
each component to read different config files?
Or do I have to write different service wrappers for a component and
use the dll as a reference?

I hope I was able to explain my problem. Thanks in advance.
Click to expand...
Click to expand...
Click to expand...
 
Back
Top