Forced 7.1 upgrade, now everyone hates me

[Rudy Ray Moore]

I forced everyone upgrade to MSVC 7.1/.net/2003 from MSVC6. Now my coworkers
hate me! I try to explain that VC has better template support, but they are
still very angry.

What can I do to make my coworkers enjoy VC7.1/.net/2003 more and not want
to kill me?

Believe me when I say it is very frusterating. It seems like the IDE is
working against us! And I'm the 7.1 proponent!

Here's a list of complaints from my 10 person team:

===

Microsoft Visual C++ .net 2003 7.1 (VC) takes a long time to load
multi-project workspaces (15 seconds). Much longer than MSVC6.0

While VC loads the project, my hard drive clicks away like I've never heard
it click before. Is this okay for my hard drive? Why does it do this?

While VC loads the project, my computer does not respond. This did not
happen with MSVC6.

Linking with VC is much slower than than with Microsoft Visual c++ 6.0.
Actually, MUCH MUCH slower.

Deciding which projects contain modified source and need to be recompiled:
much slower than than with Microsoft Visual c++ 6.0. Actually MUCH MUCH
slower.

Starting my exe in the debugger: much slower than than with Microsoft Visual
c++ 6.0. The hard drive goes crazy and my system does not respond.

Sometimes (often) the editor stops responding when compiling, launching exe
in debugger, etc. I cannot even scroll when this happens. Didn't happen in
VC6.

dockable windows

GUIDS in the .sln

Find window that doesn't go away

F4 doesn't go to next error with all the template backtrace (worked fine in
MSVC6)

F4 doesn't go to next match in "search results" (worked fine in MSVC6)

Thick dockable window boundaries that chop off valuable pixels of debugging
info.

I feel like I'm trapped in the IDE!

Launching a macro for the first time causes computer to stop responding for
about 5 seconds. And I have a fast computer! What in the world is MSVC7.1
doing?

 

[Julie]

I forced everyone upgrade to MSVC 7.1/.net/2003 from MSVC6. Now my coworkers
hate me! I try to explain that VC has better template support, but they are
still very angry.

What can I do to make my coworkers enjoy VC7.1/.net/2003 more and not want
to kill me?

VS.NET (either version) is virtually worthless for C++ projects for the reasons
that you outline, and others, unless you are using an external IDE/editor, and
just using the command line compiler. VS.NET is heavily targeted to .NET
languages (C#, VB.NET).

I'd recommend continuing w/ MSVC6 for C++ projects *unless* you have a
*business critical* reason for VS.NET.

Look at it this way, the first release of VS.NET was an alpha, VS.NET 03 is a
beta, and who know what VS.NET 05 will be (or when).

After 13 revs, MS still hasn't figured out how to release a compatible and
workable product that preserves the previous version's stability and
compatibility (and yes, I've been using this product line since its beginnings
in Lattice C).

Believe me when I say it is very frusterating. It seems like the IDE is
working against us! And I'm the 7.1 proponent!

Here's a list of complaints from my 10 person team:

===

Microsoft Visual C++ .net 2003 7.1 (VC) takes a long time to load
multi-project workspaces (15 seconds). Much longer than MSVC6.0
Yes.


While VC loads the project, my hard drive clicks away like I've never heard
it click before. Is this okay for my hard drive? Why does it do this?

Probably not good for the drive -- clicks aren't generally a good sound.
Anyone else's machine do this? Run a thorough surface/sector scan on your
drive lately?

While VC loads the project, my computer does not respond. This did not
happen with MSVC6.

VS.NET is a resource hog. If you want to do anything else in the meantime, get
a dual-processor system. Enabling hyperthreading (if supported on your
board/CPU) can help slightly, and I've had some success by launching VS.NET in
a lower-priority thread.

Linking with VC is much slower than than with Microsoft Visual c++ 6.0.
Actually, MUCH MUCH slower.
Yes.

Deciding which projects contain modified source and need to be recompiled:
much slower than than with Microsoft Visual c++ 6.0. Actually MUCH MUCH
slower.

The dependency checker didn't work well in previous versions, and it is worse
in this version. MS is /aware/ of the problem, but what I've heard, don't know
why, haven't made it a priority, and indicate that it _may_ be fixed in an
upcoming version (as a coincidental fix to other problems).

Starting my exe in the debugger: much slower than than with Microsoft Visual
c++ 6.0. The hard drive goes crazy and my system does not respond.
Yes.

Sometimes (often) the editor stops responding when compiling, launching exe
in debugger, etc. I cannot even scroll when this happens. Didn't happen in
VC6.

Yes, the IDE is unresponsive during builds. Break time.

dockable windows

GUIDS in the .sln

Find window that doesn't go away

F4 doesn't go to next error with all the template backtrace (worked fine in
MSVC6)

Yes, MS changes *A LOT* of the historical key mappings. Don't get me started
on MS and previous-version compatibility, it is an endemic problem in both MS
software and hardware.

New key code: Ctrl+Shift+F12

F4 doesn't go to next match in "search results" (worked fine in MSVC6)

Changed. Unknown what the key command for this one is.

 

[Bo Persson]

I forced everyone upgrade to MSVC 7.1/.net/2003 from MSVC6. Now my
coworkers hate me! I try to explain that VC has better template
support, but they are still very angry.

What can I do to make my coworkers enjoy VC7.1/.net/2003 more and not
want to kill me?

Believe me when I say it is very frusterating. It seems like the IDE
is working against us! And I'm the 7.1 proponent!

Here's a list of complaints from my 10 person team:

===

Microsoft Visual C++ .net 2003 7.1 (VC) takes a long time to load
multi-project workspaces (15 seconds). Much longer than MSVC6.0

Once a day?

While VC loads the project, my hard drive clicks away like I've never
heard it click before. Is this okay for my hard drive? Why does it
do this?

How much RAM do you have? Is Windows swapping out everything else?

512 MB is ok. 1024 is better!

While VC loads the project, my computer does not respond. This did
not happen with MSVC6.

Linking with VC is much slower than than with Microsoft Visual c++
6.0. Actually, MUCH MUCH slower.

That's because the link time code generation optimizes the whole program
much better. VC6 compiles each module separately (slower!) and the just
links the pieces together.

If you don't want to wait, you can disable this (and loose 20%
performance).

Deciding which projects contain modified source and need to be
recompiled: much slower than than with Microsoft Visual c++ 6.0.
Actually MUCH MUCH slower.

Haven't noticed this, but I don't have that many dependent projects.

Starting my exe in the debugger: much slower than than with Microsoft
Visual c++ 6.0. The hard drive goes crazy and my system does not
respond.

Need more memory?

Sometimes (often) the editor stops responding when compiling,
launching exe in debugger, etc. I cannot even scroll when this
happens. Didn't happen in VC6.

Happens. :-(

dockable windows

Slide-away panels? You'll love them after two weeks. Promise!

GUIDS in the .sln
Huh?


Find window that doesn't go away

Press Esc?

F4 doesn't go to next error with all the template backtrace (worked
fine in MSVC6)

F4 doesn't go to next match in "search results" (worked fine in MSVC6)

Thick dockable window boundaries that chop off valuable pixels of
debugging info.

But will also slide away if you let them - freeing up ACREs of screen
space!

I feel like I'm trapped in the IDE!

Launching a macro for the first time causes computer to stop
responding for about 5 seconds. And I have a fast computer! What in
the world is MSVC7.1 doing?

What about having a standard library that actually works?

What about the zillion bugs in VC6? Missing them too?

What about actually being able to use some templates?


Do you wanna stay in 1998 forever?


Bo Persson

 

[Rudy Ray Moore]

That's because the link time code generation optimizes the whole program
much better. VC6 compiles each module separately (slower!) and the just
links the pieces together.

If you don't want to wait, you can disable this (and loose 20%
performance).

We don't want to wait! I will do anything to increase link times,
particularly in debug builds. How do I disable this? I see four linker
optimization options: References, Enable COMDAT Folding, Optimize for
Windows 98, Function Order.

Thank so much,

Rudy

 

[Carl Daniel [VC++ MVP]]

We don't want to wait! I will do anything to increase link times,
particularly in debug builds. How do I disable this? I see four
linker optimization options: References, Enable COMDAT Folding,
Optimize for Windows 98, Function Order.

Even with LTCG disabled (it's not enabled by default), the VC7.1 linker is
quite a bit slower than the VC6 linker. More memory never hurts.. there's
probably not much else you can do but get a faster computer or break your
projects up into smaller executables.

-cd

 

[Ami Vora [MSFT]]

Hi Rudy--

I'm sorry you're experiencing trouble with your upgrade to VC7.1.

<snip perf problems>

We do recognize that there have been some regressions in performance from
VC6 to VC7.1, alongside the gains of better security options, better
optimizations, and better ISO conformance. The IDE team is working hard to
address these performance issues in Whidbey--we definitely understand how
important perf is to the C++ developer. We are improving performance all
over the IDE, in the debugger, editor, and project build and linker.

dockable windows

Find window that doesn't go away

These features will not significantly change in Whidbey. Our usability
studies show that most of our developers appreciate these features. In
some cases, we have tweaked the features, which might change your opinion
of them (eg, dockable windows are much easier to use in Whidbey).

GUIDS in the .sln

These are needed for project references, and will not change in Whidbey.

F4 doesn't go to next error with all the template backtrace (worked fine in
MSVC6)

F4 doesn't go to next match in "search results" (worked fine in MSVC6)

Whidbey will include the option (turned on by default) to use VC6
keybindings. Also, you can rebind all these keybindings in 7.1 using the
dialog at Tools.Options (Keyboard-->Environment).

I hope your team grows to see the advantages to using 7.1, and please let
us know if new problems come up. We are working to address the problems
that we know about, especially the performance issues, for Whidbey.

 

[Rudy Ray Moore]

Do you wanna stay in 1998 forever?

YES! (VC performance)
NO! (VC standards compliance)


Hey, I just got an idea... can I just replace VS6's cl.exe with the one from
VS7.1/.net/2003? I'm joking, but seems like a good way to have my cake and
eat it too.

Rudy

 

[Rudy Ray Moore]

Ami,

Thanks for your reply. I would just like to note that the following issues
are not key-binding issues, rather functionality issues (AFAIK):

1. The "go to next error key (F4)" does not skip over template backtraces
(as it did in VS6 - well, you know what I mean)

2. The "go to next error key (F4)" does not "go to next search results
match" (as it did in VS6). Maybe there's a new button to "go to next search
results match" -- does anybody know it?

Rudy

 

[Sean Cavanaugh]

Ami,

Thanks for your reply. I would just like to note that the following issues
are not key-binding issues, rather functionality issues (AFAIK):

1. The "go to next error key (F4)" does not skip over template backtraces
(as it did in VS6 - well, you know what I mean)

2. The "go to next error key (F4)" does not "go to next search results
match" (as it did in VS6). Maybe there's a new button to "go to next search
results match" -- does anybody know it?

F8


F4 has become the properties window