Odd problem with Visual Studio

[Ken Allen]

I have been developing a suite of assemblies over the past couple of weeks,
and this afternoon somethign started misbehaving.

If I do not run the IDE and compiler the code from the command line, the
compilation seems to work properly almost all of the time. More on this
later.

If I launch one copy of the IDE, then I can usually compile the project at
least once. At some point, the build fails reporting "Could not copy
temporary files to the output directory" and then indicates that one of the
DLL could not be copied to the run directory. At this point I cannot even
delete the file from the file explorer until I quit the IDE -- it seems that
something is locking the file!

I have tried to stop and start the IDE, log out and back in and even reboot,
all to no avail. This has been working fine for over two weeks, with me
running teo copies of the IDE -- one for debugging the server component and
one for debugging the client component, both within the same system and
sharing a couple of the assemblies. The DLL is question is one that is used
by the server component only.

The first indication something was different was when I compiled within one
copy of the IDE, started that component, switched to the other IDE, and when
I attempted to start that component running (debugging) it tried to
recompile all of the assemblies again, and this fails since some of the
assemblies are actually being used by the debug session in the other IDE
instance. Since the components that fail are not ones that I needed to
recompile, I generally ignored the problem and kept on debugging. This went
on all day until finally one copy (and now both copies) refuse to
successfully recompile, reporting the above error (on the same assembly).

One thing I should note is that I have all of the assembly projects
configured to place their resulting binaries (DLL or EXE) in the same
directory. This is done to make it easier to debug the applications and
services since the files are kept together.

As part of the checks I made on the project, I deleted all of the files from
the Drive:\Root\Bin\Release and Drive:\Root\Debug directories and then
attempted to rebuild from scratch. I did locate one circular reference that
I had introduced, and corrected that, and then I noticed that the *.csproj
files are reference using the relative path to the debug directory, which
meant that if I deleted all files and attempted to build the Release version
it failed! I had to build the debug version first. After thinking about this
I changed all of the project files to reference the dependant DLLs from the
Release directory.

I have not located the problem, and I am still unable to build the solution
and not get this error if even one IDE is running -- but when I lauch and
IDE, I can rebuild the entire solution once!

Does anyoine have any idea why this is happening and what I can do to
correct this?

-Ken

 

[Frans Bouma [C# MVP]]

I have been developing a suite of assemblies over the past couple of weeks,
and this afternoon somethign started misbehaving.

If I do not run the IDE and compiler the code from the command line, the
compilation seems to work properly almost all of the time. More on this
later.

If I launch one copy of the IDE, then I can usually compile the project at
least once. At some point, the build fails reporting "Could not copy
temporary files to the output directory" and then indicates that one of the
DLL could not be copied to the run directory. At this point I cannot even
delete the file from the file explorer until I quit the IDE -- it seems that
something is locking the file!

I have tried to stop and start the IDE, log out and back in and even reboot,
all to no avail. This has been working fine for over two weeks, with me
running teo copies of the IDE -- one for debugging the server component and
one for debugging the client component, both within the same system and
sharing a couple of the assemblies. The DLL is question is one that is used
by the server component only.

The first indication something was different was when I compiled within one
copy of the IDE, started that component, switched to the other IDE, and when
I attempted to start that component running (debugging) it tried to
recompile all of the assemblies again, and this fails since some of the
assemblies are actually being used by the debug session in the other IDE
instance. Since the components that fail are not ones that I needed to
recompile, I generally ignored the problem and kept on debugging. This went
on all day until finally one copy (and now both copies) refuse to
successfully recompile, reporting the above error (on the same assembly).

One thing I should note is that I have all of the assembly projects
configured to place their resulting binaries (DLL or EXE) in the same
directory. This is done to make it easier to debug the applications and
services since the files are kept together.

As part of the checks I made on the project, I deleted all of the files from
the Drive:\Root\Bin\Release and Drive:\Root\Debug directories and then
attempted to rebuild from scratch. I did locate one circular reference that
I had introduced, and corrected that, and then I noticed that the *.csproj
files are reference using the relative path to the debug directory, which
meant that if I deleted all files and attempted to build the Release version
it failed! I had to build the debug version first. After thinking about this
I changed all of the project files to reference the dependant DLLs from the
Release directory.

I have not located the problem, and I am still unable to build the solution
and not get this error if even one IDE is running -- but when I lauch and
IDE, I can rebuild the entire solution once!

Does anyoine have any idea why this is happening and what I can do to
correct this?

I assume you have a solution with projects A, B and C, and A references B
and C. Furthermore B and C reference both some given assembly. What I
sometimes see in this scenario is that B or C fail to compile due to this
error. If I first compile B and then C it's ok. You could try to set only one
of the references to copy local is true and the other to copy local is false.
This might solve the conflict.

Another solution (no pun intended) is the separation of some projects into a
separate solution and reference the assemblies from the main solution, not
the projects.

Frans.

 

[The Real Andy]

I assume you have a solution with projects A, B and C, and A references B
and C. Furthermore B and C reference both some given assembly. What I
sometimes see in this scenario is that B or C fail to compile due to this
error. If I first compile B and then C it's ok. You could try to set only one
of the references to copy local is true and the other to copy local is false.
This might solve the conflict.

Another solution (no pun intended) is the separation of some projects into a
separate solution and reference the assemblies from the main solution, not
the projects.

I too have had this same problem. Twas my fault though and feel stupid
saying this. When I was running up test harnesses, there was a bug in
my code and the application was not unloading correctly. The debugger
had stopped, but using task manager I noticed that the process was
still active. Ending the process solved all my problems and I was able
to compile straight away.

 

[Ken Allen]

You have mis-understood the problem. It is not the compilation that is
failing, but the transfer of the compiled assembly into the target
directory. I can do this once, but then one of the target files gets
'locked' and I cannot delete it until I exit the IDE!

I have put more detail in another posting.

-Ken

 

[Ken Allen]

Yes, I thought this was the problem as well, but it has nothing to do with
running the program!

I rebooted (so nothing of my test code is running). At this point I can
compile the code from the command line repeatedly without a problem. I
launch the IDE and open the solution file in debug, and immediately the
build, either from the IDE or from the command line, fails -- the
compilation succeeds but the resulting assembly file cannot be copied to the
target directory, nor can the target file be deleted until I exist from the
IDE.

I am posting more detail in another posting as I have made some progress.

-Ken

 

[Frans Bouma [C# MVP]]

You have mis-understood the problem. It is not the compilation that is
failing, but the transfer of the compiled assembly into the target
directory. I can do this once, but then one of the target files gets
'locked' and I cannot delete it until I exit the IDE!

I have put more detail in another posting.

No, I do have understood your problem, but perhaps formulated it not very
clear. One of the locked files has to be overwritten by a copy local
setting which is not possible and compile fails (sometimes you get very weird
errors, sometimes you get a copy error etc.). With webapplications sometimes
index server locks the assemblies in a bin dir and they therefore can't be
overwritten (so stop indexserver from going into these folders), sometimes it
is solved by removing obj folders or set copy-local to false. Have you tried
these settings?

Frans.

 

[Ken Allen]

OK, so I managed to stop the problem from happening, but the solution is odd
and I cannot do release builds properly.

After rebuilding the solution file and one of the project files a couple of
times, I spotted a difference in some of the project files-- and removing
that difference removed the problem! The difference was in the .csproj file
for one or more of the assemblies: in the <References> section there is an
attribute called "HintPath" that indicates where the referenced assembly may
be located -- in most of the projects this was
"..\..\Bin\Debug\assembly.DLL", but in at least one of the assembly projects
this read as "..\..\Bin\Release\assembly.DLL"! Once I changed all of the
..csproj files to contain the same path for all of the referenced assemblies
that are generated from the solution, the locked target file (actually one
of the "..\..\Bin\Debug\assembly.DLL" files) disappeared and I am able to
perform builds without errors once more!

After sleeping on this and coming in again this morning, I found this was
not the case! Some of the project files had been changes somehow during my
investigations, and the problem was being resolved because of the changed
settings. Specifically, some of the assembly outputs were not being directed
to the common target directory, and so the collision did not exist.

So, I started over from scratch, keeping a shadow copy of everything. Here
are the steps I followed:

1. Created an empty solution file and place the SLN and SUO files in the
proper directory.

2. Opened the solution from the IDE and added a new project for the first
class assembly (a class assembly common to the client and server code). I
modified the attibutes on the assembly to send the output to
[..\..\Bin\Debug\] and [..\..\Bin\Release\] for the two configurations. I
test built it a few times from the IDE and command line (with the IDE open)
and things are fine.

3. Copied the original source files into the new assembly directory, added
them to the project and removed the dummy "class1.cs" file from the
assembly, and adjusted the references to include the appropriate .Net
libraries. Repeated the build process tests, again with success.

4. Added a new project for the second common class assembly, modified the
output path, set the build order, and tested the build several times. Again
copied the original source files into the directory, added them to the
project and removed the dummy class1.cs file, adjusted the references to
include the appropriate .Net libraries and the first assembly project added
above, and repeated the build tests again.

5. Added a new project for the server-side class assembly, modified the
output path, set the build order, and tested the build several times. Again
copied the original source files into the directory, added them to the
project and removed the dummy class1.cs file, and adjusted the references to
include the appropriate .Net libraries and the two common assembly projects
already added, and repeated the build tests again.

6. Added a new project for a service, modified the project to generate a
console app (defaulted to a Windows app), modified the output path, set the
build order, and tested the build several times. Again copied the original
source files into the directory, added them to the project and removed the
dummy class1.cs file, and adjusted the references to include the appropriate
..Net libraries and the three assembly projects already added, and repeated
the build tests again. The first time it worked, but the subsequent attempts
to build the solution reports that the third assembly added (which
references the first two and is referenced by the serice) could not be
copied to the target directory, and the DLL file for this assembly in the
target directory cannot be deleted from the file explorer until the IDE
exits.

7. Opening the IDE in debug mode causes this problem to reported from a
command line compilation, but leaving the IDE open and simply switching to
Release confioguration (and doing nothing else) permits the command line
execution to proceed! Changing the IDE back to the debug configuration
causes the problem to again be reported on the command line invocation.

8. After some more hair pulling, I finally went to the source directories
for each of the new assemblies, and deleted all of the [obj]
sub-directories -- and this seems to have stopped the problem!!!! I only
thought of this when I deleted all files from the common Debug and Release
target directories and then attempted to do a Release build -- and the Debug
directory got files as well! Very odd!

-Ken

 

[Ken Allen]

None of this code is web oriented, it is all client/service code with some
common class assemblies. For the past 16 hours I have not even executed the
code! Nothing is running! The only thing it takes to 'lock' the file in the
common target directory is to open the IDE and select the Debug
configuration!

I have attempted to delete the bin and obj files from the assembly source
directories, but this only helps until the next build!

-Ken

 

[Ken Allen]

I spoke too soon. This only resolves the problem for 1-2 builds and then the
problem re-occurs.

What puzzles me is that I have not changed the assembly configurations for a
couple of days, although I have been adding code to the specific assemblies.

-Ken

OK, so I managed to stop the problem from happening, but the solution is odd
and I cannot do release builds properly.

After rebuilding the solution file and one of the project files a couple of
times, I spotted a difference in some of the project files-- and removing
that difference removed the problem! The difference was in the .csproj file
for one or more of the assemblies: in the <References> section there is an
attribute called "HintPath" that indicates where the referenced assembly may
be located -- in most of the projects this was
"..\..\Bin\Debug\assembly.DLL", but in at least one of the assembly projects
this read as "..\..\Bin\Release\assembly.DLL"! Once I changed all of the
.csproj files to contain the same path for all of the referenced assemblies
that are generated from the solution, the locked target file (actually one
of the "..\..\Bin\Debug\assembly.DLL" files) disappeared and I am able to
perform builds without errors once more!

After sleeping on this and coming in again this morning, I found this was
not the case! Some of the project files had been changes somehow during my
investigations, and the problem was being resolved because of the changed
settings. Specifically, some of the assembly outputs were not being directed
to the common target directory, and so the collision did not exist.

So, I started over from scratch, keeping a shadow copy of everything. Here
are the steps I followed:

1. Created an empty solution file and place the SLN and SUO files in the
proper directory.

2. Opened the solution from the IDE and added a new project for the first
class assembly (a class assembly common to the client and server code). I
modified the attibutes on the assembly to send the output to
[..\..\Bin\Debug\] and [..\..\Bin\Release\] for the two configurations. I
test built it a few times from the IDE and command line (with the IDE open)
and things are fine.

3. Copied the original source files into the new assembly directory, added
them to the project and removed the dummy "class1.cs" file from the
assembly, and adjusted the references to include the appropriate .Net
libraries. Repeated the build process tests, again with success.

4. Added a new project for the second common class assembly, modified the
output path, set the build order, and tested the build several times. Again
copied the original source files into the directory, added them to the
project and removed the dummy class1.cs file, adjusted the references to
include the appropriate .Net libraries and the first assembly project added
above, and repeated the build tests again.

5. Added a new project for the server-side class assembly, modified the
output path, set the build order, and tested the build several times. Again
copied the original source files into the directory, added them to the
project and removed the dummy class1.cs file, and adjusted the references to
include the appropriate .Net libraries and the two common assembly projects
already added, and repeated the build tests again.

6. Added a new project for a service, modified the project to generate a
console app (defaulted to a Windows app), modified the output path, set the
build order, and tested the build several times. Again copied the original
source files into the directory, added them to the project and removed the
dummy class1.cs file, and adjusted the references to include the appropriate
.Net libraries and the three assembly projects already added, and repeated
the build tests again. The first time it worked, but the subsequent attempts
to build the solution reports that the third assembly added (which
references the first two and is referenced by the serice) could not be
copied to the target directory, and the DLL file for this assembly in the
target directory cannot be deleted from the file explorer until the IDE
exits.

7. Opening the IDE in debug mode causes this problem to reported from a
command line compilation, but leaving the IDE open and simply switching to
Release confioguration (and doing nothing else) permits the command line
execution to proceed! Changing the IDE back to the debug configuration
causes the problem to again be reported on the command line invocation.

8. After some more hair pulling, I finally went to the source directories
for each of the new assemblies, and deleted all of the [obj]
sub-directories -- and this seems to have stopped the problem!!!! I only
thought of this when I deleted all files from the common Debug and Release
target directories and then attempted to do a Release build -- and the Debug
directory got files as well! Very odd!

-Ken

I have been developing a suite of assemblies over the past couple of weeks,
and this afternoon somethign started misbehaving.

If I do not run the IDE and compiler the code from the command line, the
compilation seems to work properly almost all of the time. More on this
later.

 

[Ken Allen]

Why is the IDE locking these files at all? They are not being locked by any
portion of my application executing since I am not executing anything at
this time other than the IDE!

-Ken

 

[Ken Allen]

As I mention earlier, one of the first symptoms of this propblem was that
when I went to execute some assembly, it automatically recompiled
everything. This was a change since up to that point it was only recompiling
the assemblies that had changed. I believe that the recompilation of one of
these assemblies is what is causing the problem. There should be no need to
copy the assembly if the current version is already in the target directory.

Even though I am not executing any portion of my code, the IDE seems to be
loading one of the assemblies, or locking it, when the service assembly that
references it is part of the solution! As long as I execute only a single
copy of the IDE and do not attempt to compile from the command line and the
IDE, things seem to be fine -- when I run more that one IDE (because I want
to debug both the client and the server code), then this problem arises. If
I have two copies of the IDE open with the same solution, if I compile
everything in one IDE and launch the server component, then in the other IDE
I attempt to launch the client, it recompiles everything again, even though
there is no need, and then I get this problem.

As I mentioned, this only started yesterday, so right now I am attempting to
reinstall Visual Studio .Net 1.1 Enterprise to see if that will change
anything.

-Ken

OK, so I managed to stop the problem from happening, but the solution is odd
and I cannot do release builds properly.

After rebuilding the solution file and one of the project files a couple of
times, I spotted a difference in some of the project files-- and removing
that difference removed the problem! The difference was in the .csproj file
for one or more of the assemblies: in the <References> section there is an
attribute called "HintPath" that indicates where the referenced assembly may
be located -- in most of the projects this was
"..\..\Bin\Debug\assembly.DLL", but in at least one of the assembly projects
this read as "..\..\Bin\Release\assembly.DLL"! Once I changed all of the
.csproj files to contain the same path for all of the referenced assemblies
that are generated from the solution, the locked target file (actually one
of the "..\..\Bin\Debug\assembly.DLL" files) disappeared and I am able to
perform builds without errors once more!

After sleeping on this and coming in again this morning, I found this was
not the case! Some of the project files had been changes somehow during my
investigations, and the problem was being resolved because of the changed
settings. Specifically, some of the assembly outputs were not being directed
to the common target directory, and so the collision did not exist.

So, I started over from scratch, keeping a shadow copy of everything. Here
are the steps I followed:

1. Created an empty solution file and place the SLN and SUO files in the
proper directory.

2. Opened the solution from the IDE and added a new project for the first
class assembly (a class assembly common to the client and server code). I
modified the attibutes on the assembly to send the output to
[..\..\Bin\Debug\] and [..\..\Bin\Release\] for the two configurations. I
test built it a few times from the IDE and command line (with the IDE open)
and things are fine.

3. Copied the original source files into the new assembly directory, added
them to the project and removed the dummy "class1.cs" file from the
assembly, and adjusted the references to include the appropriate .Net
libraries. Repeated the build process tests, again with success.

4. Added a new project for the second common class assembly, modified the
output path, set the build order, and tested the build several times. Again
copied the original source files into the directory, added them to the
project and removed the dummy class1.cs file, adjusted the references to
include the appropriate .Net libraries and the first assembly project added
above, and repeated the build tests again.

5. Added a new project for the server-side class assembly, modified the
output path, set the build order, and tested the build several times. Again
copied the original source files into the directory, added them to the
project and removed the dummy class1.cs file, and adjusted the references to
include the appropriate .Net libraries and the two common assembly projects
already added, and repeated the build tests again.

6. Added a new project for a service, modified the project to generate a
console app (defaulted to a Windows app), modified the output path, set the
build order, and tested the build several times. Again copied the original
source files into the directory, added them to the project and removed the
dummy class1.cs file, and adjusted the references to include the appropriate
.Net libraries and the three assembly projects already added, and repeated
the build tests again. The first time it worked, but the subsequent attempts
to build the solution reports that the third assembly added (which
references the first two and is referenced by the serice) could not be
copied to the target directory, and the DLL file for this assembly in the
target directory cannot be deleted from the file explorer until the IDE
exits.

7. Opening the IDE in debug mode causes this problem to reported from a
command line compilation, but leaving the IDE open and simply switching to
Release confioguration (and doing nothing else) permits the command line
execution to proceed! Changing the IDE back to the debug configuration
causes the problem to again be reported on the command line invocation.

8. After some more hair pulling, I finally went to the source directories
for each of the new assemblies, and deleted all of the [obj]
sub-directories -- and this seems to have stopped the problem!!!! I only
thought of this when I deleted all files from the common Debug and Release
target directories and then attempted to do a Release build -- and the Debug
directory got files as well! Very odd!

-Ken

I have been developing a suite of assemblies over the past couple of weeks,
and this afternoon somethign started misbehaving.

If I do not run the IDE and compiler the code from the command line, the
compilation seems to work properly almost all of the time. More on this
later.

 

[Frans Bouma [C# MVP]]

None of this code is web oriented, it is all client/service code with some
common class assemblies. For the past 16 hours I have not even executed the
code! Nothing is running! The only thing it takes to 'lock' the file in the
common target directory is to open the IDE and select the Debug
configuration!

I have attempted to delete the bin and obj files from the assembly source
directories, but this only helps until the next build!

But have you also tried to set copylocal to false? You only need 1 copy. If
multiple projects reference the same file and copy it local, it can be that
the copy action is going on for project A, AND a build is going on for
project B, which might conflict. As I said, I ran into these issues also, and
they went away after I switch copy local to false for all but 1 project: I
still get the files in the bin\debug folder (or release) and no conflicts.

Frans.

 

[Ken Allen]

I have tried changing the setting in the IDE, but it keeps getting reset to
true! Also, once the file is 'locked', whatever is causing this, even the
compilation of that assembly seems to have a problem. I will try this
again -- any hints on how to get the setting to stick? I presume you are
setting it via the reference property in the IDE...

-Ken

 

[Ken Allen]

Yes, I have confirmed that if I set the Local Copy to false then it is the
build of that assembly that fails.

The problem is that the IDE seems to be locking this assembly, even though I
have not executed my code, and I cannot determine why it is being locked!
The only way to unlock it is to not have the IDE/solution open in the debug
configuration -- or the configuration that I am attempting to build!

-Ken

 

[Ken Allen]

A small clue may have arisen...

After having rebuilt the entire solution and all of the projects, it came
time to place the code under VSS as other parts of the project need this,
even if I am having trouble with the IDE and debug mode.

When I opened the project and double-clicked on the C# source file in the
service assembly that has the same name as the project itself (e.g.,
WidgetService.cs in the WidgetService project), I got a display that
indicated "An error occurred while loading the document. Fix the error, and
then try loading the document again. The error message follows: Unspecified
error."

I do not know what the error is, but this may be the cause of the problem. I
can open the source file with View Code, so I shall attempt to rebuild this
project yet again.

-Ken

 

[Ken Allen]

Well, the only way that I have been able to resolve this is to ensure that
the server assembly that includes the other assemblies does not direct its
output to the same directory as the other assemblies! For some reason the
IDE is loading/locking the referenced assembly copy that resides in the same
diretory as the service assembly itself.

So now all assemblies direct their output to a common directory, execpt for
the debug configuraiton for this specific service, which sends its output to
its own directory (release mode still targets the common directory). This
then permits the actual assembly to compile and update its common copy, and
this specific service seems able to unlock and update its own copy as
needed.

Odd. But at least I am back to working again.

-Ken