> I'm having a speed problem with VS.NET 2003 (release) that wasn't
happening
> in the beta 2003. In the VB editor, characters, when typed, don't show
until
> about 1/2 second after I typed them. This is very annoying and slow (and
I'm
> already a slow typist). This was not the case with the beta version and my
> system has not changed between the time I uninstalled the beta and I
> installed the release. This is in a project/solution with 1 simple form
only
> as well as any others.

> Anybody have any ideas.

> Thanks,
> Mike

> Do you have any third party Addin's?

> I have noticed that some addins causes 2003 to be slower in the IDE.

> Regards
> Fredrik Melin

> > I'm having a speed problem with VS.NET 2003 (release) that wasn't
> happening
> > in the beta 2003. In the VB editor, characters, when typed, don't show
> until
> > about 1/2 second after I typed them. This is very annoying and slow (and
> I'm
> > already a slow typist). This was not the case with the beta version and
my
> > system has not changed between the time I uninstalled the beta and I
> > installed the release. This is in a project/solution with 1 simple form
> only
> > as well as any others.

> > Anybody have any ideas.

> > Thanks,
> > Mike

> What is your OS? If you are running WinXP, try running Msconfig and load
> minimun services and restart windows and see if it works fine. Then add
other
> services and apps one by one to find out what cuases this behavior. If you
are
> on Win2000 machine, you can copy the Executable msconfig.exe from a winXP
> machine. For testing, you can use Selective Startup and uncheck all the
check
> options in the msconfig utility.

> Hope this helps!
> Bharat Patel
> Microsoft, Visual Basic .NET

> This posting is provided "AS IS" with no warranties, and confers no
rights.
> Please reply to newsgroups only. Thanks.

> Hi Mike,

> Thank you providing the update, it will help someone else and I am glad
that
> you resolved the issue.

> Thanks again!
> Bharat Patel
> Microsoft, Visual Basic .NET

> This posting is provided "AS IS" with no warranties, and confers no
rights.
> Please reply to newsgroups only. Thanks.

> Just a bit more detail on the NVidia drivers that I used:
> 6.13.xxx worked with final beta but not well with release of 2003.
> 5.13.xxx and 6.14.xxx (just tried this latest one) worked fine with
release.

> Mike

> > Hi Mike,

> > Thank you providing the update, it will help someone else and I am glad
> that
> > you resolved the issue.

> > Thanks again!
> > Bharat Patel
> > Microsoft, Visual Basic .NET

> > This posting is provided "AS IS" with no warranties, and confers no
> rights.
> > Please reply to newsgroups only. Thanks.

> We're seeing similar 'lag time' in the VB editor (not the C# editor,
> though - it appears to be VB-specific), but we have definitely tied the
> problem to the presence of a strong name file attribute, ex:

>     <Assembly: AssemblyKeyFile("C:\XXXX.snk")>

>Should also add that the problem disappears even with the presence of the
>attribute line IF we disconnect our network cable. It's as if the attribute
>is causing every change in the editor to do a network trip, but to where ?
>And why ?

> I didn't see any other relevant threads and wanted to expand on this topic
> with a problem we're having...

> We're seeing similar 'lag time' in the VB editor (not the C# editor,
> though - it appears to be VB-specific), but we have definitely tied the
> problem to the presence of a strong name file attribute, ex:

>     <Assembly: AssemblyKeyFile("C:\XXXX.snk")>

> When this line is present in our AssemblyInfo.vb file, the editor simply
> crawls, taking 5-10 seconds to respond every time the enter key is
pressed.
> Simply commenting out the attribute line immediately causes the editing
> problem to disappear. We can reproduce this on multiple machines, just by
> creating a new empty solution, adding a module and then toggling the
> attribute line on and off.

> Has anyone else seen this behavior ? Given the necessity of strong names
in
> certain circumstances, having them cause this sort of productivity hit
would
> seem to be a major bug. We originally saw this with VS.NET 2002, but
> recently put on the release version of VS.NET 2003 and are still seeing
the
> same problem, unfortunately.

> Should also add that the problem disappears even with the presence of the
> attribute line IF we disconnect our network cable. It's as if the
attribute
> is causing every change in the editor to do a network trip, but to where ?
> And why ?

> Any help would be appreciated...

> TIA,
> Bob Shirley
> First DataBank, Inc.

> =====================================================

> > Just a bit more detail on the NVidia drivers that I used:
> > 6.13.xxx worked with final beta but not well with release of 2003.
> > 5.13.xxx and 6.14.xxx (just tried this latest one) worked fine with
> release.

> > Mike

> > > Hi Mike,

> > > Thank you providing the update, it will help someone else and I am
glad
> > that
> > > you resolved the issue.

> > > Thanks again!
> > > Bharat Patel
> > > Microsoft, Visual Basic .NET

> > > This posting is provided "AS IS" with no warranties, and confers no
> > rights.
> > > Please reply to newsgroups only. Thanks.

> > We're seeing similar 'lag time' in the VB editor (not the C# editor,
> > though - it appears to be VB-specific), but we have definitely tied the
> > problem to the presence of a strong name file attribute, ex:

> >     <Assembly: AssemblyKeyFile("C:\XXXX.snk")>

> Is this a real example of your keyfile location, looks local to the system
> its on.

> >Should also add that the problem disappears even with the presence of the
> >attribute line IF we disconnect our network cable. It's as if the
attribute
> >is causing every change in the editor to do a network trip, but to where
?
> >And why ?

> Where is the keyfile located or other files getting referenced from? On a
> network share?

> > I didn't see any other relevant threads and wanted to expand on this
topic
> > with a problem we're having...

> > We're seeing similar 'lag time' in the VB editor (not the C# editor,
> > though - it appears to be VB-specific), but we have definitely tied the
> > problem to the presence of a strong name file attribute, ex:

> >     <Assembly: AssemblyKeyFile("C:\XXXX.snk")>

> > When this line is present in our AssemblyInfo.vb file, the editor simply
> > crawls, taking 5-10 seconds to respond every time the enter key is
> pressed.
> > Simply commenting out the attribute line immediately causes the editing
> > problem to disappear. We can reproduce this on multiple machines, just
by
> > creating a new empty solution, adding a module and then toggling the
> > attribute line on and off.

> > Has anyone else seen this behavior ? Given the necessity of strong names
> in
> > certain circumstances, having them cause this sort of productivity hit
> would
> > seem to be a major bug. We originally saw this with VS.NET 2002, but
> > recently put on the release version of VS.NET 2003 and are still seeing
> the
> > same problem, unfortunately.

> > Should also add that the problem disappears even with the presence of
the
> > attribute line IF we disconnect our network cable. It's as if the
> attribute
> > is causing every change in the editor to do a network trip, but to where
?
> > And why ?

> > Any help would be appreciated...

> > TIA,
> > Bob Shirley
> > First DataBank, Inc.

> Subject: Re: VB.Net Editor keystrokes lag/slow to respond (VS.NET 2003)
> Date: Mon, 19 May 2003 06:29:38 -0500
> Lines: 88
> X-Priority: 3
> X-MSMail-Priority: Normal
> X-Newsreader: Microsoft Outlook Express 6.00.2800.1106
> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106

> Newsgroups: microsoft.public.dotnet.languages.vb
> NNTP-Posting-Host: 65.88.137.194
> Path: cpmsftngxa06.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTNGP11.phx.gbl
> Xref: cpmsftngxa06.phx.gbl microsoft.public.dotnet.languages.vb:108604
> X-Tomcat-NG: microsoft.public.dotnet.languages.vb

> Well, the keyfile name is bogus, but the location is correct; this is a
> development machine with the keyfile currently in the root of C:...

> What 'other files' specifically are you asking about ? As I said in the
last
> post, I can reproduce this problem starting with a clean WinForms solution
> and just adding a form and code behind that form.

> I've assumed that something having to do with network roundtrips was
causing
> this since we first started experiencing it, but haven't been able to
figure
> out what would be attempting the roundtrtips, or why, especially during an
> editor session...?

> Even with all the documentation in this thread (and others) about changing
> display drivers to fix the slowness in the editor, that can't apply here,
> since we don't have the slowness problem in projects that don't have the
> AssemblyKeyFile attribute, and the machines in question don't have NVidia
> drivers (they're Intel).

> > > We're seeing similar 'lag time' in the VB editor (not the C# editor,
> > > though - it appears to be VB-specific), but we have definitely tied
the
> > > problem to the presence of a strong name file attribute, ex:

> > >     <Assembly: AssemblyKeyFile("C:\XXXX.snk")>

> > Is this a real example of your keyfile location, looks local to the
system
> > its on.

> > >Should also add that the problem disappears even with the presence of
the
> > >attribute line IF we disconnect our network cable. It's as if the
> attribute
> > >is causing every change in the editor to do a network trip, but to
where
> ?
> > >And why ?

> > Where is the keyfile located or other files getting referenced from? On
a
> > network share?

> > > I didn't see any other relevant threads and wanted to expand on this
> topic
> > > with a problem we're having...

> > > We're seeing similar 'lag time' in the VB editor (not the C# editor,
> > > though - it appears to be VB-specific), but we have definitely tied
the
> > > problem to the presence of a strong name file attribute, ex:

> > >     <Assembly: AssemblyKeyFile("C:\XXXX.snk")>

> > > When this line is present in our AssemblyInfo.vb file, the editor
simply
> > > crawls, taking 5-10 seconds to respond every time the enter key is
> > pressed.
> > > Simply commenting out the attribute line immediately causes the
editing
> > > problem to disappear. We can reproduce this on multiple machines, just
> by
> > > creating a new empty solution, adding a module and then toggling the
> > > attribute line on and off.

> > > Has anyone else seen this behavior ? Given the necessity of strong
names
> > in
> > > certain circumstances, having them cause this sort of productivity hit
> > would
> > > seem to be a major bug. We originally saw this with VS.NET 2002, but
> > > recently put on the release version of VS.NET 2003 and are still
seeing
> > the
> > > same problem, unfortunately.

> > > Should also add that the problem disappears even with the presence of
> the
> > > attribute line IF we disconnect our network cable. It's as if the
> > attribute
> > > is causing every change in the editor to do a network trip, but to
where
> ?
> > > And why ?

> > > Any help would be appreciated...

> > > TIA,
> > > Bob Shirley
> > > First DataBank, Inc.

> X-Tomcat-ID: 535171862

> MIME-Version: 1.0
> Content-Type: text/plain
> Content-Transfer-Encoding: 7bit

> Organization: Microsoft
> Date: Mon, 19 May 2003 19:59:01 GMT
> Subject: Re: VB.Net Editor keystrokes lag/slow to respond (VS.NET 2003)
> X-Tomcat-NG: microsoft.public.dotnet.languages.vb

> Newsgroups: microsoft.public.dotnet.languages.vb
> Lines: 134      
> Path: cpmsftngxa06.phx.gbl
> Xref: cpmsftngxa06.phx.gbl microsoft.public.dotnet.languages.vb:108731
> NNTP-Posting-Host: TOMCATIMPORT2 10.201.218.182

> Hi, Bob,
>   I apologize for the inconvenience this problem has caused you.  I've
> created a bug to track this issue; one of my guys is investigating right
> now, in fact.  He may get in touch with you by e-mail to get more details
> if necessary.  (Stamping these sorts of perf issues out once and for all
is
> a major goal for us, so we'd really like to mail this -- any additional
> info appreciated.)  I'll respond back to this thread as soon as we've
> learned anything.

> Thanks,
>   --Matt Gertz--*
>   VB Compiler Lead
> --------------------










> > Subject: Re: VB.Net Editor keystrokes lag/slow to respond (VS.NET 2003)
> > Date: Mon, 19 May 2003 06:29:38 -0500
> > Lines: 88
> > X-Priority: 3
> > X-MSMail-Priority: Normal
> > X-Newsreader: Microsoft Outlook Express 6.00.2800.1106
> > X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106

> > Newsgroups: microsoft.public.dotnet.languages.vb
> > NNTP-Posting-Host: 65.88.137.194
> > Path: cpmsftngxa06.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTNGP11.phx.gbl
> > Xref: cpmsftngxa06.phx.gbl microsoft.public.dotnet.languages.vb:108604
> > X-Tomcat-NG: microsoft.public.dotnet.languages.vb

> > Well, the keyfile name is bogus, but the location is correct; this is a
> > development machine with the keyfile currently in the root of C:...

> > What 'other files' specifically are you asking about ? As I said in the
> last
> > post, I can reproduce this problem starting with a clean WinForms
solution
> > and just adding a form and code behind that form.

> > I've assumed that something having to do with network roundtrips was
> causing
> > this since we first started experiencing it, but haven't been able to
> figure
> > out what would be attempting the roundtrtips, or why, especially during
an
> > editor session...?

> > Even with all the documentation in this thread (and others) about
changing
> > display drivers to fix the slowness in the editor, that can't apply
here,
> > since we don't have the slowness problem in projects that don't have the
> > AssemblyKeyFile attribute, and the machines in question don't have
NVidia
> > drivers (they're Intel).

> > > > We're seeing similar 'lag time' in the VB editor (not the C# editor,
> > > > though - it appears to be VB-specific), but we have definitely tied
> the
> > > > problem to the presence of a strong name file attribute, ex:

> > > >     <Assembly: AssemblyKeyFile("C:\XXXX.snk")>

> > > Is this a real example of your keyfile location, looks local to the
> system
> > > its on.

> > > >Should also add that the problem disappears even with the presence
of
> the
> > > >attribute line IF we disconnect our network cable. It's as if the
> > attribute
> > > >is causing every change in the editor to do a network trip, but to
> where
> > ?
> > > >And why ?

> > > Where is the keyfile located or other files getting referenced from?
On
> a
> > > network share?

> > > > I didn't see any other relevant threads and wanted to expand on this
> > topic
> > > > with a problem we're having...

> > > > We're seeing similar 'lag time' in the VB editor (not the C# editor,
> > > > though - it appears to be VB-specific), but we have definitely tied
> the
> > > > problem to the presence of a strong name file attribute, ex:

> > > >     <Assembly: AssemblyKeyFile("C:\XXXX.snk")>

> > > > When this line is present in our AssemblyInfo.vb file, the editor
> simply
> > > > crawls, taking 5-10 seconds to respond every time the enter key is
> > > pressed.
> > > > Simply commenting out the attribute line immediately causes the
> editing
> > > > problem to disappear. We can reproduce this on multiple machines,
just
> > by
> > > > creating a new empty solution, adding a module and then toggling the
> > > > attribute line on and off.

> > > > Has anyone else seen this behavior ? Given the necessity of strong
> names
> > > in
> > > > certain circumstances, having them cause this sort of productivity
hit
> > > would
> > > > seem to be a major bug. We originally saw this with VS.NET 2002, but
> > > > recently put on the release version of VS.NET 2003 and are still
> seeing
> > > the
> > > > same problem, unfortunately.

> > > > Should also add that the problem disappears even with the presence
of
> > the
> > > > attribute line IF we disconnect our network cable. It's as if the
> > > attribute
> > > > is causing every change in the editor to do a network trip, but to
> where
> > ?
> > > > And why ?

> > > > Any help would be appreciated...

> > > > TIA,
> > > > Bob Shirley
> > > > First DataBank, Inc.

> Just an update -- currently, we're not able to repro the problem specific
> to this case, but one of my devs (Ernest) is following up with Bob via
> e-mail to check a few possibilities and one potential workaround.  More
> info as I get it...
> --------------------

> > Hi, Bob,
> >   I apologize for the inconvenience this problem has caused you.  I've
> > created a bug to track this issue; one of my guys is investigating right
> > now, in fact.  He may get in touch with you by e-mail to get more
details
> > if necessary.  (Stamping these sorts of perf issues out once and for all
> is
> > a major goal for us, so we'd really like to mail this -- any additional
> > info appreciated.)  I'll respond back to this thread as soon as we've
> > learned anything.

> > Thanks,
> >   --Matt Gertz--*
> >   VB Compiler Lead
> > --------------------

> > > Well, the keyfile name is bogus, but the location is correct; this is
a
> > > development machine with the keyfile currently in the root of C:...

> > > What 'other files' specifically are you asking about ? As I said in
the
> > last
> > > post, I can reproduce this problem starting with a clean WinForms
> solution
> > > and just adding a form and code behind that form.

> > > I've assumed that something having to do with network roundtrips was
> > causing
> > > this since we first started experiencing it, but haven't been able to
> > figure
> > > out what would be attempting the roundtrtips, or why, especially
during
> an
> > > editor session...?

> > > Even with all the documentation in this thread (and others) about
> changing
> > > display drivers to fix the slowness in the editor, that can't apply
> here,
> > > since we don't have the slowness problem in projects that don't have
the
> > > AssemblyKeyFile attribute, and the machines in question don't have
> NVidia
> > > drivers (they're Intel).

> > > > > We're seeing similar 'lag time' in the VB editor (not the C#
editor,
> > > > > though - it appears to be VB-specific), but we have definitely
tied
> > the
> > > > > problem to the presence of a strong name file attribute, ex:

> > > > >     <Assembly: AssemblyKeyFile("C:\XXXX.snk")>

> > > > Is this a real example of your keyfile location, looks local to the
> > system
> > > > its on.

> > > > >Should also add that the problem disappears even with the presence
> of
> > the
> > > > >attribute line IF we disconnect our network cable. It's as if the
> > > attribute
> > > > >is causing every change in the editor to do a network trip, but to
> > where
> > > ?
> > > > >And why ?

> > > > Where is the keyfile located or other files getting referenced from?
> On
> > a
> > > > network share?

message

> > > > > I didn't see any other relevant threads and wanted to expand on
this
> > > topic
> > > > > with a problem we're having...

> > > > > We're seeing similar 'lag time' in the VB editor (not the C#
editor,
> > > > > though - it appears to be VB-specific), but we have definitely
tied
> > the
> > > > > problem to the presence of a strong name file attribute, ex:

> > > > >     <Assembly: AssemblyKeyFile("C:\XXXX.snk")>

> > > > > When this line is present in our AssemblyInfo.vb file, the editor
> > simply
> > > > > crawls, taking 5-10 seconds to respond every time the enter key is
> > > > pressed.
> > > > > Simply commenting out the attribute line immediately causes the
> > editing
> > > > > problem to disappear. We can reproduce this on multiple machines,
> just
> > > by
> > > > > creating a new empty solution, adding a module and then toggling
the
> > > > > attribute line on and off.

> > > > > Has anyone else seen this behavior ? Given the necessity of strong
> > names
> > > > in
> > > > > certain circumstances, having them cause this sort of productivity
> hit
> > > > would
> > > > > seem to be a major bug. We originally saw this with VS.NET 2002,
but
> > > > > recently put on the release version of VS.NET 2003 and are still
> > seeing
> > > > the
> > > > > same problem, unfortunately.

> > > > > Should also add that the problem disappears even with the presence
> of
> > > the
> > > > > attribute line IF we disconnect our network cable. It's as if the
> > > > attribute
> > > > > is causing every change in the editor to do a network trip, but to
> > where
> > > ?
> > > > > And why ?

> > > > > Any help would be appreciated...

> > > > > TIA,
> > > > > Bob Shirley
> > > > > First DataBank, Inc.

> Hi,
> I encountered the same problem recently.
> I have a class library project which always uses a key file. It worked
> fine before. however, this problem started to occur a few days ago
> after I made a bunch of changes to the project. I don't know what
> change caused it. It seems that commenting out the KeyFile line
> immediately cures the slowness. I'd love to see a solution here, since
> this is a really annoying issue.
> Thanks for the discussion here which gave me a lead.
> Steven