Accessing dlls at runtime

[John]

Hi

I have a set of classes (application framework) in the form of a dll that I
have set to install in [Common Files]\[My Folder] folder by default on the
target user's pcs. This path can also be changed by the user when running
the setup on their pcs.

The problem is how do I tell me main apps (which get installed separately)
to find out the location of the dll and use its reference on the target pcs?

Thanks

Regards

[Phil Wilson]

To me this appears to be one of those "if it hurts, don't do it" things.
Users typically get to choose only the primary application folder (TARGETDIR
in a VS setup) and supporting infrastructure goes where it needs to be to
have everything work. I assume you've already given the user a choice for
the primary application folder, so does that mean you have another dialog
for the location of this Dll? Or is this a separate setup? I really think
this is one of those times where you should just put it where it should be,
and that's common with supporting infrastructure files. Delete the dialog
that offers the choice!
--
Phil Wilson
[Microsoft MVP-Windows Installer]
"John" <Jo**@nospam.infovis.co.uk> wrote in message
news:eA**************@TK2MSFTNGP09.phx.gbl...

Hi

I have a set of classes (application framework) in the form of a dll that
I have set to install in [Common Files]\[My Folder] folder by default on
the target user's pcs. This path can also be changed by the user when
running the setup on their pcs.

The problem is how do I tell me main apps (which get installed separately)
to find out the location of the dll and use its reference on the target
pcs?

Thanks

Regards

[John]

Hi Phil

The app framework and actual apps are separate setups. The reason I did that
was to keep the apps "clean" and not having to include the framework source
in each project. Also people who do not have access to framework source code
(sometimes preferable) will also be able to develop around the framework, if
this works.

I guess one way is to store the framework dll path in a registry key on
install. What I don't know is how to reference this in my app at design and
runtime.

Thanks

Regards
"Phil Wilson" <pd*******@nospam.cox.net> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl...

To me this appears to be one of those "if it hurts, don't do it" things.
Users typically get to choose only the primary application folder
(TARGETDIR in a VS setup) and supporting infrastructure goes where it
needs to be to have everything work. I assume you've already given the
user a choice for the primary application folder, so does that mean you
have another dialog for the location of this Dll? Or is this a separate
setup? I really think this is one of those times where you should just put
it where it should be, and that's common with supporting infrastructure
files. Delete the dialog that offers the choice!
--
Phil Wilson
[Microsoft MVP-Windows Installer]
"John" <Jo**@nospam.infovis.co.uk> wrote in message
news:eA**************@TK2MSFTNGP09.phx.gbl...

Hi

I have a set of classes (application framework) in the form of a dll that
I have set to install in [Common Files]\[My Folder] folder by default on
the target user's pcs. This path can also be changed by the user when
running the setup on their pcs.

The problem is how do I tell me main apps (which get installed
separately) to find out the location of the dll and use its reference on
the target pcs?

Thanks

Regards

[stand__sure]

why not install it to the GAC? the Runtime looks there first when it
attempts to bind.

[John]

Hmmm...this sounds interesting. Where can I get more info on how to do
this??

Thanks

Regards

"stand__sure" <st*********@hotmail.com> wrote in message
news:11**********************@g44g2000cwa.googlegr oups.com...

why not install it to the GAC? the Runtime looks there first when it
attempts to bind.

[John]

OK, installed it in gac. Now how do I access it in my other apps?

Thanks

Regards

"stand__sure" <st*********@hotmail.com> wrote in message
news:11**********************@g44g2000cwa.googlegr oups.com...

why not install it to the GAC? the Runtime looks there first when it
attempts to bind.

[Phil Wilson]

Well if "access" means "link to when the programs run", it will just work
because the GAC is the the first place default location where the runtime
will look for a dependent assembly. Of course the assembly must match the
client requirements for assemblyversion, strong name etc.

There are some gotchas with updating files installed by MSI into the GAC, so
I'd ensure you figure out how to replace it with a new version before
committing to using the GAC. The fixed common location will be easier to
update than the GAC.
--
Phil Wilson
[Microsoft MVP-Windows Installer]
Definitive Guide to Windows Installer
http://apress.com/book/bookDisplay.html?bID=280

"John" <Jo**@nospam.infovis.co.uk> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl...

OK, installed it in gac. Now how do I access it in my other apps?

Thanks

Regards

"stand__sure" <st*********@hotmail.com> wrote in message
news:11**********************@g44g2000cwa.googlegr oups.com...

why not install it to the GAC? the Runtime looks there first when it
attempts to bind.

[John]

So if the dll is installed in the [Prorgam files]\[Common Files]\[My Class]
folder then how can I access the dll regardless of which drive the [Prorgam
files]\[Common Files]\[My Class] folder is on?

Thanks

Regards
"Phil Wilson" <pd*******@nospam.cox.net> wrote in message
news:O3**************@tk2msftngp13.phx.gbl...

Well if "access" means "link to when the programs run", it will just work
because the GAC is the the first place default location where the runtime
will look for a dependent assembly. Of course the assembly must match the
client requirements for assemblyversion, strong name etc.

There are some gotchas with updating files installed by MSI into the GAC,
so I'd ensure you figure out how to replace it with a new version before
committing to using the GAC. The fixed common location will be easier to
update than the GAC.
--
Phil Wilson
[Microsoft MVP-Windows Installer]
Definitive Guide to Windows Installer
http://apress.com/book/bookDisplay.html?bID=280

"John" <Jo**@nospam.infovis.co.uk> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl...

OK, installed it in gac. Now how do I access it in my other apps?

Thanks

Regards

"stand__sure" <st*********@hotmail.com> wrote in message
news:11**********************@g44g2000cwa.googlegr oups.com...

why not install it to the GAC? the Runtime looks there first when it
attempts to bind.

[Phil Wilson]

Well your main problem is that the best place for dependent assemblies to be
installed is right next to the app that uses it. You've got an unusual
deployment model where an assembly which is required for one or more apps is
likely to be installed in some completely random folder, and that's not the
usual deployment model that people use, and that's why someone suggested the
GAC. If client programs want to cleanly instantiate objects from your
assembly with the deployment model you're using, you don't have any
reasonable choice except the GAC. Dependent assemblies pretty much need to
be in the same directory as the client app, or in a subfolder via
redirection, or in the GAC.

If you want some other fixed location, you can tell your clients that they
need to do some kind of assembly load from somewhere in
Environment.GetFolderPath (Environment.SpecialFolder.CommonApplicationData)
and instantiate objects that way, but that isn't the usual way.
--
Phil Wilson [MVP Windows Installer]
----
"John" <Jo**@nospam.infovis.co.uk> wrote in message
news:%2****************@tk2msftngp13.phx.gbl...

So if the dll is installed in the [Prorgam files]\[Common Files]\[My
Class] folder then how can I access the dll regardless of which drive the
[Prorgam files]\[Common Files]\[My Class] folder is on?

Thanks

Regards
"Phil Wilson" <pd*******@nospam.cox.net> wrote in message
news:O3**************@tk2msftngp13.phx.gbl...

Well if "access" means "link to when the programs run", it will just work
because the GAC is the the first place default location where the runtime
will look for a dependent assembly. Of course the assembly must match the
client requirements for assemblyversion, strong name etc.

There are some gotchas with updating files installed by MSI into the GAC,
so I'd ensure you figure out how to replace it with a new version before
committing to using the GAC. The fixed common location will be easier to
update than the GAC.
--
Phil Wilson
[Microsoft MVP-Windows Installer]
Definitive Guide to Windows Installer
http://apress.com/book/bookDisplay.html?bID=280

"John" <Jo**@nospam.infovis.co.uk> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl...

OK, installed it in gac. Now how do I access it in my other apps?

Thanks

Regards

"stand__sure" <st*********@hotmail.com> wrote in message
news:11**********************@g44g2000cwa.googlegr oups.com...
why not install it to the GAC? the Runtime looks there first when it
attempts to bind.