Author |
Message |
Thomas Olsso #1 / 11
|
 Project always rebuilt
I have at least two C++ projects in VS.NET that are always completely rebuilt at each compilation. If I select to compile again after a successful compilation, it will still compile all files again. Strangely enough, the same project on another computer, does not behave this way. I can see no difference in the configuration of the computers. On both computers I have VS.NET final version and then the latest Platform SDK installed on top of that. The project contains several IDL files, but I have made sure they are set not to produce a TLB file, since I know that this can cause the same problem in VC++ 6 when the IDL file does not contain any LIBRARY section. I have tried to delete all output files and checked all input files for invalid dates. In VC++6 you could see what dependencies that VS associated with each file. Can you do that in VS.NET? How can I troubleshoot this problem? /Thomas -- Thomas Olsson, Vinga System AB, Sweden http://www.*-*-*.com/ (Reply adress is invalid to avoid spam)
|
Tue, 09 Nov 2004 22:14:44 GMT |
|
 |
MSFT #2 / 11
|
 Project always rebuilt
Are you seeing the MIDL part of the build running again? If this is the case there is a known bug where if your IDL files are outside your project directory, but they include files that are in your project, the project will rebuild. You can fix this by adding the $(ProjectDir) to the MIDL "Additional Include Directories" property. This will also apply to RC building again and again. Let me know which tools is rebuilding again and again if this doesn't help. The two bugs noted above have been fixed for a future release. Brick This posting is provided "AS IS" with no warranties, and confers no rights. You assume all risk for your use. ? 2002 Microsoft Corporation. All rights reserved
Quote: > I have at least two C++ projects in VS.NET that are always completely > rebuilt at each compilation. If I select to compile again after a successful > compilation, it will still compile all files again. > Strangely enough, the same project on another computer, does not behave this > way. I can see no difference in the configuration of the computers. On both > computers I have VS.NET final version and then the latest Platform SDK > installed on top of that. > The project contains several IDL files, but I have made sure they are set > not to produce a TLB file, since I know that this can cause the same problem > in VC++ 6 when the IDL file does not contain any LIBRARY section. > I have tried to delete all output files and checked all input files for > invalid dates. > In VC++6 you could see what dependencies that VS associated with each file. > Can you do that in VS.NET? How can I troubleshoot this problem? > /Thomas > -- > Thomas Olsson, Vinga System AB, Sweden > http://www.vinga.se > (Reply adress is invalid to avoid spam)
|
Wed, 10 Nov 2004 01:54:50 GMT |
|
 |
James Wa #3 / 11
|
 Project always rebuilt
Hi, There is a new compiler swith /showincludes will show all the included header file for a .cpp file. Also the output file setting in the file properties would be the dependency file. You may also want to check to make sure none of the file data are in the future. A filemon log and build log may also help to find the problem. James This posting is provided "AS IS" with no warranties, and confers no rights
|
Wed, 10 Nov 2004 02:53:04 GMT |
|
 |
Thomas Olsso #4 / 11
|
 Project always rebuilt
Brick, Thank you for your reply. At first I thought that my problem did fit your description, but it did not. I have several projects with this problem. One of them has a more complex layout with dependencies between projects in different directories. Basically the layout is like this A B C D Projects B, C and D are dependenyt on A. This is also the directory layout (all on the same drive). The directory A includes some IDL files included by IDL files in B, C and D, but there is only one IDL file in each of B, C and D and those are not included by any IDL files in A. The MIDL settings for B, C and D have Additional Include Directories = ".,.." I have also tried with "$(ProjectDir), .." and "$(ProjectDir),$(ProjectDir)..". Strangely enough, only the project C is rebuilt over and over again. I can not see any obvious differences between B, C and D. What I see is that the IDL file is rebuild and then all of the C++ files in the project (they all include the .h file generated by the IDL). The res file is not rebuilt. I have also tried to compiling the IDL by using "Custom build", but it made no difference. Another project that is experiencing the same problem, consists of only a single project and a single directory. /Thomas -- Thomas Olsson, Vinga System AB, Sweden http://www.vinga.se (Reply adress is invalid to avoid spam)
Quote: > Are you seeing the MIDL part of the build running again? If this is the case > there is a known bug where if your IDL files are outside your project > directory, but they include files that are in your project, the project will > rebuild. You can fix this by adding the $(ProjectDir) to the MIDL > "Additional Include Directories" property. This will also apply to RC > building again and again. > Let me know which tools is rebuilding again and again if this doesn't help. > The two bugs noted above have been fixed for a future release. > Brick > This posting is provided "AS IS" with no warranties, and confers no rights. > You assume all risk for your use. ? 2002 Microsoft Corporation. All rights > reserved
> > I have at least two C++ projects in VS.NET that are always completely > > rebuilt at each compilation. If I select to compile again after a > successful > > compilation, it will still compile all files again. > > Strangely enough, the same project on another computer, does not behave > this > > way. I can see no difference in the configuration of the computers. On > both > > computers I have VS.NET final version and then the latest Platform SDK > > installed on top of that. > > The project contains several IDL files, but I have made sure they are set > > not to produce a TLB file, since I know that this can cause the same > problem > > in VC++ 6 when the IDL file does not contain any LIBRARY section. > > I have tried to delete all output files and checked all input files for > > invalid dates. > > In VC++6 you could see what dependencies that VS associated with each > file. > > Can you do that in VS.NET? How can I troubleshoot this problem? > > /Thomas > > -- > > Thomas Olsson, Vinga System AB, Sweden > > http://www.vinga.se > > (Reply adress is invalid to avoid spam)
|
Fri, 12 Nov 2004 14:53:44 GMT |
|
 |
MSFT #5 / 11
|
 Project always rebuilt
Looks like we are dealing with the IDL file from one project, C? When you look at the MIDL setting for project C are you looking at the File Level or the Project level settings? Some times the file levels settings have overwritten the project level settings. Just a quick check to be sure you setting the correct information for the IDL file. Select the IDL file in question and look at the properties on the file. If the property is Bolded, that means it has file level setting that is over writing the project level setting. Also, the IDL deps scanner is not smart enough to translate preprocessor lines like the compiler can for .cpp files. So, if you your IDL file has #includes that are #ifdef'd in your code the deps generator doesn't know that this file may or may not be included. If you have one of these cases in your code, you will either have to remove it (if it's not needed), place a dummy file that represents the file you are #including, or add the missing file to Sysincl.dat file (look under the help topics for Sysincl.dat and how to use this to speed up your deps scanning). Basically what is happening is if the #include file is not on your hard drive, the build engine will build .idl file again. As for the Custom Build step always firing. It doesn't use the same build scanner that the would be used if the IDL file is build in the project. This will just use the "Outputs" and "Additional Dependencies" to determine is something is to be built. I will need to see what you set for custom build step to make it fire. Was it a project level or file level custom build step? If none of this helps, maybe you can send me a copy of your .vcproj file, and the idl file that are causing you problems? Thanks Brick This posting is provided "AS IS" with no warranties, and confers no rights. You assume all risk for your use. ? 2002 Microsoft Corporation. All rights reserved
Quote: > Brick, > Thank you for your reply. At first I thought that my problem did fit your > description, but it did not. I have several projects with this problem. > One of them has a more complex layout with dependencies between projects in > different directories. Basically the layout is like this > A > B > C > D > Projects B, C and D are dependenyt on A. This is also the directory layout > (all on the same drive). The directory A includes some IDL files included by > IDL files in B, C and D, but there is only one IDL file in each of B, C and > D and those are not included by any IDL files in A. The MIDL settings for B, > C and D have Additional Include Directories = ".,.." I have also tried with > "$(ProjectDir), .." and "$(ProjectDir),$(ProjectDir)..". > Strangely enough, only the project C is rebuilt over and over again. I can > not see any obvious differences between B, C and D. > What I see is that the IDL file is rebuild and then all of the C++ files in > the project (they all include the .h file generated by the IDL). The res > file is not rebuilt. > I have also tried to compiling the IDL by using "Custom build", but it made > no difference. > Another project that is experiencing the same problem, consists of only a > single project and a single directory. > /Thomas > -- > Thomas Olsson, Vinga System AB, Sweden > http://www.vinga.se > (Reply adress is invalid to avoid spam)
> > Are you seeing the MIDL part of the build running again? If this is the > case > > there is a known bug where if your IDL files are outside your project > > directory, but they include files that are in your project, the project > will > > rebuild. You can fix this by adding the $(ProjectDir) to the MIDL > > "Additional Include Directories" property. This will also apply to RC > > building again and again. > > Let me know which tools is rebuilding again and again if this doesn't > help. > > The two bugs noted above have been fixed for a future release. > > Brick > > This posting is provided "AS IS" with no warranties, and confers no > rights. > > You assume all risk for your use. ? 2002 Microsoft Corporation. All rights > > reserved
> > > I have at least two C++ projects in VS.NET that are always completely > > > rebuilt at each compilation. If I select to compile again after a > > successful > > > compilation, it will still compile all files again. > > > Strangely enough, the same project on another computer, does not behave > > this > > > way. I can see no difference in the configuration of the computers. On > > both > > > computers I have VS.NET final version and then the latest Platform SDK > > > installed on top of that. > > > The project contains several IDL files, but I have made sure they are > set > > > not to produce a TLB file, since I know that this can cause the same > > problem > > > in VC++ 6 when the IDL file does not contain any LIBRARY section. > > > I have tried to delete all output files and checked all input files for > > > invalid dates. > > > In VC++6 you could see what dependencies that VS associated with each > > file. > > > Can you do that in VS.NET? How can I troubleshoot this problem? > > > /Thomas > > > -- > > > Thomas Olsson, Vinga System AB, Sweden > > > http://www.vinga.se > > > (Reply adress is invalid to avoid spam)
|
Sun, 14 Nov 2004 02:19:42 GMT |
|
 |
Thomas Olsso #6 / 11
|
 Project always rebuilt
See inline below. -- Thomas Olsson, Vinga System AB, Sweden http://www.vinga.se (Reply adress is invalid to avoid spam)
Quote: > Looks like we are dealing with the IDL file from one project, C? > When you look at the MIDL setting for project C are you looking at the File > Level or the Project level settings? Some times the file levels settings > have overwritten the project level settings. Just a quick check to be sure > you setting the correct information for the IDL file. Select the IDL file in > question and look at the properties on the file. If the property is Bolded, > that means it has file level setting that is over writing the project level > setting.
I have double checked this. I have also looked at the command line output in the settings to verify that everything look OK. Quote: > Also, the IDL deps scanner is not smart enough to translate preprocessor > lines like the compiler can for .cpp files. So, if you your IDL file has > #includes that are #ifdef'd in your code the deps generator doesn't know > that this file may or may not be included. If you have one of these cases in > your code, you will either have to remove it (if it's not needed), place a > dummy file that represents the file you are #including, or add the missing > file to Sysincl.dat file (look under the help topics for Sysincl.dat and how > to use this to speed up your deps scanning). Basically what is happening is > if the #include file is not on your hard drive, the build engine will build > .idl file again.
No #ifdefs in our files. Quote: > As for the Custom Build step always firing. It doesn't use the same build > scanner that the would be used if the IDL file is build in the project. This > will just use the "Outputs" and "Additional Dependencies" to determine is > something is to be built. I will need to see what you set for custom build > step to make it fire. Was it a project level or file level custom build > step?
I did the changes on the file level and used a command line like midl.exe /nologo /env win32 /notlb /h "a.h" /iid "a_i.c" "a.idl" with dependencies set to a.idl and outputs to a.h and a_i.c For the one and only IDL file that produce a TLB I used midl.exe /nologo /env win32 /tlb "b.tlb" /h "b.h" /iid "b_i.c" "b.idl" with dependencies set to b.idl and outputs to b.h, b.tlb and b_i.c Quote: > If none of this helps, maybe you can send me a copy of your .vcproj file, > and the idl file that are causing you problems?
Please note that we only have this problem on two out of five computers. Exactly the same project works on some computers and does not work on others. I can not find any difference in what programs we have installed. (Visual Studio.NET + latest MS Platform SDK on Windows XP Prof.) I will send you a copy. Thank you for your help and suggestions so far. -- Thomas Olsson, Vinga System AB, Sweden http://www.vinga.se (Reply adress is invalid to avoid spam)
|
Sun, 14 Nov 2004 14:59:33 GMT |
|
 |
MSFT #7 / 11
|
 Project always rebuilt
Follow Up: The issue was related to the installation of a PSDK kit. The folder where the PSDK was installed to had to be added to the Sysincl.dat file to tell the build engine this it should ignore scanning this folder for additional includes. Failing to do so will slow down the build deps check and potentially cause rebuilds since the build deps engine can get confused with #ifdef's around #includes. See VS7 help topic for how to use Sysincl.dat ms-help://MS.VSCC/MS.MSDNVS/vccore/html/_core_Excluding_Files_When_Dependenc y_Checking.htm Brick This posting is provided "AS IS" with no warranties, and confers no rights. You assume all risk for your use. ? 2002 Microsoft Corporation. All rights reserved
Quote: > See inline below. > -- > Thomas Olsson, Vinga System AB, Sweden > http://www.vinga.se > (Reply adress is invalid to avoid spam)
> > Looks like we are dealing with the IDL file from one project, C? > > When you look at the MIDL setting for project C are you looking at the > File > > Level or the Project level settings? Some times the file levels settings > > have overwritten the project level settings. Just a quick check to be sure > > you setting the correct information for the IDL file. Select the IDL file > in > > question and look at the properties on the file. If the property is > Bolded, > > that means it has file level setting that is over writing the project > level > > setting. > I have double checked this. I have also looked at the command line output in > the settings to verify that everything look OK. > > Also, the IDL deps scanner is not smart enough to translate preprocessor > > lines like the compiler can for .cpp files. So, if you your IDL file has > > #includes that are #ifdef'd in your code the deps generator doesn't know > > that this file may or may not be included. If you have one of these cases > in > > your code, you will either have to remove it (if it's not needed), place a > > dummy file that represents the file you are #including, or add the missing > > file to Sysincl.dat file (look under the help topics for Sysincl.dat and > how > > to use this to speed up your deps scanning). Basically what is happening > is > > if the #include file is not on your hard drive, the build engine will > build > > .idl file again. > No #ifdefs in our files. > > As for the Custom Build step always firing. It doesn't use the same build > > scanner that the would be used if the IDL file is build in the project. > This > > will just use the "Outputs" and "Additional Dependencies" to determine is > > something is to be built. I will need to see what you set for custom build > > step to make it fire. Was it a project level or file level custom build > > step? > I did the changes on the file level and used a command line like > midl.exe /nologo /env win32 /notlb /h "a.h" /iid "a_i.c" "a.idl" with > dependencies set to a.idl and outputs to a.h and a_i.c > For the one and only IDL file that produce a TLB I used > midl.exe /nologo /env win32 /tlb "b.tlb" /h "b.h" /iid "b_i.c" "b.idl" with > dependencies set to b.idl and outputs to b.h, b.tlb and b_i.c > > If none of this helps, maybe you can send me a copy of your .vcproj file, > > and the idl file that are causing you problems? > Please note that we only have this problem on two out of five computers. > Exactly the same project works on some computers and does not work on > others. I can not find any difference in what programs we have installed. > (Visual Studio.NET + latest MS Platform SDK on Windows XP Prof.) > I will send you a copy. Thank you for your help and suggestions so far. > -- > Thomas Olsson, Vinga System AB, Sweden > http://www.vinga.se > (Reply adress is invalid to avoid spam)
|
Mon, 15 Nov 2004 05:01:04 GMT |
|
 |
Thomas Olsso #8 / 11
|
 Project always rebuilt
The topic refered to by Brick can also be found at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vcco... My theory is that there are references in the latest Platform SDK to files that do not exist any longer and this makes the dependency checker i VS.NET confused. /Thomas -- Thomas Olsson, Vinga System AB, Sweden http://www.vinga.se (Reply adress is invalid to avoid spam)
Quote: > Follow Up: > The issue was related to the installation of a PSDK kit. The folder where > the PSDK was installed to had to be added to the Sysincl.dat file to tell > the build engine this it should ignore scanning this folder for additional > includes. Failing to do so will slow down the build deps check and > potentially cause rebuilds since the build deps engine can get confused with > #ifdef's around #includes. > See VS7 help topic for how to use Sysincl.dat
ms-help://MS.VSCC/MS.MSDNVS/vccore/html/_core_Excluding_Files_When_Dependen c Quote: > y_Checking.htm > Brick > This posting is provided "AS IS" with no warranties, and confers no rights. > You assume all risk for your use. ? 2002 Microsoft Corporation. All rights > reserved
> > See inline below. > > -- > > Thomas Olsson, Vinga System AB, Sweden > > http://www.vinga.se > > (Reply adress is invalid to avoid spam)
> > > Looks like we are dealing with the IDL file from one project, C? > > > When you look at the MIDL setting for project C are you looking at the > > File > > > Level or the Project level settings? Some times the file levels settings > > > have overwritten the project level settings. Just a quick check to be > sure > > > you setting the correct information for the IDL file. Select the IDL > file > > in > > > question and look at the properties on the file. If the property is > > Bolded, > > > that means it has file level setting that is over writing the project > > level > > > setting. > > I have double checked this. I have also looked at the command line output > in > > the settings to verify that everything look OK. > > > Also, the IDL deps scanner is not smart enough to translate preprocessor > > > lines like the compiler can for .cpp files. So, if you your IDL file has > > > #includes that are #ifdef'd in your code the deps generator doesn't know > > > that this file may or may not be included. If you have one of these > cases > > in > > > your code, you will either have to remove it (if it's not needed), place > a > > > dummy file that represents the file you are #including, or add the > missing > > > file to Sysincl.dat file (look under the help topics for Sysincl.dat and > > how > > > to use this to speed up your deps scanning). Basically what is happening > > is > > > if the #include file is not on your hard drive, the build engine will > > build > > > .idl file again. > > No #ifdefs in our files. > > > As for the Custom Build step always firing. It doesn't use the same > build > > > scanner that the would be used if the IDL file is build in the project. > > This > > > will just use the "Outputs" and "Additional Dependencies" to determine > is > > > something is to be built. I will need to see what you set for custom > build > > > step to make it fire. Was it a project level or file level custom build > > > step? > > I did the changes on the file level and used a command line like > > midl.exe /nologo /env win32 /notlb /h "a.h" /iid "a_i.c" "a.idl" with > > dependencies set to a.idl and outputs to a.h and a_i.c > > For the one and only IDL file that produce a TLB I used > > midl.exe /nologo /env win32 /tlb "b.tlb" /h "b.h" /iid "b_i.c" "b.idl" > with > > dependencies set to b.idl and outputs to b.h, b.tlb and b_i.c > > > If none of this helps, maybe you can send me a copy of your .vcproj > file, > > > and the idl file that are causing you problems? > > Please note that we only have this problem on two out of five computers. > > Exactly the same project works on some computers and does not work on > > others. I can not find any difference in what programs we have installed. > > (Visual Studio.NET + latest MS Platform SDK on Windows XP Prof.) > > I will send you a copy. Thank you for your help and suggestions so far. > > -- > > Thomas Olsson, Vinga System AB, Sweden > > http://www.vinga.se > > (Reply adress is invalid to avoid spam)
|
Mon, 15 Nov 2004 15:15:34 GMT |
|
 |
David Lownde #9 / 11
|
 Project always rebuilt
Quote: >..since the build deps engine can get confused with >#ifdef's around #includes.
Brick, Is this issue going to be fixed for the "7.1" release? Dave -- MVP VC++ FAQ: http://www.mvps.org/vcfaq My address is altered to discourage junk mail. Please post responses to the newsgroup thread, there's no need for follow-up email copies.
|
Tue, 16 Nov 2004 19:51:22 GMT |
|
 |
MSFT #10 / 11
|
 Project always rebuilt
You know we can't make promises on future shipping versions. I think for this case, it wont be addressed in the next version. This is just a limitation of dep scanning files not pushed to the CL tool. The sysincl.dat file is perfect for deps exclusion. Used properly, it can speed up build times too. Brick This posting is provided "AS IS" with no warranties, and confers no rights. You assume all risk for your use. ? 2002 Microsoft Corporation. All rights reserved
Quote: > >..since the build deps engine can get confused with > >#ifdef's around #includes. > Brick, > Is this issue going to be fixed for the "7.1" release? > Dave > -- > MVP VC++ FAQ: http://www.mvps.org/vcfaq > My address is altered to discourage junk mail. > Please post responses to the newsgroup thread, > there's no need for follow-up email copies.
|
Wed, 17 Nov 2004 02:13:08 GMT |
|
 |
David Lownde #11 / 11
|
 Project always rebuilt
Quote: >You know we can't make promises on future shipping versions. I think for >this case, it wont be addressed in the next version. This is just a >limitation of dep scanning files not pushed to the CL tool.
But in this situation we're talking about unnecessary rebuild problems that a lot of people (me included) are seeing all the time. Your prior post indicated that there really was a problem rather than using this facility as a useful convenience - surely something needs fixing? Dave -- MVP VC++ FAQ: http://www.mvps.org/vcfaq My address is altered to discourage junk mail. Please post responses to the newsgroup thread, there's no need for follow-up email copies.
|
Wed, 17 Nov 2004 06:10:07 GMT |
|
|
|