VB.Net, .NET project locking/loading DLL created by other .NET project

.NET project locking/loading DLL created by other .NET project

Author	Message
Tim Roger #1 / 5	.NET project locking/loading DLL created by other .NET project I've got a .NET DLL I'm creating with MC++. This DLL is used by two "client" projects; one in C# and the other in VB.NET. All three projects are in the same solution for convenience. Because of distribution requirements, I need to have the MC++ project output it's DLL into a specific directory (for instance "MyDir"). Then, I need to have the other two client projects output their EXEs into the MyDir directory, AND reference the MC++ produced DLL in MyDir. (I don't want to do a post-build copy of targets to achieve this.) Here is the problem. I can build the DLL and the client projects just fine. All of the targets end up in MyDir as planned by changing the project's various output path/directory settings. The problem is after I build either of the client projects they appear to keep the referenced DLL loaded. So, if I try to compile the DLL again (via the MC++ project) I get the error "fatal error LNK1104: cannot open file <my Dll>". I thought the 'Copy Local' property in the client projects, of my referenced DLL, set to true was causing this issue, but setting it to false did not help. Is there any way to force the client projects to unload the referenced DLL immediately after compilation? (Note: We're compiling these projects via the command line.) I understand the client projects must load the DLL to resolve symbols for their own compilation, it just seems an annoyance that they don't unload afterwards. Thanks, Tim Rogers
Sun, 06 Mar 2005 20:52:09 GMT

Ron B. LaGron #2 / 5	.NET project locking/loading DLL created by other .NET project Sounds like the same problem many of us are having in that we can't compile some solutions more than once without unloading the solution and taking some action on the output directories. I hope you get more of a response than we have gotten on past messages. Quote: > I've got a .NET DLL I'm creating with MC++. This DLL is used by two > "client" projects; one in C# and the other in VB.NET. All three projects > are in the same solution for convenience. Because of distribution > requirements, I need to have the MC++ project output it's DLL into a > specific directory (for instance "MyDir"). Then, I need to have the other > two client projects output their EXEs into the MyDir directory, AND > reference the MC++ produced DLL in MyDir. (I don't want to do a post-build > copy of targets to achieve this.) > Here is the problem. I can build the DLL and the client projects just fine. > All of the targets end up in MyDir as planned by changing the project's > various output path/directory settings. The problem is after I build either > of the client projects they appear to keep the referenced DLL loaded. So, > if I try to compile the DLL again (via the MC++ project) I get the error > "fatal error LNK1104: cannot open file <my Dll>". I thought the 'Copy > Local' property in the client projects, of my referenced DLL, set to true > was causing this issue, but setting it to false did not help. > Is there any way to force the client projects to unload the referenced DLL > immediately after compilation? (Note: We're compiling these projects via > the command line.) I understand the client projects must load the DLL to > resolve symbols for their own compilation, it just seems an annoyance that > they don't unload afterwards. > Thanks, > Tim Rogers
Sun, 06 Mar 2005 21:35:01 GMT

Tim Roger #3 / 5	.NET project locking/loading DLL created by other .NET project Well, your reply makes me think that I probably won't. :-( BTW, in my scenario it's even worse than I though. I took out the client projects from the solution that contains the MC++ project, and put one of them into it's own solution. Now, just the fact that the solution with the client project is OPEN locks the DLL. You don't even have to build it. Now, that's nice. X-( Tim Rogers Quote: > Sounds like the same problem many of us are having in that we can't compile > some solutions more than once without unloading the solution and taking some > action on the output directories. I hope you get more of a response than we > have gotten on past messages. > > I've got a .NET DLL I'm creating with MC++. This DLL is used by two > > "client" projects; one in C# and the other in VB.NET. All three projects > > are in the same solution for convenience. Because of distribution > > requirements, I need to have the MC++ project output it's DLL into a > > specific directory (for instance "MyDir"). Then, I need to have the other > > two client projects output their EXEs into the MyDir directory, AND > > reference the MC++ produced DLL in MyDir. (I don't want to do a > post-build > > copy of targets to achieve this.) > > Here is the problem. I can build the DLL and the client projects just > fine. > > All of the targets end up in MyDir as planned by changing the project's > > various output path/directory settings. The problem is after I build > either > > of the client projects they appear to keep the referenced DLL loaded. So, > > if I try to compile the DLL again (via the MC++ project) I get the error > > "fatal error LNK1104: cannot open file <my Dll>". I thought the 'Copy > > Local' property in the client projects, of my referenced DLL, set to true > > was causing this issue, but setting it to false did not help. > > Is there any way to force the client projects to unload the referenced DLL > > immediately after compilation? (Note: We're compiling these projects via > > the command line.) I understand the client projects must load the DLL to > > resolve symbols for their own compilation, it just seems an annoyance that > > they don't unload afterwards. > > Thanks, > > Tim Rogers
Sun, 06 Mar 2005 22:16:51 GMT

Ron B. LaGron #4 / 5	.NET project locking/loading DLL created by other .NET project Yes, having a separate solution open that depends on your first solution can cause locking for sure. I wrote up a question about locking of one project within a solution when doing a compile a while back. Basically one of the projects within the solution would have its output locked during a compile, and I am basically unable to compile a second time. I have to close the solution, and remove the obj output directory of the thing that is locked. In my case exiting visual studio and such didn't help unless I removed the obj directory. There were several responses to my post sympathizing as others were experiencing this problem, but to my knowledge nobody from Microsoft (Hello???) ever responded. Quote: > Well, your reply makes me think that I probably won't. :-( > BTW, in my scenario it's even worse than I though. I took out the client > projects from the solution that contains the MC++ project, and put one of > them into it's own solution. Now, just the fact that the solution with the > client project is OPEN locks the DLL. You don't even have to build it. > Now, that's nice. X-( > Tim Rogers > > Sounds like the same problem many of us are having in that we can't > compile > > some solutions more than once without unloading the solution and taking > some > > action on the output directories. I hope you get more of a response than > we > > have gotten on past messages. > > > I've got a .NET DLL I'm creating with MC++. This DLL is used by two > > > "client" projects; one in C# and the other in VB.NET. All three > projects > > > are in the same solution for convenience. Because of distribution > > > requirements, I need to have the MC++ project output it's DLL into a > > > specific directory (for instance "MyDir"). Then, I need to have the > other > > > two client projects output their EXEs into the MyDir directory, AND > > > reference the MC++ produced DLL in MyDir. (I don't want to do a > > post-build > > > copy of targets to achieve this.) > > > Here is the problem. I can build the DLL and the client projects just > > fine. > > > All of the targets end up in MyDir as planned by changing the project's > > > various output path/directory settings. The problem is after I build > > either > > > of the client projects they appear to keep the referenced DLL loaded. > So, > > > if I try to compile the DLL again (via the MC++ project) I get the error > > > "fatal error LNK1104: cannot open file <my Dll>". I thought the 'Copy > > > Local' property in the client projects, of my referenced DLL, set to > true > > > was causing this issue, but setting it to false did not help. > > > Is there any way to force the client projects to unload the referenced > DLL > > > immediately after compilation? (Note: We're compiling these projects > via > > > the command line.) I understand the client projects must load the DLL > to > > > resolve symbols for their own compilation, it just seems an annoyance > that > > > they don't unload afterwards. > > > Thanks, > > > Tim Rogers
Sun, 06 Mar 2005 23:01:41 GMT

Josh Shepar #5 / 5	.NET project locking/loading DLL created by other .NET project the C# (and VB) project system does not robustly support changing the output directory to a common location. it most often results in project outputs being 'locked' and thus not being able to build the solution. sometimes this is intermittent, other times it happens consistently. i suggest that you work around the problem by letting the C# project build into its own directory and doing the copies later. in fact, i would recommend never changing the output directory of a C# project (also never setting the "copy local" property on a reference in a C# project, as this can cause similar problems). let the project system do its copying of files and then place the files where you need them after the build. i know, it's annoying that it creates all these seemingly un-needed copies, but it does them for a reason and trying to work around them generally breaks things :( (there is another known issue that causes locking with having the object browser open with project-to-project references and the C# project system. close the object browser to work around this). josh Quote: > I've got a .NET DLL I'm creating with MC++. This DLL is used by two > "client" projects; one in C# and the other in VB.NET. All three projects > are in the same solution for convenience. Because of distribution > requirements, I need to have the MC++ project output it's DLL into a > specific directory (for instance "MyDir"). Then, I need to have the other > two client projects output their EXEs into the MyDir directory, AND > reference the MC++ produced DLL in MyDir. (I don't want to do a post-build > copy of targets to achieve this.) > Here is the problem. I can build the DLL and the client projects just fine. > All of the targets end up in MyDir as planned by changing the project's > various output path/directory settings. The problem is after I build either > of the client projects they appear to keep the referenced DLL loaded. So, > if I try to compile the DLL again (via the MC++ project) I get the error > "fatal error LNK1104: cannot open file <my Dll>". I thought the 'Copy > Local' property in the client projects, of my referenced DLL, set to true > was causing this issue, but setting it to false did not help. > Is there any way to force the client projects to unload the referenced DLL > immediately after compilation? (Note: We're compiling these projects via > the command line.) I understand the client projects must load the DLL to > resolve symbols for their own compilation, it just seems an annoyance that > they don't unload afterwards. > Thanks, > Tim Rogers
Mon, 07 Mar 2005 04:49:45 GMT

Page 1 of 1

[ 5 post ]