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.
-
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.
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
-
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: 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 ... supposed to be in "Visual Studio IDE" forum. :~ Maxwell Chen
-
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: Error #1: On VS.NET you have to build to the default directories, or you'll have trouble. You're confusing “build” with “deploy”. This is the bug. It is not a problem with MFC/ATL/C++ or MC++, it is VC# specific. There is no confusion of "build" and "deploy" here. Daniel Turini wrote: 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. I think you are just repeating the content of the link I have provide. There is no 3 common dll, I said at least three and they do change just too often - even with non-programming task as documentations. You do not need to recompile each time to get this bug, but is what the VC# will authomatically do. Daniel Turini wrote: Xtreme Programming has the answer: Continuous integration; you need to rebuild often, from the sources on a separate machine. I wish you gave my post a little more thought! this is a company not willing to spare $350 for bug support, how much more separate machines. The X stuff is a theory and does not apply to many cases. Daniel Turini wrote: This way people work on smaller projects. No one needs to work on a 178 project-solution all the time - it's not productive. 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. For our work, the very core (common) is currently 68 KB. Best regards, Paul. Jesus Christ is LOVE! Please tell somebody.
-
Daniel Turini wrote: 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 ... supposed to be in "Visual Studio IDE" forum. :~ Maxwell Chen
Maxwell Chen wrote: ... supposed to be in "Visual Studio IDE" forum. Tried there, you can check. Best regards, Paul. Jesus Christ is LOVE! Please tell somebody.
-
Daniel Turini wrote: Error #1: On VS.NET you have to build to the default directories, or you'll have trouble. You're confusing “build” with “deploy”. This is the bug. It is not a problem with MFC/ATL/C++ or MC++, it is VC# specific. There is no confusion of "build" and "deploy" here. Daniel Turini wrote: 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. I think you are just repeating the content of the link I have provide. There is no 3 common dll, I said at least three and they do change just too often - even with non-programming task as documentations. You do not need to recompile each time to get this bug, but is what the VC# will authomatically do. Daniel Turini wrote: Xtreme Programming has the answer: Continuous integration; you need to rebuild often, from the sources on a separate machine. I wish you gave my post a little more thought! this is a company not willing to spare $350 for bug support, how much more separate machines. The X stuff is a theory and does not apply to many cases. Daniel Turini wrote: This way people work on smaller projects. No one needs to work on a 178 project-solution all the time - it's not productive. 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. For our work, the very core (common) is currently 68 KB. Best regards, Paul. Jesus Christ is LOVE! Please tell somebody.
: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:
-
Maxwell Chen wrote: ... supposed to be in "Visual Studio IDE" forum. Tried there, you can check. Best regards, Paul. Jesus Christ is LOVE! Please tell somebody.
:-D Maxwell Chen
-
: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:
Daniel Turini wrote: This bug has nothing to do with 178 projects-solution. I guess that Paul was trying to say:
If it's a bug of VC#, MS shouldn't charge $350 ...
Maxwell Chen
-
Daniel Turini wrote: This bug has nothing to do with 178 projects-solution. I guess that Paul was trying to say:
If it's a bug of VC#, MS shouldn't charge $350 ...
Maxwell Chen
Maxwell Chen wrote: If it's a bug of VC#, MS shouldn't charge $350 ... Seriously, I work with MS for quite a long time. Every time the problem was caused by MS, I did not pay a single cent to get a QFE. I reported bugs, got SQL Server 2000 and VB6 QFEs that later appeared on service packs. Ok, I was patient and went through several support levels ('are you sure your query should return this, sir?') until I talked someone who really understood me (it was a SUM() bug: if the query plan used a MERGE JOIN, the sum was wrong; if the query plan used a HASH JOIN, the sum was right). Maybe in this case, as he's using a non-recommended practice, MS sees it as a misuse, not a bug and wants to charge him. 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:
-
: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:
Daniel Turini wrote: You misread my entire post! Sorry. Let me follow more closely then... Daniel Turini wrote: 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. I understand. I work with very small team, this being the first VS.NET project for all. So, I have to configure everything, and generate all the projects configure them for them to simple code in. This configuration involves many tools, NDoc, NUnit, FxCop etc and since I code most of them as well as manage this stuff, I had to make such I get the most common configuration for all to work with. So, you pick a project and it already has an NDoc, NUnit projects configured and ready to go. In fact, VS.NET bugs seems to show here in there in most of this configurations. Even handling of the relative path in xml doc tag is a problem - it depends on how you start the VS.NET. Also, to make sure all the documentations links work correctly, I need this to not touch approach to save more time to code myself - so my headache!!! Daniel Turini wrote: 2. You said people do not need to recompile them often; move them to another solution, and build them manually. The opposite, they have to. We are "coding" even all documentations, in a bit complex manner to handle internationalization - currently just Japanese and English. Being the first time, they have to see the out of even NDoc often to make they are doing all things right including links. Daniel Turini wrote: No, this bug has to do with poor planning on the build process: Being the project leader, I will accept it. But still do not forget, not all solutions or theories applies to all situation. I wish I have the ideal team too. Daniel Turini wrote: if you're referencing projects, your solution should contain projects that generate DLLs. If you're referencing DLLs, your solution should contain those DLLs. I do not understand what you mean here, I am referencing projects anyway, which makes things easy. Each member creates his/her own solution and check out only the projects to work on and could quickly see (by the yellow mark) the missing dependency. Daniel Turini wrote: Sorry, I can't ex
-
Daniel Turini wrote: You misread my entire post! Sorry. Let me follow more closely then... Daniel Turini wrote: 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. I understand. I work with very small team, this being the first VS.NET project for all. So, I have to configure everything, and generate all the projects configure them for them to simple code in. This configuration involves many tools, NDoc, NUnit, FxCop etc and since I code most of them as well as manage this stuff, I had to make such I get the most common configuration for all to work with. So, you pick a project and it already has an NDoc, NUnit projects configured and ready to go. In fact, VS.NET bugs seems to show here in there in most of this configurations. Even handling of the relative path in xml doc tag is a problem - it depends on how you start the VS.NET. Also, to make sure all the documentations links work correctly, I need this to not touch approach to save more time to code myself - so my headache!!! Daniel Turini wrote: 2. You said people do not need to recompile them often; move them to another solution, and build them manually. The opposite, they have to. We are "coding" even all documentations, in a bit complex manner to handle internationalization - currently just Japanese and English. Being the first time, they have to see the out of even NDoc often to make they are doing all things right including links. Daniel Turini wrote: No, this bug has to do with poor planning on the build process: Being the project leader, I will accept it. But still do not forget, not all solutions or theories applies to all situation. I wish I have the ideal team too. Daniel Turini wrote: if you're referencing projects, your solution should contain projects that generate DLLs. If you're referencing DLLs, your solution should contain those DLLs. I do not understand what you mean here, I am referencing projects anyway, which makes things easy. Each member creates his/her own solution and check out only the projects to work on and could quickly see (by the yellow mark) the missing dependency. Daniel Turini wrote: Sorry, I can't ex
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
-
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
Then there is more to the bug. Best regards, Paul. Jesus Christ is LOVE! Please tell 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.