DLL from hell

  • Thread starter Thread starter Elisa
  • Start date Start date
E

Elisa

Hi,

Since yesterday, whenever I launch my application on the Pocket PC
Emulator, and then close my application, I can't rebuild my application
because Visual Studio keeps complaining about a DLL that can't be
overwritten (one of my own DLL's that is part of my application).

The message Visual Studio gives is:

"Unable to write to output file 'C:\SomeDir\obj\Debug\SomeDll.dll':
System error &H80070020"

If I try to delete this DLL using the File Explorer (or even the command
prompt), I get an error "Cannot delete SomeDLL: Access is denied. The
source file may be in use.".

The only thing that works, is rebooting and removing the DLL, but that
is not a very practical solution ;-)

Any idea what might be causing this? Is there some tool to see which
process is using the DLL (and thus preventing it from being overwritten)?


Regards,

Elisa
 
Elisa,

Does this DLL stay in memory after each build? Is it a DLL you've created
with VS?
 
Is this a native DLL or a managed DLL? If the latter case, is it in the
same solution or a separate solution? I have seen this occur when I have a
managed DLL in one solution and an application that references it in another
solution and I open both simultaneously at some point. If they are both
managed and C# then it might be best to add the DLL project to the solution
with the application and then reference the project directly.

--
Geoff Schwab
Program Manager
Excell Data Corporation
http://msdn.com/mobility
http://msdn.microsoft.com/mobility/prodtechinfo/devtools/netcf/FAQ/default.aspx

This posting is provided "AS IS" with no warranties, and confers no rights.
 
Hi Geoff,
Is this a native DLL or a managed DLL? If the latter case, is it in the
same solution or a separate solution?
Click to expand...

It's a managed DLL, in the same solution. I think it happens because I
have some object (or control) that I don't dispose of manually, yet at
the same time explicitly prevent the GC from disposing it automatically
(via a "GC.SuppressFinalize(Me)" call)...

I noticed that if I kill/stop the application via the debugger,
everything is fine, it's just when I quit the application normally,
appararently pieces are left lingering in limbo...


Regards,

Elisa
 
Hi,

I have seen this if the DLL creates a thread which is not terminated when
the application exits. If you create any threads, make sure that they
terminate themselves, do not rely on the Framework to clean them up when
closing.

Dick

--
Richard Grier (Microsoft Visual Basic MVP)

See www.hardandsoftware.net for contact information.

Author of Visual Basic Programmer's Guide to Serial Communications, 3rd
Edition ISBN 1-890422-27-4 (391 pages) published February 2002.
 
If this is one of the dlls in your project, I assume it is only used by your
application. A possible cause is that, even if you can't see any of its
forms, the app is not really terminating. Maybe it can still be seen in the
System/Memory/Running Tasks applet or using the eMbedded Tools Process
Viewer.

Hope this helps
 
This is a problem I have seen frequently with VS 2003 and debugging on
a remote device. The issue shows up when I stop the debugger and
immediately attempt to recompile. This issue usually shows up after a
little box pops up in the middle of VS, I can't read what it says
because it vanishes too fast. I haven't found a fix for this; I have
done two things to deal with it. First I wait until the debugger has
completely stopped and I have full control back into VS. This sounds
like a pain, but it only takes a few seconds and I hide it now by
stopping before I do any code changes. Second, when the issue shows up
save what you are doing and close/open Visual Studio. This will clear
the locks on the DLL and you will be able to rebuild/delete it at your
whim. I wish I could give you better solutions, but this is all I have
been able to deal with.

Also I think this has to do with threads not closing properly (or
quickly) on the O/S via the debugger. My applications without threads
do not seem to have this problem.

Norm
 
Hi,
what about a Soft (or Hard for that matter) reset ?
Click to expand...

I try to limit the use of resetting the emulator to the absolute
minimum, as it seems to be buggy. A Soft reset actually removes all my
settings and files on the emulator (e.g. it resets the name of the
Pocket PC, it removes .NET CF SP2, it removes all my application files,
etc.). So what should be a simple Soft reset actually looks more like a
Hard reset.

In any case, the problem is not that Visual Studio can't overwrite the
DLL in question on the emulator, it can't overwrite the DLL on the
development machine (bin/Debug/blabla.dll).


Regards,

Elisa
 
Back
Top