No free slot for more dll's

[Empi]

Hi,

I've got a project with heavy graphic elements (picture boxes, image lists
etc).
At some point of development I needed additional dll's but I can't load them
since I'm out of "dll's memory" slots.

I thought of several solutions:

1) generate a seperate exe utility that is activated from the main exe, and
is actually an interface to the dll.
(did that. takes too long for the exe to load each time I need it).

2) Use the same utility as a tcp/ip server.
did that. for some reason, the utility is ending with "native error"...
and restarted automatically by my software.

3) Use messaging.

4) try to load the bitmaps on the fly, only the needed ones.
This way I might free enough space for the additional dll.


My questions:
1) Are there any other solutions?
2) What is your opinion about the best way to solve it?
3) How can I check to see how far am I from being able to load additional
dll('s) ? (current allocated memory / dll's size etc )?

Thanks for all the help.

Empi.

 

[Paul G. Tobey [eMVP]]

5) Combine the large number of small DLLs that you are using for various
activities into a single larger DLL.

Paul T.

 

[Empi]

Could do that ... only they are a third party dll's.



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

 

[David Hearn]

Have you looked at ILMerge? I understand it combines multiple DLLs etc
into a single Assembly. I don't believe you need the source code for
the DLLs etc.

See:

<http://research.microsoft.com/~mbarnett/ILMerge.aspx>
<http://blog.opennetcf.org/ncowburn/2007/01/30/UsingILMergeOnCompactFrameworkApplications.aspx>

Hope that might help,

David

Could do that ... only they are a third party dll's.



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

5) Combine the large number of small DLLs that you are using for various
activities into a single larger DLL.

Paul T.

 

[Guest]

There really isn't such a thing as a "DLL memory slot". You're probably
thinking of the 32 process slot limit in Windows CE 5.0 and earlier, and the
number of DLLs you have has no effect on that.

Native DLLs use up virtual memory, and that is often where the problem lies
with lots of DLLs - you run out of address space to use physical RAM.
However managed DLLs don't directly use virtual space. They *don't* get
mapped in like a native DLL and immediately consume a minimum of 64k of
virtual space. Instead they are memory-mapped files and the only virtual
space they take is the space that class instances take up in the GC Heap
when they are loaded - and this is per object, not per DLL.

The short of it is that if you have a problem now, separate EXEs will only
make the problem worse. If you're using a lot of bitmaps and just loading
and holding all of them, that's likely a big problem area.


--

Chris Tacke, Embedded MVP
OpenNETCF Consulting
Managed Code in an Embedded World
www.OpenNETCF.com

 

[Empi]

Thanks.

Any recommendation regarding a software that will show me just how much
memory do I use - on the fly?
(physical / virtual etc.)

Thanks.

 

[Empi]

Forgot to mention.

I did implement an additional exe, and the dll's works great.
I pass the request as a parameter, and get the result in the returned
result.
An additional solution I tried was the tcp/ip server & client.
The exe server listens for the requests, and responds the result.
Both works fine.
What does this imply ?

 

[Shloma Baum]

Very intresting post!! never knew there is a difference in this regard
between a native DLL and a managed.

Thanks