|
|
You're in the
visual studio .net ide
group:vs.net locks dlls needed for compilation!?
visual studio .net ide:
Hi, When solutions grow and contain several projects (10, 20 or more) people complain that they can't compile their projects anymore. Why? The IDE locks some dlls (assemblies from project output) and doesn't free them anymore. Every attempt to compile those solutions fail with an error message "... because it's locked by an other process". The error can't be reproduced on every machine but frequently happens and usually doesn't disapear anymore once occured. The locked file get's freed when the devenv process is terminated (:-)). Currently I'm supporting a guy working on a project where he has errors like that every time of compilation and he's spending quite an amount of his time shuting down and restarting the IDE. What's going on? What can we do? I mean it's a bug, a pretty nasty one, not because it's so horrible, but because it kills productivity and really hits the wallet. Does anyone have a solution for that problem or share that experience? Is there an (educated) explanation for it. It seems like te IDE has a resource leck when reflecting the assemblies... Any comments appreciated thanks Christian Kuendig
forgot to mention:
considering KB - 313512 doesn't really help... http://support.microsoft.com/default.aspx?scid=kb;en- us;313512 [quoted text, click to view] >-----Original Message-----
>(IDE: VS2003 7.1.3088) > >Hi, > >When solutions grow and contain several projects (10, 20 >or more) people complain that they can't compile their >projects anymore. > >Why? The IDE locks some dlls (assemblies from project >output) and doesn't free them anymore. Every attempt to >compile those solutions fail with an error message "... >because it's locked by an other process". >The error can't be reproduced on every machine but >frequently happens and usually doesn't disapear anymore >once occured. > >The locked file get's freed when the devenv process is >terminated (:-)). Currently I'm supporting a guy working >on a project where he has errors like that every time of >compilation and he's spending quite an amount of his time >shuting down and restarting the IDE. > >What's going on? What can we do? I mean it's a bug, a >pretty nasty one, not because it's so horrible, but >because it kills productivity and really hits the wallet. > >Does anyone have a solution for that problem or share >that experience? Is there an (educated) explanation for >it. > >It seems like te IDE has a resource leck when reflecting >the assemblies... > >Any comments appreciated > >thanks > >Christian Kuendig >..Net Competence Centre, HSR University, Switzerland >.
[quoted text, click to view]
"Christian Kuendig" <*removethis*kuendigc@spectraweb.ch> wrote in message news:025a01c36c0f$81c582a0$a501280a@phx.gbl... > (IDE: VS2003 7.1.3088) > > Hi, > > When solutions grow and contain several projects (10, 20 > or more) people complain that they can't compile their > projects anymore. At least in VS.NET 2002, a large solution isn't required to cause this problem. The solution is to exit devenv and start over. If that's taking too long, perhaps you could consider using smaller solutions for day-to-day work? -- John Saunders Internet Engineer john.saunders@surfcontrol.com
"Christian Kuendig" <*removethis*kuendigc@spectraweb.ch> wrote in
news:025a01c36c0f$81c582a0$a501280a@phx.gbl: [quoted text, click to view] > When solutions grow and contain several projects (10, 20 I only experienced this when I had a signed assembly A which was > or more) people complain that they can't compile their > projects anymore. > > Why? The IDE locks some dlls (assemblies from project > output) and doesn't free them anymore. Every attempt to > compile those solutions fail with an error message "... > because it's locked by an other process". > The error can't be reproduced on every machine but > frequently happens and usually doesn't disapear anymore > once occured. > > The locked file get's freed when the devenv process is > terminated (:-)). Currently I'm supporting a guy working > on a project where he has errors like that every time of > compilation and he's spending quite an amount of his time > shuting down and restarting the IDE. > > What's going on? What can we do? I mean it's a bug, a > pretty nasty one, not because it's so horrible, but > because it kills productivity and really hits the wallet. > > Does anyone have a solution for that problem or share > that experience? Is there an (educated) explanation for > it. > > It seems like te IDE has a resource leck when reflecting > the assemblies... > referenced by signed assemblies B and C (A, B and C were projects in the same solution). A was locked and also wasn't updated when recompilation was done, an old version was loaded. FB -- Solutions Design : http://www.sd.nl My open source .NET Software : http://www.sd.nl/software My .NET Blog : http://weblogs.asp.net/FBouma
[quoted text, click to view]
>The solution is to exit devenv and start over. Yea, maybe one can reproduce the behavior with two > >If that's taking too long, perhaps you could consider using smaller >solutions for day-to-day work? projects. You're right, anyway, it's causing much more pain with bigger soluions. [quoted text, click to view] > A solution for day-to-day work? .... not really. that's not an acceptable solution. rather I would write make files. One can simply turn off the compilation of all projects except those one is working on, but again, that's not the solution I'm looking for. anyway, thanks a lot I now understand nobody really knows a solution and everybody is kind of trying to work around the problem... being really happy since, indeed, it could be worse... rgards Christian [quoted text, click to view] >-----Original Message-----
>"Christian Kuendig" <*removethis*kuendigc@spectraweb.ch> wrote in message >news:025a01c36c0f$81c582a0$a501280a@phx.gbl... >> (IDE: VS2003 7.1.3088) >> >> Hi, >> >> When solutions grow and contain several projects (10, 20 >> or more) people complain that they can't compile their >> projects anymore. > >At least in VS.NET 2002, a large solution isn't required to cause this >problem. > >The solution is to exit devenv and start over. > >If that's taking too long, perhaps you could consider using smaller >solutions for day-to-day work? >-- >John Saunders >Internet Engineer >john.saunders@surfcontrol.com > > > >.
[quoted text, click to view]
"Christian Kuendig" <*removethis*kuendigc@spectraweb.ch> wrote in message news:0b3a01c36c95$18a1ce10$a401280a@phx.gbl... > > A solution for day-to-day work? > ... not really. that's not an acceptable solution. rather > I would write make files. One can simply turn off the > compilation of all projects except those one is working > on, but again, that's not the solution I'm looking for. I was talking about creating small, private solutions on-disk for short-term, special-purpose or day-to-day work. I do this by using File->New->Blank Solution, then adding to that solution just the projects I need to work on. This can create a much smaller solution which opens much faster. -- John Saunders Internet Engineer john.saunders@surfcontrol.com
Hello!
I hope someone from Microsoft reads this thread... This is a total disaster for the current project I'm working on now. After every compile we need to shut down VS, delete the dlls, start VS again and reopen the solution. As you can imagine it takes alot of our precious time and we do have a deadline to keep. We have tried everything, the latest framework, patches, new visual studio 2003. One colleague will try to reinstall windows and see if that helps (I doubt it). I've read alot about this problem and some say it's because the solution is to big (to many projects). I guess we could start splitting up the solution to many small ones but come on... This is suppose to be a professional develop enviroment. Can someone from M$ please come up with something better than uggly workarounds that doesn't work anyway ??? // Mikael "Christian Kuendig" <*removethis*kuendigc@spectraweb.ch> skrev i meddelandet news:025a01c36c0f$81c582a0$a501280a@phx.gbl... [quoted text, click to view] > (IDE: VS2003 7.1.3088) > > Hi, > > When solutions grow and contain several projects (10, 20 > or more) people complain that they can't compile their > projects anymore. > > Why? The IDE locks some dlls (assemblies from project > output) and doesn't free them anymore. Every attempt to > compile those solutions fail with an error message "... > because it's locked by an other process". > The error can't be reproduced on every machine but > frequently happens and usually doesn't disapear anymore > once occured. > > The locked file get's freed when the devenv process is > terminated (:-)). Currently I'm supporting a guy working > on a project where he has errors like that every time of > compilation and he's spending quite an amount of his time > shuting down and restarting the IDE. > > What's going on? What can we do? I mean it's a bug, a > pretty nasty one, not because it's so horrible, but > because it kills productivity and really hits the wallet. > > Does anyone have a solution for that problem or share > that experience? Is there an (educated) explanation for > it. > > It seems like te IDE has a resource leck when reflecting > the assemblies... > > Any comments appreciated > > thanks > > Christian Kuendig > .Net Competence Centre, HSR University, Switzerland
Hi Mikael,
We have this same problem with one of our projects, and our initial work-around was to break our single solution into a number of solutions (we're at five now). This however yielded only temporary relief. Our next try was to create our own build engine that compiled everything outside of the IDE (deletes the files, builds the VS solutions, then installs to the gac). This is reliable and gets around the lock up problem which for us was quite severe (simply starting VS and opening one of our solutions would lock our low-level DLLs until VS was closed down). However, I saw an interesting post about this elsewhere, and the auther claimed that the problem was caused by at least two strongly-named assemblies (one dependent on the other) and a third assembly that is dependent upon one of the other two. While we have not had time to research this, his suggestion has resonance with our situation. Our solution includes at least four strongly-named assemblies, and there is a dependent relationship among assemblies in within that group. I hope this information will be helpful. Best regards, Mark Miller - Developer Express
Don't see what you're looking for? Try a search.
|
June 2003
July 2003
August 2003
September 2003
October 2003
November 2003
December 2003
January 2004
February 2004
March 2004
April 2004
May 2004
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
| home · blog · groups | Questions? Comments? Contact the dn |