DLL in other directory then application on device

  • Thread starter Thread starter Peter
  • Start date Start date
P

Peter

Hello,

On my WINCE 4.2(not pocketpc) device I have a directory called "IPSM" where
I can put my application and data.
All other directories are not available to keep the data and app's after
reboot.

So my question is can I have my DLL's seperate in a other directory than the
directory in which I put my application to keep it all a little bit clean
When I put the DLL's in the same directory as my application all is
functioning OK

How can I do this?.

I'm working with VS 2003 in C#

thanks,
Peter.
 
If I understand your question, you want your exe and dll to be in separate
directories and specifically the dll to be in IPSM and the exe not,
correct?. I don't think you can do that. What use is the dll being preserved
if the exe isn't by the way?

With the CF, the dll has to be in the application's directory, the gac
(windows directory) or the root.

Cheers
Daniel
 
Thanks Daniel,

The .exe stays also in the IPSM as well as the DLL's , the reason I asked
was that I wanted to keep a nice structure for the data, application and
dll's

Regards,
Peter
 
OK got it.
The answer remains the same - you can't have the "nice structure".

Cheers
Daniel
 
The DLL must be in one of 2 places, the calling assembly's directory, or in
\Windows and GAC registered. THere are no options beyond that with CF 1.0

--
Chris Tacke
Co-founder
OpenNETCF.org
Has OpenNETCF helped you? Consider donating to support us!
http://www.opennetcf.org/donate
 
.... already replied to this Chris and the 3rd option you are not listing is
the root directory. Still no good to the OP :-)

Cheers
Daniel
 
There is one caveat, for native code DLLs and EXEs, you can actually create
a path on Windows CE. Open the registry of the device with the Remote
Registry Editor and find the key

HKEY_LOCAL_MACHINE\Loader

Under this key is a value, SystemPath. This multi-string value contains a
list of locations where the loader will look when you tell it to load a DLL
or EXE. You can open it in the Remote Registry Editor and add the path
where your DLL will be located.

However, the managed code run-time doesn't seem to use this path, so, if
your DLL is managed code, you're stuck.

Paul T.
 
Yes, you can.
The trick is to make sure your DLL is loaded in the current AppDomain before
you enter any function call that uses it internally. E.g. if you have a
function DoSomething() that internally creates a variable of type MyObject
that is defined in a class library MyLib.dll, then before you ever call this
function you need to do the following:

Assembly a = Assembly.LoadFrom("\path\to\MyLib.dll") // of course you need
to have a correct path here
TO be safe it can be done in the Main(), just before call to
Application.Run(), although for performance reasons you might want to spread
these calls further throughout the application.

A little catch - Studio will deploy all referenced assemblies with the
application automatically, so for the purpose of development you could
expicitly delete a newly copied dll from the application directory from your
code. This however will result in an inability to step through the dll code
since the device path will be unfamiliar to the Studio debugger
 
Thanks Paul.

I checked that and the path was IPSM\Windows\System on my device
Copied the openNET DLL's there but with no succes, because they are in
managed code also tried to copy there my resco advancedlist dll which resco
claims to have written in C++ but also with no succes.
So, I guess I'm out of luck.

Regards
Peter.





Paul G. Tobey said:
There is one caveat, for native code DLLs and EXEs, you can actually create
a path on Windows CE. Open the registry of the device with the Remote
Registry Editor and find the key

HKEY_LOCAL_MACHINE\Loader

Under this key is a value, SystemPath. This multi-string value contains a
list of locations where the loader will look when you tell it to load a DLL
or EXE. You can open it in the Remote Registry Editor and add the path
where your DLL will be located.

However, the managed code run-time doesn't seem to use this path, so, if
your DLL is managed code, you're stuck.

Paul T.
Click to expand...
 
Many thanks Alex !!! You made my day :-)))) this works !!
What is the correct way to do this with more then one dll ?

Regards,
Peter.
 
Alex, do you mean :

Assembly a = Assembly.LoadFrom("\path\to\MyLib.dll")
Assembly b = Assembly.LoadFrom("\path\to\MyOtherLib.dll")

or is this wrong ?

Thanks again,
Peter.
 
You don't even need to assign the result anywhere:
Assembly.LoadFrom("\path\to\MyLib.dll")
Assembly.LoadFrom("\path\to\MyOtherLib.dll")
Assembly.LoadFrom("\another path\to\YetAnotherLib.dll")
 
Back
Top