Project always rebuilt 
Author Message
 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  
 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  
 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  
 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  
 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  
 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  
 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  
 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_Dependenc
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  
 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  
 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  
 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  
 
 [ 11 post ] 

 Relevant Pages 

1. Q:Why my project always rebuild

2. VC7 project always out-of-date, always rebuilds all

3. Rebuild, Rebuild, Rebuild

4. VC7 - why is the DLL always rebuild

5. IDL File always rebuilt

6. VC7 always does rebuild all

7. VC 6.0 always rebuild

8. VS 6.0 always rebuild

9. I always have to rebuild the .tlb file ?

10. VC 6.0 always rebuild

11. VS 6.0 always rebuild

12. BUILD command always REBUILDs in VC++ 5.0

 

 
Powered by phpBB® Forum Software