problem with a shared assembly in a VS solution
-
I'm having a problem with shared assemblies > 2^16 bytes in size. My assembly is in a solution along with a console app that references the assembly. The app is set up to reference the assembly (the reference path is pointed to the assemblies output directory). When I do a build, the assembly is failing to build because the .dll is loaded. If I remove the console app's reference to the assembly everything is fine. I'm getting the following output from the build: The file 'Test_Library.dll' cannot be copied to the run directory. The process cannot access the file because it is being used by another process. Could not copy temporary files to the output directory. I've created a few other shared assemblies with no problems. This is the first time I've seen this exact problem and in trying to run it down I've discovered that if the .dll's size is < 65536 bytes (as all my other ones are), this doesn't happen. It looks like VS is loading the .dll when I add the reference for the console app. If I delete the console app's reference to the assembly, I am able to build the library. I hope one of you has run across this before. thanks for any help
-
I'm having a problem with shared assemblies > 2^16 bytes in size. My assembly is in a solution along with a console app that references the assembly. The app is set up to reference the assembly (the reference path is pointed to the assemblies output directory). When I do a build, the assembly is failing to build because the .dll is loaded. If I remove the console app's reference to the assembly everything is fine. I'm getting the following output from the build: The file 'Test_Library.dll' cannot be copied to the run directory. The process cannot access the file because it is being used by another process. Could not copy temporary files to the output directory. I've created a few other shared assemblies with no problems. This is the first time I've seen this exact problem and in trying to run it down I've discovered that if the .dll's size is < 65536 bytes (as all my other ones are), this doesn't happen. It looks like VS is loading the .dll when I add the reference for the console app. If I delete the console app's reference to the assembly, I am able to build the library. I hope one of you has run across this before. thanks for any help
Yes, and it's definitely a bug in VS.NET. One thing that helps eliminate the problem is to use a Project reference instead of a file reference. When adding the reference to a project in your solution to another project, click on the Projects tab in your Add Reference dialog. Select the project. This not only helps eliminate the problem a little, but it also ensures that whenever you make a build of your library/application, that the proper build of the dependency is created as well. For instance, when you create a Debug build all dependencies are built in debug mode. When this problem occurs, pretty much all you can do is make sure that your application isn't running (use the Process tab in the Task Manager to really make sure - just because you can't see it doesn't mean it's not running) and restart VS.NET to get it to release the lock on the executable(s).
-----BEGIN GEEK CODE BLOCK----- Version: 3.21 GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++ -----END GEEK CODE BLOCK-----
-
Yes, and it's definitely a bug in VS.NET. One thing that helps eliminate the problem is to use a Project reference instead of a file reference. When adding the reference to a project in your solution to another project, click on the Projects tab in your Add Reference dialog. Select the project. This not only helps eliminate the problem a little, but it also ensures that whenever you make a build of your library/application, that the proper build of the dependency is created as well. For instance, when you create a Debug build all dependencies are built in debug mode. When this problem occurs, pretty much all you can do is make sure that your application isn't running (use the Process tab in the Task Manager to really make sure - just because you can't see it doesn't mean it's not running) and restart VS.NET to get it to release the lock on the executable(s).
-----BEGIN GEEK CODE BLOCK----- Version: 3.21 GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++ -----END GEEK CODE BLOCK-----
Alright, thanks for the feedback. I'll try a project reference. This is a real bummer though.. I hope they fix this soon as it really stinks up developing a library of any size.
-
Alright, thanks for the feedback. I'll try a project reference. This is a real bummer though.. I hope they fix this soon as it really stinks up developing a library of any size.
It doesn't have anything to do with the size of the assembly. You've found a pattern, but a pattern unique to you. That happens to us with assemblies of all sizes, and assemblies that are referenced by others both frequently and infrequently. This problem exists in both VS.NET 2002 and 2003. While I too hope they fix it, it's not looking too good. I know a lot of people - including myself - have posted this bug to their newsgroups, but you should as well (use the NNTP server msnews.microsoft.com or the web-based news reader on their site in various places). Every mention should help.
-----BEGIN GEEK CODE BLOCK----- Version: 3.21 GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++ -----END GEEK CODE BLOCK-----