Sebastiaan
Thu Nov 25 06:24:38 CST 2004
Thanks Nick for the elaborate advice. I think will be able to work it out
now.
Kind regards,
Sebastiaan.
"Nick Malik" <nickmalik@hotmail.nospam.com> wrote in message
news:EI1pd.141503$HA.93334@attbi_s01...
> 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
>
>
>
>
>
> "Sebastiaan Olijerhoek" <no_mail@microsoft.com> wrote in message
> news:1101292503.265650@ernani.logica.co.uk...
> > 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.
> >
> > "Nick Malik" <nickmalik@hotmail.nospam.com> wrote in message
> > news:QcIod.382175$wV.298290@attbi_s54...
> > > 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
> > >
> > >
> > > "Sebastiaan Olijerhoek" <no_mail@microsoft.com> wrote in message
> > > news:1101219522.38488@ernani.logica.co.uk...
> > > > 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.
> > > >
> > > >
> > >
> > >
> >
> >
>
>