PC Review
Forums
Newsgroups
Microsoft DotNet
Microsoft Dot NET Framework
Debugging Shared Assemblies (ex. Custom Controls)
Forums
Newsgroups
Microsoft DotNet
Microsoft Dot NET Framework
Debugging Shared Assemblies (ex. Custom Controls)
![]() |
Debugging Shared Assemblies (ex. Custom Controls) |
|
|
Thread Tools |
Rating:
|
|
|
#1 |
|
Guest
Posts: n/a
|
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 |
|
![]() |
|
| Thread Tools | |
| Rate This Thread | |
|
|

Main Page 


