R
RadekP
Hi Gurus ..
I would really appreciate some insights for the problem that bugs me for
quite some time. I keep my custom controls in their own shared
(private/public key signed) assembly. I need to have it shared. Usually I
work with a Web application project that has a reference to my shared,
custom controls assembly. Web project is a "Startup Project". I need to be
able to set a breakpoint in my Custom Controls (shared) project. VS.NET
solution can hold more then one project - that's the most convenient way to
go. There is no problem to stop debugger at that breakpoint having all
assemblies kept as private. Annoyance begins with shared assemblies and its
projects not being set as a startup project. The reference "Copy Local =
false" always locks them up producing errors :
"The file xxx cannot be copied to the run directory. The process cannot
access the file because it is being used by another process".
"Copy Local = true" helps to eliminate the error since the reference is no
longer kept by public key in my Web application's manifest BUT even though
they should be treated at this point as private assemblies I can't seem to
get them to debug at all. I keep my shared assemblies in GAC so the
reference with "Copy Local = False" at the run time concerns this location.
Sometimes I succeed and can debug inside my shared assembly from other
startup project but in so indeterministic way. No matter what - locking up
shared assembly at the compilation time undermines efficient way of working
with multiproject VS.NET solution. Can somebody share any guildlines,
experiences ?
Best Regards
Radek
I would really appreciate some insights for the problem that bugs me for
quite some time. I keep my custom controls in their own shared
(private/public key signed) assembly. I need to have it shared. Usually I
work with a Web application project that has a reference to my shared,
custom controls assembly. Web project is a "Startup Project". I need to be
able to set a breakpoint in my Custom Controls (shared) project. VS.NET
solution can hold more then one project - that's the most convenient way to
go. There is no problem to stop debugger at that breakpoint having all
assemblies kept as private. Annoyance begins with shared assemblies and its
projects not being set as a startup project. The reference "Copy Local =
false" always locks them up producing errors :
"The file xxx cannot be copied to the run directory. The process cannot
access the file because it is being used by another process".
"Copy Local = true" helps to eliminate the error since the reference is no
longer kept by public key in my Web application's manifest BUT even though
they should be treated at this point as private assemblies I can't seem to
get them to debug at all. I keep my shared assemblies in GAC so the
reference with "Copy Local = False" at the run time concerns this location.
Sometimes I succeed and can debug inside my shared assembly from other
startup project but in so indeterministic way. No matter what - locking up
shared assembly at the compilation time undermines efficient way of working
with multiproject VS.NET solution. Can somebody share any guildlines,
experiences ?
Best Regards
Radek