Managed C++ projects always rebuild

[Pinnguy]

Hello, I have started to use managed C++ in VS 2003. I have several .NET
class libraries written in MC++.

I am finding the rebuild tendencies in VS to be very annoying. If I make a
minor change to a C++ file (not header), it causes all depend projects to
rebuild. I have not changed any classes or interfaces; I only make a minor
change to some code in a cpp file.

I would expect all depend files to rebuild if I change a class header file,
but I do not expect **all depend projects** to rebuild if I make a minor
change to some cpp code.

I can live with this behavior for now, but once I have a large system, I can
see that this will become quite a burden.

Is there anyway to stop/work-around this behavior. Is it fixed in VS 2005?

Thanks

[Mikhail Arkhipov (Microsoft)]

On 10/26/05 8:36, in article
89**********************************@microsoft.com, "Pinnguy"
<pi*****@noemail.noemail> wrote:

Hello, I have started to use managed C++ in VS 2003. I have several .NET
class libraries written in MC++.

I am finding the rebuild tendencies in VS to be very annoying. If I make a
minor change to a C++ file (not header), it causes all depend projects to
rebuild. I have not changed any classes or interfaces; I only make a minor
change to some code in a cpp file.

I would expect all depend files to rebuild if I change a class header file,
but I do not expect **all depend projects** to rebuild if I make a minor
change to some cpp code.

I can live with this behavior for now, but once I have a large system, I can
see that this will become quite a burden.

Is there anyway to stop/work-around this behavior. Is it fixed in VS 2005?

Thanks

Since managed code does not use headers (only managed C++ keeps the
concept), dependent projects consume resulting assemblies as source of
information on the primary project classes and interfaces. Therefore, if
primary assembly changes, dependent projects have to be compiled again in
order to verify if they still use correct types and method signatures.
Fortunately, compilation of managed code is way faster than native C++
compilation.
Thanks
Mikhail Arkhipov (Microsoft)
-- This post is provided 'AS IS' with no warranties and confers no rights

[Pinnguy]

"Mikhail Arkhipov (Microsoft)" wrote:

On 10/26/05 8:36, in article
89**********************************@microsoft.com, "Pinnguy"
<pi*****@noemail.noemail> wrote:

Hello, I have started to use managed C++ in VS 2003. I have several .NET
class libraries written in MC++.

I am finding the rebuild tendencies in VS to be very annoying. If I make a
minor change to a C++ file (not header), it causes all depend projects to
rebuild. I have not changed any classes or interfaces; I only make a minor
change to some code in a cpp file.

I would expect all depend files to rebuild if I change a class header file,
but I do not expect **all depend projects** to rebuild if I make a minor
change to some cpp code.

I can live with this behavior for now, but once I have a large system, I can
see that this will become quite a burden.

Is there anyway to stop/work-around this behavior. Is it fixed in VS 2005?

Thanks

Since managed code does not use headers (only managed C++ keeps the
concept), dependent projects consume resulting assemblies as source of
information on the primary project classes and interfaces. Therefore, if
primary assembly changes, dependent projects have to be compiled again in
order to verify if they still use correct types and method signatures.
Fortunately, compilation of managed code is way faster than native C++
compilation.
Thanks
Mikhail Arkhipov (Microsoft)
-- This post is provided 'AS IS' with no warranties and confers no rights

Thanks for your fast response. I suspected that this was the cause of the
behavoir.

To work around this, what if I where to adopt more of a COM approach where I
have a strong separation between interface and implementation.

I could declare my base interfaces in a separate assembly that only provided
the interface decls. Then I could remove the dependancies on the assemblies
that implement the interfaces. Dependant projects would reference the
assembly with the interface decls, not the assemblies that implement the
interfaces. This should stop the compile time dependencies, Correct?