S
Sune Foldager
We use a build system which compiles in 3-6 processes in parallel, using
the csc.exe program (usually via the .NET interface to it). To save time
copying resulting build products, we set the output directory to the destination
we want directly, instead of building each project to its own local location
and copying the results.
Sometimes a project will fail with a message something like:
c:\src\dev\GAF\Release\client\CSCD59A.tmp: error CS1567: Error generating
Win32 resource: The process cannot access the file because it is being used
by another process.
Investigating further, it seems csc produces a lot of files like that, CSCxxxx.tmp,
in the destination directory during compile, and removes them as soon as
it's done. The file names also seem to be very poorly protected from being
unique; it seems mostly like an increasing sequence of numbers. So my theory
is that it's simply a collision between the parallel build processes that
is the cause.
Why it doesn't use the (at any point in time) unique process id as part of
the name of the temp file is beyond me. Does anyone know of a way to get
around this other than building in another directory and copying stuff around?
Thanks in advance, and I really hope MS considers fixing this problem in
upcoming releases. Please use a more unique name, involving the process identifier
or similar
.
Sincerly,
Sune Foldager
Edlund A/S
the csc.exe program (usually via the .NET interface to it). To save time
copying resulting build products, we set the output directory to the destination
we want directly, instead of building each project to its own local location
and copying the results.
Sometimes a project will fail with a message something like:
c:\src\dev\GAF\Release\client\CSCD59A.tmp: error CS1567: Error generating
Win32 resource: The process cannot access the file because it is being used
by another process.
Investigating further, it seems csc produces a lot of files like that, CSCxxxx.tmp,
in the destination directory during compile, and removes them as soon as
it's done. The file names also seem to be very poorly protected from being
unique; it seems mostly like an increasing sequence of numbers. So my theory
is that it's simply a collision between the parallel build processes that
is the cause.
Why it doesn't use the (at any point in time) unique process id as part of
the name of the temp file is beyond me. Does anyone know of a way to get
around this other than building in another directory and copying stuff around?
Thanks in advance, and I really hope MS considers fixing this problem in
upcoming releases. Please use a more unique name, involving the process identifier
or similar
.Sincerly,
Sune Foldager
Edlund A/S