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\Deb ug 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]]

Ken Allen wrote:

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\Deb ug 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.

--
Get LLBLGen Pro, the new O/R mapper for .NET: http://www.llblgen.com
My .NET Blog: http://weblogs.asp.net/fbouma
Microsoft C# MVP

[The Real Andy]

On Wed, 28 Apr 2004 01:20:31 -0700, "Frans Bouma [C# MVP]"
<pe************ ******@xs4all.n l> wrote:

Ken Allen wrote:

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\Deb ug 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.

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

"Frans Bouma [C# MVP]" <pe************ ******@xs4all.n l> wrote in message
news:xn******** *******@msnews. microsoft.com.. .

Ken Allen wrote:

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

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.

--
Get LLBLGen Pro, the new O/R mapper for .NET: http://www.llblgen.com
My .NET Blog: http://weblogs.asp.net/fbouma
Microsoft C# MVP

[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

"The Real Andy" <.pearson@wayit _dot_com_dot_au _remove_the_obv ious_to_reply>
wrote in message news:hi******** *************** *********@4ax.c om...

On Wed, 28 Apr 2004 01:20:31 -0700, "Frans Bouma [C# MVP]"
<pe************ ******@xs4all.n l> wrote:

Ken Allen wrote:

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

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.

[Frans Bouma [C# MVP]]

Ken Allen wrote:

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

"Frans Bouma [C# MVP]" <pe************ ******@xs4all.n l> wrote in message
news:xn******** *******@msnews. microsoft.com.. .

Ken Allen wrote:

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

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.

--
Get LLBLGen Pro, the new O/R mapper for .NET: http://www.llblgen.com
My .NET Blog: http://weblogs.asp.net/fbouma
Microsoft C# MVP

[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\Debu g\assembly.DLL" , but in at least one of the assembly projects
this read as "..\..\Bin\Rele ase\assembly.DL L"! 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\Debu g\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\Relea se\] 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" <ke******@sympa tico.ca> wrote in message
news:eW******** *****@TK2MSFTNG P11.phx.gbl...

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]

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

"Frans Bouma [C# MVP]" <pe************ ******@xs4all.n l> wrote in message
news:xn******** *******@msnews. microsoft.com.. .

Ken Allen wrote:

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

"Frans Bouma [C# MVP]" <pe************ ******@xs4all.n l> wrote in message
news:xn******** *******@msnews. microsoft.com.. .

Ken Allen wrote:

> I have been developing a suite of assemblies over the past couple of

weeks,

> and this afternoon somethign started misbehaving.
>

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.

--
Get LLBLGen Pro, the new O/R mapper for .NET: http://www.llblgen.com
My .NET Blog: http://weblogs.asp.net/fbouma
Microsoft C# MVP

[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

"Ken Allen" <ke******@sympa tico.ca> wrote in message
news:uN******** ******@TK2MSFTN GP09.phx.gbl...

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\Debu g\assembly.DLL" , but in at least one of the assembly projects this read as "..\..\Bin\Rele ase\assembly.DL L"! 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\Debu g\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\Relea se\] 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" <ke******@sympa tico.ca> wrote in message
news:eW******** *****@TK2MSFTNG P11.phx.gbl...

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

"Frans Bouma [C# MVP]" <pe************ ******@xs4all.n l> wrote in message
news:xn******** *******@msnews. microsoft.com.. .

Ken Allen wrote:

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

"Frans Bouma [C# MVP]" <pe************ ******@xs4all.n l> wrote in message
news:xn******** *******@msnews. microsoft.com.. .

Ken Allen wrote:

> I have been developing a suite of assemblies over the past couple of

weeks,

> and this afternoon somethign started misbehaving.
>

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.

--
Get LLBLGen Pro, the new O/R mapper for .NET: http://www.llblgen.com
My .NET Blog: http://weblogs.asp.net/fbouma
Microsoft C# MVP