How to reference a dll in device's registry?

[Guest]

In my PPC app, I want to reference a dll that's registered in device's
registry. Is it possible? How to do it?
Thank you.

 

[Paul G. Tobey [eMVP]]

Registered how? It's a COM DLL or what? You haven't told us what version
of Windows Mobile the PPC has, what sort of DLL is it or how you want to use
it. Most of us here are *not* able to read minds over long distances...

Paul T.

 

[Guest]

I didn't specify those things because I didn't think it would matter...I just
wanted to know if it's possible at all. Let me give you more details:
I have two projects: the first one is Windows Applications (that will use
the dll) and the second one is Class Library (this is the dll that I want to
create a registry entry on the device for and reference it in my
application). I want to be able to run the application on Pocket PC 2002,
2003, Windows Mobile 2003, and Windows Mobile 5.0.

 

[Paul G. Tobey [eMVP]]

Well, without more details, all "registered in the device's registry" just
means that there's a simple string entry that calls out the DLL's name!
That's like saying, "Can you use a DLL on a device?" It has no meaning
without details.

There's no reason in either of the situations that you mention to put
*anything* concerning the DLL into the registry. Just use the DLL from the
application. You don't need the registry at all.

Paul T.

 

[Guest]

I think there's a way to create a registry entry on the device when a dll
gets installed...So I would have to install the dll separately on the device,
which IS what I want to do - for the following reason: I'm using the dll in
multiple applications. When I make changes to the dll, I have to go into
every single project, do the build, reinstall the project on the device, but
all I would have to do is reinstall the single dll. I think it makes sense,
doesn't it??

 

[Paul G. Tobey [eMVP]]

Sure, separating the code commonly used by several programs into a shared
DLL makes sense, but that, again, has *nothing* to do with the registry.
The use of a DLL *at all* (regardless of the registry contents), separates
the EXE from the DLL and, assuming you install the DLL into a location where
the loader can find it, \Windows, for example, your application has no
issues with the registry at all. The application won't work if the DLL
isn't installed, of course, but that's a separate issue.

Paul T.

 

[Guest]

If I install the dll under \Windows, for example, all my programs that use
the dll would have to know the location. Again, if for some reason I decide
to change the location, I have to change all those programs, instead of
changing the single registry entry which stores the location. It's not that I
would change the location very often, but that's the reasoning behind using
the registry. I guess I can
install the dll into \Windows or whatever folder on the device, but how do I
tell the application where to find it?

 

[Paul G. Tobey [eMVP]]

No, that's not true. The *loader* has to know the location. If your EXE is
linked to the DLL, it can't change where it's loaded from, even if it knew,
anyway! It counts on the loader to find and load the DLL; if the loader
can't find it, the EXE won't run. The loader uses a search path stored in
the registry to search, but I can't think of any good reason not to install
in \Windows.

If you don't know how DLLs work, you need to read up on that before deciding
on your installation scheme!

Paul T.

 

[Guest]

Yes, I perfectly understand the fact that the exe cannot change the location
of the dll. When I said, "If...I decide to change the location, I have to
change all those programs" I simply meant that I have to change the Reference
Path in the Project Properties window. Or I don't have to? You see, I don't
know how to tell the exe where to find the dll if the dll resides in
\Windows. Can you, please, tell me what I have to enter in Project Properites
to make that linkage work?

 

[Paul G. Tobey [eMVP]]

I don't recognize any Reference Path option that would show up in Project
Properties. How did you get there and, while we're at it, what development
environment are we talking about and what version?

The DLL is just a file laying around on the target device. Your EXE has to
know *absolutely nothing, not one damn thing* about its location, provided,
as I said, that the loader can find it. The loader will automatically look
in \Windows, so you have to do *precisely nothing*, if you put the DLL
there. Linkage is determined by linking the EXE with the import library for
the DLL and I have absolutely no way of knowing where on your development
system you might have put that. You *are* linking with the DLL import
library, right? Not using LoadLibrary() at run-time to load the DLL?

Paul T.

 

[Paul G. Tobey [eMVP]]

Ah, perhaps I'm starting to catch up. You're talking about building a
managed code DLL that you want to reference from your program, yes? The
easiest way to do this is, as I mentioned in the previous message, add the
project to build the DLL to the workspace for building the EXE, and add a
reference for the EXE to the DLL project. Right-click on the EXE project,
choose Add Reference... In the dialog which is presented, choose the
Projects tab, select the DLL project from the list and hit Select. This
will, if I remember right from VS.NET 2003, deploy to the same folder as the
EXE and the managed loader will work with that, or you can change the
deployment options for the DLL project to put it in the \Windows folder.

Paul T.

"Paul G. Tobey [eMVP]" <p space tobey no spam AT no instrument no spam DOT
com> wrote in message news:OqCfaQ%[email protected]...

 

[Guest]

Yes, you understand me correctly, I'm talking about building a managed code
DLL that I want to reference from my program. However, what you're describing
I'm doing right now: I'm referencing the DLL in my EXE, except my DLL resides
under the same folder as my EXE, not the \Windows folder. I can change the
deployment path for the DLL, but again, every time I make changes to the DLL,
I have to rebuild every project that has a reference to the DLL and reinstall
the project on the device, right? I'm looking for something like this: every
time I change the DLL, I just reinstall this single DLL file on the device
and my programs that use the DLL will pick up the change. Do you know what I
mean? I don't know how to explain it better...

Ah, perhaps I'm starting to catch up. You're talking about building a
managed code DLL that you want to reference from your program, yes? The
easiest way to do this is, as I mentioned in the previous message, add the
project to build the DLL to the workspace for building the EXE, and add a
reference for the EXE to the DLL project. Right-click on the EXE project,
choose Add Reference... In the dialog which is presented, choose the
Projects tab, select the DLL project from the list and hit Select. This
will, if I remember right from VS.NET 2003, deploy to the same folder as the
EXE and the managed loader will work with that, or you can change the
deployment options for the DLL project to put it in the \Windows folder.

Paul T.

"Paul G. Tobey [eMVP]" <p space tobey no spam AT no instrument no spam DOT
com> wrote in message news:OqCfaQ%[email protected]...

I don't recognize any Reference Path option that would show up in Project
Properties. How did you get there and, while we're at it, what development
environment are we talking about and what version?

The DLL is just a file laying around on the target device. Your EXE has
to know *absolutely nothing, not one damn thing* about its location,
provided, as I said, that the loader can find it. The loader will
automatically look in \Windows, so you have to do *precisely nothing*, if
you put the DLL there. Linkage is determined by linking the EXE with the
import library for the DLL and I have absolutely no way of knowing where
on your development system you might have put that. You *are* linking
with the DLL import library, right? Not using LoadLibrary() at run-time
to load the DLL?

Paul T.

 

[Paul G. Tobey [eMVP]]

No, of course not. Arrange to deploy the DLL, when you build it, to
\Windows. Any program that uses the DLL will use the one in \Windows.
Obviously, if you change the API exported by the DLL you'll have to
recompile any EXE that uses it! What else would make sense?

Paul T.

Yes, you understand me correctly, I'm talking about building a managed
code
DLL that I want to reference from my program. However, what you're
describing
I'm doing right now: I'm referencing the DLL in my EXE, except my DLL
resides
under the same folder as my EXE, not the \Windows folder. I can change the
deployment path for the DLL, but again, every time I make changes to the
DLL,
I have to rebuild every project that has a reference to the DLL and
reinstall
the project on the device, right? I'm looking for something like this:
every
time I change the DLL, I just reinstall this single DLL file on the device
and my programs that use the DLL will pick up the change. Do you know what
I
mean? I don't know how to explain it better...

Ah, perhaps I'm starting to catch up. You're talking about building a
managed code DLL that you want to reference from your program, yes? The
easiest way to do this is, as I mentioned in the previous message, add
the
project to build the DLL to the workspace for building the EXE, and add a
reference for the EXE to the DLL project. Right-click on the EXE
project,
choose Add Reference... In the dialog which is presented, choose the
Projects tab, select the DLL project from the list and hit Select. This
will, if I remember right from VS.NET 2003, deploy to the same folder as
the
EXE and the managed loader will work with that, or you can change the
deployment options for the DLL project to put it in the \Windows folder.

Paul T.

"Paul G. Tobey [eMVP]" <p space tobey no spam AT no instrument no spam
DOT
com> wrote in message news:OqCfaQ%[email protected]...

I don't recognize any Reference Path option that would show up in
Project
Properties. How did you get there and, while we're at it, what
development
environment are we talking about and what version?

The DLL is just a file laying around on the target device. Your EXE
has
to know *absolutely nothing, not one damn thing* about its location,
provided, as I said, that the loader can find it. The loader will
automatically look in \Windows, so you have to do *precisely nothing*,
if
you put the DLL there. Linkage is determined by linking the EXE with
the
import library for the DLL and I have absolutely no way of knowing
where
on your development system you might have put that. You *are* linking
with the DLL import library, right? Not using LoadLibrary() at
run-time
to load the DLL?

Paul T.

Yes, I perfectly understand the fact that the exe cannot change the
location
of the dll. When I said, "If...I decide to change the location, I have
to
change all those programs" I simply meant that I have to change the
Reference
Path in the Project Properties window. Or I don't have to? You see, I
don't
know how to tell the exe where to find the dll if the dll resides in
\Windows. Can you, please, tell me what I have to enter in Project
Properites
to make that linkage work?

:

No, that's not true. The *loader* has to know the location. If your
EXE is
linked to the DLL, it can't change where it's loaded from, even if it
knew,
anyway! It counts on the loader to find and load the DLL; if the
loader
can't find it, the EXE won't run. The loader uses a search path
stored
in
the registry to search, but I can't think of any good reason not to
install
in \Windows.

If you don't know how DLLs work, you need to read up on that before
deciding
on your installation scheme!

Paul T.

If I install the dll under \Windows, for example, all my programs
that
use
the dll would have to know the location. Again, if for some reason
I
decide
to change the location, I have to change all those programs,
instead
of
changing the single registry entry which stores the location. It's
not
that I
would change the location very often, but that's the reasoning
behind
using
the registry. I guess I can
install the dll into \Windows or whatever folder on the device, but
how do
I
tell the application where to find it?

:

Sure, separating the code commonly used by several programs into a
shared
DLL makes sense, but that, again, has *nothing* to do with the
registry.
The use of a DLL *at all* (regardless of the registry contents),
separates
the EXE from the DLL and, assuming you install the DLL into a
location
where
the loader can find it, \Windows, for example, your application
has
no
issues with the registry at all. The application won't work if
the
DLL
isn't installed, of course, but that's a separate issue.

Paul T.

I think there's a way to create a registry entry on the device
when
a
dll
gets installed...So I would have to install the dll separately
on
the
device,
which IS what I want to do - for the following reason: I'm using
the
dll
in
multiple applications. When I make changes to the dll, I have to
go
into
every single project, do the build, reinstall the project on the
device,
but
all I would have to do is reinstall the single dll. I think it
makes
sense,
doesn't it??



:

Well, without more details, all "registered in the device's
registry"
just
means that there's a simple string entry that calls out the
DLL's
name!
That's like saying, "Can you use a DLL on a device?" It has no
meaning
without details.

There's no reason in either of the situations that you mention
to
put
*anything* concerning the DLL into the registry. Just use the
DLL
from
the
application. You don't need the registry at all.

Paul T.

I didn't specify those things because I didn't think it would
matter...I
just
wanted to know if it's possible at all. Let me give you more
details:
I have two projects: the first one is Windows Applications
(that
will
use
the dll) and the second one is Class Library (this is the dll
that I
want
to
create a registry entry on the device for and reference it in
my
application). I want to be able to run the application on
Pocket
PC
2002,
2003, Windows Mobile 2003, and Windows Mobile 5.0.

:

Registered how? It's a COM DLL or what? You haven't told
us
what
version
of Windows Mobile the PPC has, what sort of DLL is it or how
you
want
to
use
it. Most of us here are *not* able to read minds over long
distances...

Paul T.

In my PPC app, I want to reference a dll that's registered
in
device's
registry. Is it possible? How to do it?
Thank you.

 

[Guest]

The way to achieve what you're after is to sign the assembly and put it in
the GAC.

-Chris

Yes, you understand me correctly, I'm talking about building a managed
code
DLL that I want to reference from my program. However, what you're
describing
I'm doing right now: I'm referencing the DLL in my EXE, except my DLL
resides
under the same folder as my EXE, not the \Windows folder. I can change the
deployment path for the DLL, but again, every time I make changes to the
DLL,
I have to rebuild every project that has a reference to the DLL and
reinstall
the project on the device, right? I'm looking for something like this:
every
time I change the DLL, I just reinstall this single DLL file on the device
and my programs that use the DLL will pick up the change. Do you know what
I
mean? I don't know how to explain it better...

Ah, perhaps I'm starting to catch up. You're talking about building a
managed code DLL that you want to reference from your program, yes? The
easiest way to do this is, as I mentioned in the previous message, add
the
project to build the DLL to the workspace for building the EXE, and add a
reference for the EXE to the DLL project. Right-click on the EXE
project,
choose Add Reference... In the dialog which is presented, choose the
Projects tab, select the DLL project from the list and hit Select. This
will, if I remember right from VS.NET 2003, deploy to the same folder as
the
EXE and the managed loader will work with that, or you can change the
deployment options for the DLL project to put it in the \Windows folder.

Paul T.

"Paul G. Tobey [eMVP]" <p space tobey no spam AT no instrument no spam
DOT
com> wrote in message news:OqCfaQ%[email protected]...

I don't recognize any Reference Path option that would show up in
Project
Properties. How did you get there and, while we're at it, what
development
environment are we talking about and what version?

The DLL is just a file laying around on the target device. Your EXE
has
to know *absolutely nothing, not one damn thing* about its location,
provided, as I said, that the loader can find it. The loader will
automatically look in \Windows, so you have to do *precisely nothing*,
if
you put the DLL there. Linkage is determined by linking the EXE with
the
import library for the DLL and I have absolutely no way of knowing
where
on your development system you might have put that. You *are* linking
with the DLL import library, right? Not using LoadLibrary() at
run-time
to load the DLL?

Paul T.

Yes, I perfectly understand the fact that the exe cannot change the
location
of the dll. When I said, "If...I decide to change the location, I have
to
change all those programs" I simply meant that I have to change the
Reference
Path in the Project Properties window. Or I don't have to? You see, I
don't
know how to tell the exe where to find the dll if the dll resides in
\Windows. Can you, please, tell me what I have to enter in Project
Properites
to make that linkage work?

:

No, that's not true. The *loader* has to know the location. If your
EXE is
linked to the DLL, it can't change where it's loaded from, even if it
knew,
anyway! It counts on the loader to find and load the DLL; if the
loader
can't find it, the EXE won't run. The loader uses a search path
stored
in
the registry to search, but I can't think of any good reason not to
install
in \Windows.

If you don't know how DLLs work, you need to read up on that before
deciding
on your installation scheme!

Paul T.

If I install the dll under \Windows, for example, all my programs
that
use
the dll would have to know the location. Again, if for some reason
I
decide
to change the location, I have to change all those programs,
instead
of
changing the single registry entry which stores the location. It's
not
that I
would change the location very often, but that's the reasoning
behind
using
the registry. I guess I can
install the dll into \Windows or whatever folder on the device, but
how do
I
tell the application where to find it?

:

Sure, separating the code commonly used by several programs into a
shared
DLL makes sense, but that, again, has *nothing* to do with the
registry.
The use of a DLL *at all* (regardless of the registry contents),
separates
the EXE from the DLL and, assuming you install the DLL into a
location
where
the loader can find it, \Windows, for example, your application
has
no
issues with the registry at all. The application won't work if
the
DLL
isn't installed, of course, but that's a separate issue.

Paul T.

I think there's a way to create a registry entry on the device
when
a
dll
gets installed...So I would have to install the dll separately
on
the
device,
which IS what I want to do - for the following reason: I'm using
the
dll
in
multiple applications. When I make changes to the dll, I have to
go
into
every single project, do the build, reinstall the project on the
device,
but
all I would have to do is reinstall the single dll. I think it
makes
sense,
doesn't it??



:

Well, without more details, all "registered in the device's
registry"
just
means that there's a simple string entry that calls out the
DLL's
name!
That's like saying, "Can you use a DLL on a device?" It has no
meaning
without details.

There's no reason in either of the situations that you mention
to
put
*anything* concerning the DLL into the registry. Just use the
DLL
from
the
application. You don't need the registry at all.

Paul T.

I didn't specify those things because I didn't think it would
matter...I
just
wanted to know if it's possible at all. Let me give you more
details:
I have two projects: the first one is Windows Applications
(that
will
use
the dll) and the second one is Class Library (this is the dll
that I
want
to
create a registry entry on the device for and reference it in
my
application). I want to be able to run the application on
Pocket
PC
2002,
2003, Windows Mobile 2003, and Windows Mobile 5.0.

:

Registered how? It's a COM DLL or what? You haven't told
us
what
version
of Windows Mobile the PPC has, what sort of DLL is it or how
you
want
to
use
it. Most of us here are *not* able to read minds over long
distances...

Paul T.

In my PPC app, I want to reference a dll that's registered
in
device's
registry. Is it possible? How to do it?
Thank you.

 

[Guest]

I got the answer to my question. What I wanted to do didn't look possible to
me, I just wanted to make sure I'm not missing something. Thanks a lot for
your time!

No, of course not. Arrange to deploy the DLL, when you build it, to
\Windows. Any program that uses the DLL will use the one in \Windows.
Obviously, if you change the API exported by the DLL you'll have to
recompile any EXE that uses it! What else would make sense?

Paul T.

Yes, you understand me correctly, I'm talking about building a managed
code
DLL that I want to reference from my program. However, what you're
describing
I'm doing right now: I'm referencing the DLL in my EXE, except my DLL
resides
under the same folder as my EXE, not the \Windows folder. I can change the
deployment path for the DLL, but again, every time I make changes to the
DLL,
I have to rebuild every project that has a reference to the DLL and
reinstall
the project on the device, right? I'm looking for something like this:
every
time I change the DLL, I just reinstall this single DLL file on the device
and my programs that use the DLL will pick up the change. Do you know what
I
mean? I don't know how to explain it better...

Ah, perhaps I'm starting to catch up. You're talking about building a
managed code DLL that you want to reference from your program, yes? The
easiest way to do this is, as I mentioned in the previous message, add
the
project to build the DLL to the workspace for building the EXE, and add a
reference for the EXE to the DLL project. Right-click on the EXE
project,
choose Add Reference... In the dialog which is presented, choose the
Projects tab, select the DLL project from the list and hit Select. This
will, if I remember right from VS.NET 2003, deploy to the same folder as
the
EXE and the managed loader will work with that, or you can change the
deployment options for the DLL project to put it in the \Windows folder.

Paul T.

"Paul G. Tobey [eMVP]" <p space tobey no spam AT no instrument no spam
DOT
com> wrote in message I don't recognize any Reference Path option that would show up in
Project
Properties. How did you get there and, while we're at it, what
development
environment are we talking about and what version?

The DLL is just a file laying around on the target device. Your EXE
has
to know *absolutely nothing, not one damn thing* about its location,
provided, as I said, that the loader can find it. The loader will
automatically look in \Windows, so you have to do *precisely nothing*,
if
you put the DLL there. Linkage is determined by linking the EXE with
the
import library for the DLL and I have absolutely no way of knowing
where
on your development system you might have put that. You *are* linking
with the DLL import library, right? Not using LoadLibrary() at
run-time
to load the DLL?

Paul T.

Yes, I perfectly understand the fact that the exe cannot change the
location
of the dll. When I said, "If...I decide to change the location, I have
to
change all those programs" I simply meant that I have to change the
Reference
Path in the Project Properties window. Or I don't have to? You see, I
don't
know how to tell the exe where to find the dll if the dll resides in
\Windows. Can you, please, tell me what I have to enter in Project
Properites
to make that linkage work?

:

No, that's not true. The *loader* has to know the location. If your
EXE is
linked to the DLL, it can't change where it's loaded from, even if it
knew,
anyway! It counts on the loader to find and load the DLL; if the
loader
can't find it, the EXE won't run. The loader uses a search path
stored
in
the registry to search, but I can't think of any good reason not to
install
in \Windows.

If you don't know how DLLs work, you need to read up on that before
deciding
on your installation scheme!

Paul T.

If I install the dll under \Windows, for example, all my programs
that
use
the dll would have to know the location. Again, if for some reason
I
decide
to change the location, I have to change all those programs,
instead
of
changing the single registry entry which stores the location. It's
not
that I
would change the location very often, but that's the reasoning
behind
using
the registry. I guess I can
install the dll into \Windows or whatever folder on the device, but
how do
I
tell the application where to find it?

:

Sure, separating the code commonly used by several programs into a
shared
DLL makes sense, but that, again, has *nothing* to do with the
registry.
The use of a DLL *at all* (regardless of the registry contents),
separates
the EXE from the DLL and, assuming you install the DLL into a
location
where
the loader can find it, \Windows, for example, your application
has
no
issues with the registry at all. The application won't work if
the
DLL
isn't installed, of course, but that's a separate issue.

Paul T.

I think there's a way to create a registry entry on the device
when
a
dll
gets installed...So I would have to install the dll separately
on
the
device,
which IS what I want to do - for the following reason: I'm using
the
dll
in
multiple applications. When I make changes to the dll, I have to
go
into
every single project, do the build, reinstall the project on the
device,
but
all I would have to do is reinstall the single dll. I think it
makes
sense,
doesn't it??



:

Well, without more details, all "registered in the device's
registry"
just
means that there's a simple string entry that calls out the
DLL's
name!
That's like saying, "Can you use a DLL on a device?" It has no
meaning
without details.

There's no reason in either of the situations that you mention
to
put
*anything* concerning the DLL into the registry. Just use the
DLL
from
the
application. You don't need the registry at all.

Paul T.

I didn't specify those things because I didn't think it would
matter...I
just
wanted to know if it's possible at all. Let me give you more
details:
I have two projects: the first one is Windows Applications
(that
will
use
the dll) and the second one is Class Library (this is the dll
that I
want
to
create a registry entry on the device for and reference it in
my
application). I want to be able to run the application on
Pocket
PC
2002,
2003, Windows Mobile 2003, and Windows Mobile 5.0.

:

Registered how? It's a COM DLL or what? You haven't told
us
what
version
of Windows Mobile the PPC has, what sort of DLL is it or how
you
want
to
use
it. Most of us here are *not* able to read minds over long
distances...

Paul T.

In my PPC app, I want to reference a dll that's registered
in
device's
registry. Is it possible? How to do it?
Thank you.

 

[Guest]

So, there IS a way to do this...I'll take a look at that stuff. Thanks!

The way to achieve what you're after is to sign the assembly and put it in
the GAC.

-Chris

Yes, you understand me correctly, I'm talking about building a managed
code
DLL that I want to reference from my program. However, what you're
describing
I'm doing right now: I'm referencing the DLL in my EXE, except my DLL
resides
under the same folder as my EXE, not the \Windows folder. I can change the
deployment path for the DLL, but again, every time I make changes to the
DLL,
I have to rebuild every project that has a reference to the DLL and
reinstall
the project on the device, right? I'm looking for something like this:
every
time I change the DLL, I just reinstall this single DLL file on the device
and my programs that use the DLL will pick up the change. Do you know what
I
mean? I don't know how to explain it better...

Ah, perhaps I'm starting to catch up. You're talking about building a
managed code DLL that you want to reference from your program, yes? The
easiest way to do this is, as I mentioned in the previous message, add
the
project to build the DLL to the workspace for building the EXE, and add a
reference for the EXE to the DLL project. Right-click on the EXE
project,
choose Add Reference... In the dialog which is presented, choose the
Projects tab, select the DLL project from the list and hit Select. This
will, if I remember right from VS.NET 2003, deploy to the same folder as
the
EXE and the managed loader will work with that, or you can change the
deployment options for the DLL project to put it in the \Windows folder.

Paul T.

"Paul G. Tobey [eMVP]" <p space tobey no spam AT no instrument no spam
DOT
com> wrote in message I don't recognize any Reference Path option that would show up in
Project
Properties. How did you get there and, while we're at it, what
development
environment are we talking about and what version?

The DLL is just a file laying around on the target device. Your EXE
has
to know *absolutely nothing, not one damn thing* about its location,
provided, as I said, that the loader can find it. The loader will
automatically look in \Windows, so you have to do *precisely nothing*,
if
you put the DLL there. Linkage is determined by linking the EXE with
the
import library for the DLL and I have absolutely no way of knowing
where
on your development system you might have put that. You *are* linking
with the DLL import library, right? Not using LoadLibrary() at
run-time
to load the DLL?

Paul T.

Yes, I perfectly understand the fact that the exe cannot change the
location
of the dll. When I said, "If...I decide to change the location, I have
to
change all those programs" I simply meant that I have to change the
Reference
Path in the Project Properties window. Or I don't have to? You see, I
don't
know how to tell the exe where to find the dll if the dll resides in
\Windows. Can you, please, tell me what I have to enter in Project
Properites
to make that linkage work?

:

No, that's not true. The *loader* has to know the location. If your
EXE is
linked to the DLL, it can't change where it's loaded from, even if it
knew,
anyway! It counts on the loader to find and load the DLL; if the
loader
can't find it, the EXE won't run. The loader uses a search path
stored
in
the registry to search, but I can't think of any good reason not to
install
in \Windows.

If you don't know how DLLs work, you need to read up on that before
deciding
on your installation scheme!

Paul T.

If I install the dll under \Windows, for example, all my programs
that
use
the dll would have to know the location. Again, if for some reason
I
decide
to change the location, I have to change all those programs,
instead
of
changing the single registry entry which stores the location. It's
not
that I
would change the location very often, but that's the reasoning
behind
using
the registry. I guess I can
install the dll into \Windows or whatever folder on the device, but
how do
I
tell the application where to find it?

:

Sure, separating the code commonly used by several programs into a
shared
DLL makes sense, but that, again, has *nothing* to do with the
registry.
The use of a DLL *at all* (regardless of the registry contents),
separates
the EXE from the DLL and, assuming you install the DLL into a
location
where
the loader can find it, \Windows, for example, your application
has
no
issues with the registry at all. The application won't work if
the
DLL
isn't installed, of course, but that's a separate issue.

Paul T.

I think there's a way to create a registry entry on the device
when
a
dll
gets installed...So I would have to install the dll separately
on
the
device,
which IS what I want to do - for the following reason: I'm using
the
dll
in
multiple applications. When I make changes to the dll, I have to
go
into
every single project, do the build, reinstall the project on the
device,
but
all I would have to do is reinstall the single dll. I think it
makes
sense,
doesn't it??



:

Well, without more details, all "registered in the device's
registry"
just
means that there's a simple string entry that calls out the
DLL's
name!
That's like saying, "Can you use a DLL on a device?" It has no
meaning
without details.

There's no reason in either of the situations that you mention
to
put
*anything* concerning the DLL into the registry. Just use the
DLL
from
the
application. You don't need the registry at all.

Paul T.

I didn't specify those things because I didn't think it would
matter...I
just
wanted to know if it's possible at all. Let me give you more
details:
I have two projects: the first one is Windows Applications
(that
will
use
the dll) and the second one is Class Library (this is the dll
that I
want
to
create a registry entry on the device for and reference it in
my
application). I want to be able to run the application on
Pocket
PC
2002,
2003, Windows Mobile 2003, and Windows Mobile 5.0.

:

Registered how? It's a COM DLL or what? You haven't told
us
what
version
of Windows Mobile the PPC has, what sort of DLL is it or how
you
want
to
use
it. Most of us here are *not* able to read minds over long
distances...

Paul T.

In my PPC app, I want to reference a dll that's registered
in
device's
registry. Is it possible? How to do it?
Thank you.