Member Avatar for AT--O

Precedents:
Using visual basic express 2010 on windows 7 pro 64b.
Solution one CLB is a class library with multiple projects.
Solution two WFA is a windows form application with a reference to one of the CLB projects .dll located in the bin release folder (not the debug folder).
Problem:
When CLB gets modified and build, the WFA shows for the class on the .dll:
“Type “MyClass” is not defined”
and at description:
“Unable to load referenced library “MyLibraryDllPath”. The process cannot access the file because it is being used by another process”
Bad solutions:
This problem gets solved by either deleting and adding again the reference or by closing the WFA in which case when reopen the reference is good again.
I know that:
When referencing the .dll on the bin debug folder doesn’t present this problem after the . dll builds again.
Solutions with multiple projects don’t create a .dll on the debug folder just on the release one.
Questions:
How do I fix this problem?
Why a reference to the .dll on the debug folder doesn’t generate this problem after the .dll buids again and references to the release folder do?
Why multiproject solutions doesn’t create a .dll on the debug and single project solutions do?
Why do I get the message “…cannot access the file because because it is being used by another process”?
What is that other process using it?
cess the file because because it is being used by another process”?
What is that other process using it?

  • 2 Contributors
  • 1 Reply
  • 538 Views
  • 2 Days Discussion Span
  • Latest Post Latest Post by pardeep3dec

Dani AI

Generated

Short summary and the quick fix

This is almost always a file-lock / build-order problem: Visual Studio or another process has a handle on the compiled DLL so MSBuild cannot overwrite it, which breaks the reference in the other project. The correct, long-term fix is to reference the library project instead of the compiled DLL (project-to-project reference). That lets Visual Studio manage build order, CopyLocal, and avoids brittle file-path references. (learn.microsoft.com)

How to find the process holding the DLL

Use Process Explorer or SysInternals Handle to find which process has the file open. Run Process Explorer as Administrator, press Ctrl+F (Find Handle or DLL), type the DLL name and it will show the process and handle. From there stop the process (or close the solution/runner) and rebuild. Example command-line check with Handle:

handle.exe "C:\path\to\MyLibrary.dll"
handle.exe -c <HandleID> -p <PID>

Common culprits: Visual Studio (devenv/vshost/vstest), test runners, IIS/ASP.NET shadow-copying, antivirus/indexers. These are well-known causes for the “process cannot access the file” error. (miajimyu.com)

Practical steps (in order)

  • Best: add the CLB project into the WFA solution and add a Project Reference (References → Add Reference → Projects). This creates a build dependency and generally prevents the problem. (learn.microsoft.com)
  • If you must reference a built DLL: stop the process that has it open (use Process Explorer), or change your build to produce and consume the same configuration/output path.
  • Temporary workaround (last resort): a pre-build script that renames/moves the locked file before build (many teams use this to get unblocked), but use with caution — it masks the root cause and can cause stale-state issues:
if exist "$(TargetPath).locked" del "$(TargetPath).locked"
if exist "$(TargetPath)" if not exist "$(TargetPath).locked" move "$(TargetPath)" "$(TargetPath).locked"

This kind of pre-build trick and similar community workarounds are commonly suggested but should be temporary. (stackoverflow.com)

What about 's suggestion?

Setting objects to Nothing / calling Dispose helps only if a running instance of the WFA (or a test runner) is holding the DLL at runtime. It does not address the IDE/process-level file handle that blocks MSBuild — for that you must identify and stop the process (see Process Explorer above). (stackoverflow.com)

Check the project configuration

Make sure Debug/Release output paths are what you expect (OutputPath per-configuration). A misconfigured project can be building into Release while the consumer expects Debug (or vice-versa), which explains why one folder behaves differently. Fixing OutputPath / Configuration Manager often resolves confusing differences. (stackoverflow.com)

Start by converting the reference to a project reference; if that’s not possible, run Process Explorer to find the locker and work from there.

Member Avatar for pardeep3dec

show your code and i think after using that object your are not releasing that object like
object_name=nothing
or
object_name.dispose()

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.