This VC# bug is killing me - please help somebody!
-
I am currently working on a .NET project with over 40 projects in the solution and due to the dependencies each developer needs access/reference to at least 3 assemblies (most of them over 80 KB). To make other tools, testing, documentations, sample codes etc easier to handle, I had to build all this project to a common output and this VC# bug - Q313512[^], is killing me. I requested the guy in charge of the my company's MSDN subscription to enquire for hotfix (QFE), but MS is claiming we had to pay an equivalent of $350 just to enquire the presense of a hotfix, a so-called support instance. We sent an email. My company is not willing to pay this amount and I had to suffer for an acknowleged bug - closing my solutions and then re-opening each time to effect a rebuild. Please help. How are you guys using this VS.NET productively? (to me it is more of a headache than a solution) :(( Best regards, Paul. Jesus Christ is LOVE! Please tell somebody.
This problem may occur when one of the assemblies that you compile is larger than 64 kilobytes (KB) Reminds me of something.... -------- "I say no to drugs, but they don't listen." - Marilyn Manson
-
This problem may occur when one of the assemblies that you compile is larger than 64 kilobytes (KB) Reminds me of something.... -------- "I say no to drugs, but they don't listen." - Marilyn Manson
Yeah. DOS. Marc Microsoft MVP, Visual C# MyXaml MyXaml Blog
-
I am currently working on a .NET project with over 40 projects in the solution and due to the dependencies each developer needs access/reference to at least 3 assemblies (most of them over 80 KB). To make other tools, testing, documentations, sample codes etc easier to handle, I had to build all this project to a common output and this VC# bug - Q313512[^], is killing me. I requested the guy in charge of the my company's MSDN subscription to enquire for hotfix (QFE), but MS is claiming we had to pay an equivalent of $350 just to enquire the presense of a hotfix, a so-called support instance. We sent an email. My company is not willing to pay this amount and I had to suffer for an acknowleged bug - closing my solutions and then re-opening each time to effect a rebuild. Please help. How are you guys using this VS.NET productively? (to me it is more of a headache than a solution) :(( Best regards, Paul. Jesus Christ is LOVE! Please tell somebody.
What about NAnt or other command line build tools? hehe. Try SharpDevelop! Marc Microsoft MVP, Visual C# MyXaml MyXaml Blog
-
Yeah. DOS. Marc Microsoft MVP, Visual C# MyXaml MyXaml Blog
-
This problem may occur when one of the assemblies that you compile is larger than 64 kilobytes (KB) Reminds me of something.... -------- "I say no to drugs, but they don't listen." - Marilyn Manson
Michel Prévost wrote: Reminds me of something.... Of what? hope you are not too old :) Best regards, Paul. Jesus Christ is LOVE! Please tell somebody.
-
Marc Clifton wrote: Yeah. DOS. Marc You mean, Windows 98. Sometimes I feel like I'm a USB printer in a parallel universe.
-
What about NAnt or other command line build tools? hehe. Try SharpDevelop! Marc Microsoft MVP, Visual C# MyXaml MyXaml Blog
Marc Clifton wrote: What about NAnt or other command line build tools? You have a point, I have never considered NAnt. Marc Clifton wrote: hehe. Try SharpDevelop! Is there MyXaml version? Best regards, Paul. Jesus Christ is LOVE! Please tell somebody.
-
Paul Selormey wrote: I am currently working on a .NET project with over 40 projects I have a solution with 178 projects, C++, C#, VB.NET, some of them ASP.NET based. On a super-duper machine, this takes almost 2 minutes to open. Paul Selormey wrote: To make other tools, testing, documentations, sample codes etc easier to handle, I had to build all this project to a common output Error #1: On VS.NET you have to build to the default directories, or you'll have trouble. You're confusing “build” with “deploy”. Use Copy Local=true, copy everything to their own directories in the way VS.NET likes it, then have some post-build action, e.g, a batch file that copies the files to the proper directories. Probably this won't be a huge problem: I don't believe your 3 common DLLs don't change so often; at least not to the point that people need to recompile them all the time. If they are so used, their interface can't change so often or people wouldn't be able to work properly, am I right? The opposite would mean some design mistake, and usually can be easily fixed. If I am right, why don't you break it on 2 separate solutions? Paul Selormey wrote: How are you guys using this VS.NET productively? (to me it is more of a headache than a solution) Xtreme Programming has the answer: Continuous integration; you need to rebuild often, from the sources on a separate machine. The deployment is also done by this machine. All of this without human intervention. This way people work on smaller projects. No one needs to work on a 178 project-solution all the time - it's not productive. What we do is working on smaller (5 ~ 10 projects) solutions that include a unit testing project and a few class libraries being tested. This is repeated two or three times, until the new feature is integrated on the software. Each CVS checkin, after a 5 minute delay, triggers a build on the build machine. Our 'full' solution is only used to generate some NAnt scripts that build our software, so we only need to open it to add more projects. [disclaimer]I only answered it on the Lounge because this is a 'boundary question': I really don't know if this should be tagged as a programming question or not[/disclaimer] No programming questions at The Lounge - Please tell somebody Due to technical difficulties my previous signature, "I see dumb people" will be off until further notice. Too many people were thinking I was talking about them... :s
Daniel Turini wrote: No programming questions at The Lounge - Please tell somebody Good one! :laugh: --Mike-- Personal stuff:: Ericahist | Homepage Shareware stuff:: 1ClickPicGrabber | RightClick-Encrypt CP stuff:: CP SearchBar v2.0.2 | C++ Forum FAQ ---- Laugh it up, fuzzball.
-
I am currently working on a .NET project with over 40 projects in the solution and due to the dependencies each developer needs access/reference to at least 3 assemblies (most of them over 80 KB). To make other tools, testing, documentations, sample codes etc easier to handle, I had to build all this project to a common output and this VC# bug - Q313512[^], is killing me. I requested the guy in charge of the my company's MSDN subscription to enquire for hotfix (QFE), but MS is claiming we had to pay an equivalent of $350 just to enquire the presense of a hotfix, a so-called support instance. We sent an email. My company is not willing to pay this amount and I had to suffer for an acknowleged bug - closing my solutions and then re-opening each time to effect a rebuild. Please help. How are you guys using this VS.NET productively? (to me it is more of a headache than a solution) :(( Best regards, Paul. Jesus Christ is LOVE! Please tell somebody.
So long as MS acknowledges that the problem is due to a bug (given that it has published the KB article, this just means you need to convince them that you have encountered the situation described there) you will get a refund. If you pay for it as a one-off then I don't know whether you get the money back or whether you get the next support call free.
-
:sigh: You misread my entire post! :doh: Let's go: 1. You have some DLLs that need to be on specific directories after the build of a project, but before the build of another. You can't generate them on those directories because of a VS.NET bug. What do you do? Generate on a temporary directory and move them. 2. You said people do not need to recompile them often; move them to another solution, and build them manually. Paul Selormey wrote: This bug has nothing to do with 178 projects-solution. You only need an assembly which is more than 60 KB to get into this problem. You can work on 2000 projects, if none is more than 60 KB you do not have the problem. No, this bug has to do with poor planning on the build process: if you're referencing projects, your solution should contain projects that generate DLLs. If you're referencing DLLs, your solution should contain those DLLs. Sorry, I can't explain it simpler than that. Due to technical difficulties my previous signature, "I see dumb people" will be off until further notice. Too many people were thinking I was talking about them... :sigh:
I have experienced the exact same problem with assemblies getting larger than 60KB. Very crappy.
-
Doesn't matter anyway... I have a (large) solution with all binaries outputting to the correct folders and Copy Local set correctly etc etc and all the other conditions being correct I STILL get the error occasionally... ----------------------------------------------------------------------- Shaun Austin: .NET Specialist. Spreading the word of .NET to the world... well the UK... well my tiny corner of it!! :-D
Not quite sure why that last comment deserved a "1" vote... it's just a statement of fact! ----------------------------------------------------------------------- Shaun Austin: .NET Specialist. Spreading the word of .NET to the world... well the UK... well my tiny corner of it!! :-D