Weird error: Could not copy temporary files to the output directory.

[Etienne Charland]

Hi, I have a solution containing 6 C# projects; 1 WinForms project and 5
class libraries. I didn't have any problems until recently. I added a new
project containing reports. I am using ActiveReports.Net. Now, whenever I
make a change to a report in the class library and recompile, I get this
error: "Could not copy temporary files to the output directory.". I have to
close VS.Net and reopen it in order to recompile, this is very cumbersome.
Anyway, I decided to investigate to reproduce the problem. I made an exact
copy of the solution from c:\InfoForest to c:\InfoForest2. But now, I can't
reproduce the problem anymore!!! It happens on c:\InfoForest but not on
InfoForest2. I could work on c:\InfoForest2, but I'd like to be working on a
correctly named folder. I moved c:\InfoForest away and renamed
c:\InfoForest2 as c:\InfoForest, and the problem came back... WTF?

Before copying or renaming folders, I completly close VS.Net. I have
problems when the project is located in c:\InfoForest ONLY. Anyone have any
other explanation than ghosts?

I am using VS.Net 2003 and Windows XP SP2, all in english.

Thanks!
Etienne

 

[Jeff Gaines]

Hi, I have a solution containing 6 C# projects; 1 WinForms project
and 5 class libraries. I didn't have any problems until recently. I
added a new project containing reports. I am using ActiveReports.Net.
Now, whenever I make a change to a report in the class library and
recompile, I get this error: "Could not copy temporary files to the
output directory.". I have to close VS.Net and reopen it in order to
recompile, this is very cumbersome. Anyway, I decided to investigate
to reproduce the problem. I made an exact copy of the solution from
c:\InfoForest to c:\InfoForest2. But now, I can't reproduce the
problem anymore!!! It happens on c:\InfoForest but not on
InfoForest2. I could work on c:\InfoForest2, but I'd like to be
working on a correctly named folder. I moved c:\InfoForest away and
renamed c:\InfoForest2 as c:\InfoForest, and the problem came back...
WTF?

Before copying or renaming folders, I completly close VS.Net. I have
problems when the project is located in c:\InfoForest ONLY. Anyone
have any other explanation than ghosts?

I am using VS.Net 2003 and Windows XP SP2, all in english.

Thanks!
Etienne

Something is hooked into one of your DLL's and so you can't over write
it - that's why it's OK in a different directory, the hook is into the
original.

I found when writing a shell extension that after testing I had to
un-register it, then close Explorer, then I could alter it and re-build
it.

In my case I think that somehow Explorer was the suspect, perhaps not
surprising since it was a context menu extension.

 

[Etienne Charland]

I do not have any fency interaction with Windows. It is just a management
software in front of a SQL database.

 

[Charles Law]

Hi Etienne

Have a look at the Project | Properties dialogue. There is a section
"Reference Path" that shows where references are found. When you rename a
directory, the reference path is not changed, so the problem goes away (as
another respondent hinted). When you rename back again the problem
re-appears.

Check for circular references, that is Project A references Project B, that
references Project C, that references Project A. This kind of thing is
allowed but can cause such problems. Also, it is preferable (because of a
problem in VS) to reference projects, rather than the DLL output from these
projects.

HTH

Charles

 

[Etienne Charland]

There is nothing wrong in Reference Path. I have alot of references between
the projects, so that could cause circular reference but... then, the
problem wouldn't go away when moving the solution. It's not that. I have
always added project references.

Etienne

 

[Jeff Gaines]

I do not have any fency interaction with Windows. It is just a
management software in front of a SQL database.

I would still suspect that 'something' is using one of the DLL's.

Can you delete them? There is a utility called 'WhoLockMe' which will
tell you what is locking a file if you can't delete it.

 

[Charles Law]

I wasn't suggesting that there was anything necessarily wrong in the
reference path. I was trying to explain why the problem goes away when you
rename the directory. When the directory has been renamed the reference path
remains unchanged, so the project references refer to the old location. When
you build the solution, the output from each project is created in the new
directory hierarchy. However, when references are resolved they are from the
original directory hierarchy. The result is no locking conflict, but you
will also find that you are not using the most recently built dlls from your
referenced projects.

Charles

 

[Etienne Charland]

I can delete the DLLs, but not the EXE. WhoLockMe looks like a great
utility, but it doesn't seem to work on XP SP2 The context menu
appeared, but clicking on it doesn't do anything.

Btw, I completly moved the solution to a different folder. This makes the
problem go away, but not because it references other DLLs. There is only one
version.

Etienne

 

[Charles Law]

Hi Etienne

I had the same problem with WhoLockMe. After I rebooted and tried again it
worked. I also have XP Pro with SP2.

HTH

Charles

 

[Charles Law]

I should add, if it doesn't find any locks then no window is displayed :-(

Charles

 

[Jeff Gaines]

Hi Etienne

I had the same problem with WhoLockMe. After I rebooted and tried
again it worked. I also have XP Pro with SP2.

HTH

Charles

Etienne/Charles

Thanks for that, I've been using WhoLockMe for a while and I didn't
realise you could register the DLL and run it from the context menu
It's a useful utility.

Are you OK with your app now Etienne?

 

[Etienne Charland]

WhoLockMe is still not working. But anyway, I know it is locked by Visual
Studio. The EXE file gets locked whenever I open the Active Reports designer
in one of the DLLs. I still don't know why...

Etienne