DLL Locking Shared Assemblies 
Author Message
 DLL Locking Shared Assemblies

We thought we were the only ones getting the problem but when we had a look
at the web found some body having posted the same question but no answers
yet . I have included the transcript of that below . We exactly face the
same situation and any help or workarounds would save us several mandays of
lost productivity because of this issue

==========================================================

Quote:
>WHEN is Microsoft going to fix the problem with VS.NET where it cannot
>build the solution because it is locking DLLs ? This
>has been a problem since day one and I have wasted DAYS of time over the
>last 12 months battling this.  I can't even work on one of the
subprojects
>because everytime I make a change and compile it, it fails because the
DLL
>is locked and I have to exit VS.NET, delete the project's bin and obj
>folders and reload VS.NET.  Another way that the problem manifests itself
>is that the subproject will build fine but another subproject that
>references that subproject will not build saying something like it can't
>find the type of namespace in that project.

>(YES, all references to the project in question are Project references,
not
>File references - which, according the Microsoft, should make it work
fine)

>Surely a hell of a lot of people out there are running into this
problem...
>or is no one out besides me and a few others foolish enough to try a
large-
>scale .NET project yet?

>Sorry for the ranting and raving but I have completely lost my patience
>with this.

=======================================================
I get the same problem when building in studio and have noticed a
few "quicker" work arounds.  I generally run between 4-6 web projects and
2
class library projects in the same solution referencing each other.  At
least for me, when it indicates the file is in use and wont compile, the
file really is not in use nor does VS.NET have a file lock on it.  Just go
to the .dll file in the bin folder it's complaining about and delete it
and
re-compile.  I think I only had to close studio twice when I have recieved
the error.  Another thing I noticed is that I don't remember receiving
these errors until I started using XP Pro.  When using Win2K server as my
dev machine, I don't recall getting these errors.  It's possible that my
project/solution configuration has changed since then enough to now get
the
errors.  One other thing, ocassionally the indexing service can have a
lock
on your dll's temporarily and it may not be studio that is causing the
problem.  You assume it's studio, close it as usual, start it back up and
everything works fine.  By that time, the indexing service has released
the
lock.  You may want to stop the service if it is running and see if this
reduces the number of times your dll's are locked.
-Chad
==================================================================

Regards
Bijoy



Sun, 22 May 2005 19:27:38 GMT  
 DLL Locking Shared Assemblies
Bijoy,

    I would consider shutting down the server completely, which will shut
down the runtime and then let go of the references that the framework is
holding on your assemblies.  In order to do this, you can use the following
on the command line:

net stop iisadmin

    This will shut down the IIS administration service, which will
subsequently shut down the WWW publishing service, as well as the FTP
publishing service.  When you are done, you can use the following to start
the service:

net start iisadmin

    Hope this helps.

--
               - Nicholas Paldino [.NET/C# MVP]


Quote:
> We thought we were the only ones getting the problem but when we had a
look
> at the web found some body having posted the same question but no answers
> yet . I have included the transcript of that below . We exactly face the
> same situation and any help or workarounds would save us several mandays
of
> lost productivity because of this issue

> ==========================================================
> >WHEN is Microsoft going to fix the problem with VS.NET where it cannot
> >build the solution because it is locking DLLs ? This
> >has been a problem since day one and I have wasted DAYS of time over the
> >last 12 months battling this.  I can't even work on one of the
> subprojects
> >because everytime I make a change and compile it, it fails because the
> DLL
> >is locked and I have to exit VS.NET, delete the project's bin and obj
> >folders and reload VS.NET.  Another way that the problem manifests itself
> >is that the subproject will build fine but another subproject that
> >references that subproject will not build saying something like it can't
> >find the type of namespace in that project.

> >(YES, all references to the project in question are Project references,
> not
> >File references - which, according the Microsoft, should make it work
> fine)

> >Surely a hell of a lot of people out there are running into this
> problem...
> >or is no one out besides me and a few others foolish enough to try a
> large-
> >scale .NET project yet?

> >Sorry for the ranting and raving but I have completely lost my patience
> >with this.

> =======================================================
> I get the same problem when building in studio and have noticed a
> few "quicker" work arounds.  I generally run between 4-6 web projects and
> 2
> class library projects in the same solution referencing each other.  At
> least for me, when it indicates the file is in use and wont compile, the
> file really is not in use nor does VS.NET have a file lock on it.  Just go
> to the .dll file in the bin folder it's complaining about and delete it
> and
> re-compile.  I think I only had to close studio twice when I have recieved
> the error.  Another thing I noticed is that I don't remember receiving
> these errors until I started using XP Pro.  When using Win2K server as my
> dev machine, I don't recall getting these errors.  It's possible that my
> project/solution configuration has changed since then enough to now get
> the
> errors.  One other thing, ocassionally the indexing service can have a
> lock
> on your dll's temporarily and it may not be studio that is causing the
> problem.  You assume it's studio, close it as usual, start it back up and
> everything works fine.  By that time, the indexing service has released
> the
> lock.  You may want to stop the service if it is running and see if this
> reduces the number of times your dll's are locked.
> -Chad
> ==================================================================

> Regards
> Bijoy



Sun, 22 May 2005 21:15:50 GMT  
 DLL Locking Shared Assemblies
I think Microsoft finally did acknowledge this problem (I don't remember in
what thread), and it was stated to only occur for projects whose output dll
was larger than 64K.  I don't remember if any timeframe was given when it
would be fixed.  I had similar issues, and yes it only occurred on the dlls
of that size or larger.  Luckily for me the dlls that were causing problems
were replaced, so I no longer have the problem, but it is only a matter of
time.


Quote:
> We thought we were the only ones getting the problem but when we had a
look
> at the web found some body having posted the same question but no answers
> yet . I have included the transcript of that below . We exactly face the
> same situation and any help or workarounds would save us several mandays
of
> lost productivity because of this issue

> ==========================================================
> >WHEN is Microsoft going to fix the problem with VS.NET where it cannot
> >build the solution because it is locking DLLs ? This
> >has been a problem since day one and I have wasted DAYS of time over the
> >last 12 months battling this.  I can't even work on one of the
> subprojects
> >because everytime I make a change and compile it, it fails because the
> DLL
> >is locked and I have to exit VS.NET, delete the project's bin and obj
> >folders and reload VS.NET.  Another way that the problem manifests itself
> >is that the subproject will build fine but another subproject that
> >references that subproject will not build saying something like it can't
> >find the type of namespace in that project.

> >(YES, all references to the project in question are Project references,
> not
> >File references - which, according the Microsoft, should make it work
> fine)

> >Surely a hell of a lot of people out there are running into this
> problem...
> >or is no one out besides me and a few others foolish enough to try a
> large-
> >scale .NET project yet?

> >Sorry for the ranting and raving but I have completely lost my patience
> >with this.

> =======================================================
> I get the same problem when building in studio and have noticed a
> few "quicker" work arounds.  I generally run between 4-6 web projects and
> 2
> class library projects in the same solution referencing each other.  At
> least for me, when it indicates the file is in use and wont compile, the
> file really is not in use nor does VS.NET have a file lock on it.  Just go
> to the .dll file in the bin folder it's complaining about and delete it
> and
> re-compile.  I think I only had to close studio twice when I have recieved
> the error.  Another thing I noticed is that I don't remember receiving
> these errors until I started using XP Pro.  When using Win2K server as my
> dev machine, I don't recall getting these errors.  It's possible that my
> project/solution configuration has changed since then enough to now get
> the
> errors.  One other thing, ocassionally the indexing service can have a
> lock
> on your dll's temporarily and it may not be studio that is causing the
> problem.  You assume it's studio, close it as usual, start it back up and
> everything works fine.  By that time, the indexing service has released
> the
> lock.  You may want to stop the service if it is running and see if this
> reduces the number of times your dll's are locked.
> -Chad
> ==================================================================

> Regards
> Bijoy



Sun, 22 May 2005 23:14:36 GMT  
 DLL Locking Shared Assemblies

Quote:

> We thought we were the only ones getting the problem but when we had a look
> at the web found some body having posted the same question but no answers
> yet . I have included the transcript of that below . We exactly face the
> same situation and any help or workarounds would save us several mandays of
> lost productivity because of this issue

Over the last 6 months or so, our company has had to reinstall 3
development machines because of this issue.

The latest time was last week when I was using my Win2K machine and
working on our main .NET product, which consists of 7 projects
referencing each other in one solution. I suddenly started getting
"The file 'bin\whatever.dll' cannot be copied to the run directory.
The process cannot access the file because it is being used by another
process." during compiles.

The problem first occurred after I removed a COM interop library from
that project, but it may have been co-incidence (reversing that change
didn't resolve the problem, and making the same change on other
machines didn't cause any problem)

So far we have not managed to explain what happens. We don't think
this is the 64KB DLL issue, as other machines can compile exactly the
same code without problem.

I tried various permutations of the following, without success:

  Restarting VS.NET

  Rebooting

  Renaming the old source directory and getting a new copy of the
source code from our Source Control system

  Removing the cache files in C:\Documents and
Settings\Username\VSWebCache

  Removing the cache files in
C:\WINNT\Microsoft.NET\Framework\v1.0.3705\Temporary ASP.NET files

After trying the above, sometimes the product would compile once or
twice, and then the problem would occur again.

When this had previously happened to others in the department, they
had tried using VS.NET's Repair option without success, so I decided
to completely remove and reinstall Visual Studio .NET; unfortunately
the uninstall failed, and after this the VS.NET installer would no
longer run.

At this point I had already lost half a day to the issue, so I decided
to cut my losses and totally reinstall my machine. This has resolved
the problem for now.



Mon, 23 May 2005 17:44:49 GMT  
 DLL Locking Shared Assemblies
I believe this is an issue that microsoft has corrected with the
framework service pack:

// description of problem and fix
http://support.microsoft.com/default.aspx?scid=kb;EN-US;319991

// summary of fixes
http://support.microsoft.com/?kbid=321884&sd=msdn



Wed, 25 May 2005 05:54:45 GMT  
 
 [ 5 post ] 

 Relevant Pages 

1. Inline assembly locks system on INT instruction

2. DLL with shared data/class not sharing...

3. Share CObArray Object using DLL Section share method

4. Create ocx in Dll(regular Dll using shared MFC Dll)

5. Create ocx in Dll(Regular Dll using Shared MFC Dll)

6. Create ocx in Dll(Regular Dll using Shared MFC Dll)

7. What are shared-locks, exclusive locks, read-write locks?

8. Multiple Version Shared Assemblies & Remoting

9. Running assemblies from shared directories

10. Deploying a shared assembly

11. Shared assembly with C#

12. File locking/sharing

 

 
Powered by phpBB® Forum Software