Starting up application from dll.

  • Thread starter Thread starter Sebastiaan Olijerhoek
  • Start date Start date
S

Sebastiaan Olijerhoek

Excel can be started up throw automation like:
Excel.Application myExcel = new Excel.Application()

How can I create this functionality for my own application?

Kind regards,
Sebastiaan.
 
Build your app as ActiveX exe if you are in pre-.NET platform (Excel,
Word... are ActiveX exe server). Since you are asking on .NET NG, you want
to look at .NET Remoting (a bit more complicated than ActiveX exe, in my
point of view. Note, Remoting does not necessarily mean apps on different
computers far apart).
 
Your own application is a windows forms app?

If so, you will want your windows forms app to use its own object layer. In
other words, if your U/I access a set of libraries, that you created in
..net, then another developer can also access those same libraries. In
Visual Studio, that means your solution file will have multiple projects.
(user interface and object layer) The user interface refers to your object
layer and uses it to do all of the important tasks that it wants to do.

The other programmer can simply reference the same object layer as your app
does (direct references) or you can add your object layer libraries into the
Global Assembly Cache (GAC) when you install your app on their machine.
Then it is much easier for the other developer to make the reference (they
still have to reference your library). However, this is a little harder for
you to do, because you have to start signing your libraries and dealing with
Code Access Security.

I hope this sheds some light on the topic.

--- Nick
 
Thanks for your information.
Bringing it a step further. My application reads settings from an app.config
file. Can I reference these settings when starting up the application
through the dll? Or is a manual copy of the settings to the app.config file
from the calling application the only way?

Kind regards,
Sebastiaan.
 
The config file gets its name from the .EXE, not the DLLs. Therefore, if
your U/I is the EXE (which it usually is), then your dlls will be getting
their settings from the config file for the EXE.

This is intentional. It is often the case that the DLL provides services
that can be configured, and that you would want to configure those services
differently for each application that uses the DLL.

On the other hand, if you want to provide a set of "common services" using
your object layer, then you can create an XML file that the DLLs will use.
So, how does the dll find it's XML file?

I've answered this question many different ways in different apps, trying
things out to see what works. I've got three answers:

1) put the name of the XML file into the registry during install. The DLL
looks to the registry to get the config file name. This is useful if you
are writing a DLL that needs to run from Biztalk or Sharepoint, since you
cannot control either their executable or the directory in which they are
installed.

2) Give the XML file a fixed name, hardcoded into dll itself. Have the DLL
look into the application directory (where the EXE lives) to find the XML
file.
Variation: in the app.config for the EXE, provide a seperate section
for the DLL to use. That section will contain the name of the XML Config
file. If no name is given, use the hardcoded name. If neither is found,
use basic default settings or raise an error in the constructor of your
classes.

3) during install of your app, create a specific directory where nothing but
the XML config file will live. When it comes time to go looking for the
file, take the first XML file that you find that lives in that directory.
This is convenient when transferring your app from dev to test to
production, because you can have three files: dev.cml, test.cml, and
prod.cml (I renamed xml to cml on purpose). When you install the app, all
three are placed in the directory. The next step in the install is to ask
the person doing the install "what environment is this" and, using their
response, rename the proper file to the "xml" extension.

In all three cases, loading an XML is not as difficult as it first appears.
Take a look at the XSD.EXE tool that is delivered with the .NET SDK (a free
download from Microsoft). Using the XSD tool, you can point at an XML and
the tool will generate a class that the XML will deserialize into. Using
this class, and the XML deserialization methods built into the framework,
you can very easily load the entire XML file into an object that contains
other objects. Now, you can use that object "tree" to inspect your settings
very easily. In fact, if you change the values in the settings, it is very
easy to save those changes back to the XML config file by simply using the
serialization functions (something that is a bit more difficult with the
config files).

I hope this provides useful information.

--- Nick Malik
Application Architect
http://weblogs.asp.net/nickmalik
 
Thanks Nick for the elaborate advice. I think will be able to work it out
now.
Kind regards,
Sebastiaan.
 
Back
Top