> 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)

> 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)

> 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)

> 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?

> 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)

> 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

> 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)

>..since the build deps engine can get confused with
>#ifdef's around #includes.

> >..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.

>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.