VB.Net Text Editor stalls when I try and declare a variable

  • Thread starter Thread starter Desmond Cassidy
  • Start date Start date
D

Desmond Cassidy

Hi,
I don't know whether this is the correct place to ask this question..anyway
here goes...

I have a large solution with about 300 .vb files split into 9 projects
VB.net Framework 1.1 WinXP Pro

Whilst editing, as soon as I try and enter a statement like

Private strName as string

Then the VS.net stalls for about 30 seconds until the cursor is usable
again, devenv.exe (from viewing with the Task Manager) is eating up CPU
Time, Page Faulting like mad and I have loads of unused memory. I haven't a
clue what its doing...

However when I am in a piece of code (e.g. writing a function ) just writing
normal stuff then I don't have this problem.

Is it the size of the project and its trying to verify the variable, WIN XP
or perhaps a setting (option) that I have overlooked ???

ANy help/direction appreciated.

Cheers,

Desmond.
 
Hi Desmond,

Is it posible that you have on your import line things like system.mshmtl.
Have a look at those imports, it can be that one of those do this behaviour.
(mshtml will definitly do that).

I hope this helps,

Cor

"
 
Hi Cor...thanks for the quick reply....

I have 2 Imports....

One which Imports a project outside of the one I am working on (i.e. one of
the other 9) and that's a huge project (its the Kernel of the Project) and
another of a small piece of code...
 
* "Desmond Cassidy said:
I don't know whether this is the correct place to ask this question..anyway
here goes...

I have a large solution with about 300 .vb files split into 9 projects
VB.net Framework 1.1 WinXP Pro

Whilst editing, as soon as I try and enter a statement like

Private strName as string

Then the VS.net stalls for about 30 seconds until the cursor is usable
again, devenv.exe (from viewing with the Task Manager) is eating up CPU
Time, Page Faulting like mad and I have loads of unused memory. I haven't a
clue what its doing...

However when I am in a piece of code (e.g. writing a function ) just writing
normal stuff then I don't have this problem.

Is it the size of the project and its trying to verify the variable, WIN XP
or perhaps a setting (option) that I have overlooked ???
Click to expand...

I think this behavior may be caused by the background compiler. For
some reason, there is no way to turn it off...
 
So every time I change something it is verifying everything for teh WHOLE
soluton ??
 
I have the exact same problem... 350 files, 6 projects... Its irritating...

Does it take forever to load a form somteimtes as well?

Desmond Cassidy said:
So every time I change something it is verifying everything for teh WHOLE
soluton ??

WIN
Click to expand...
 
Well CJ....I am lucky (hah) that I don't have forms...this is a black box
project...

Very surprised no reference is made to this activity in the Microsoft
site....????



CJ Taylor said:
I have the exact same problem... 350 files, 6 projects... Its irritating...

Does it take forever to load a form somteimtes as well?
Click to expand...
 
Hi Desmond,

Is it on the point

Dim a as ...................... Then it can be the import.

(It start searching all the posible types).

Cor
 
Actually its worse that that....

If I go up to where all the Private variables are declared and type a
carriage return then that's enough for it to stall....
 
* "Desmond Cassidy said:
So every time I change something it is verifying everything for teh WHOLE
soluton ??
Click to expand...

I am not sure if it's the whole solution, but the background compiler
will check for syntax errors and other problems with your source code
which can be very time consuming, even in large projects.

I am not sure if it will work, but you can try to split the solution up
into some solutions and reference DLLs directly from your EXE project.
 
* "Desmond Cassidy said:
Very surprised no reference is made to this activity in the Microsoft
site....????
Click to expand...

I am not sure where it is documented, but for very large projects,
currently performance in C# is much better because no checking is done
while typing code into the text editor window.
 
* "Cor said:
Is it on the point

Dim a as ...................... Then it can be the import.

(It start searching all the posible types).
Click to expand...

This may also be problematic if there are /lots/ of types defined in the
solution.
 
There are hundreds of types defined in this project....

We are using a lot of IInterfaces,,,,
 
You know Herfried....that was what I was going to do next....


I have all the other other 8 projects loaded into the solution.....whereas I
am only working on one project...

So I guess I should get rid of the other 8 projects and then just add 8 dll
references ???
 
Unfortunately... a bit late in the day to change to c#.....

Have you seen any reference made to this in the MS Site,.???
 
* "Desmond Cassidy said:
I have all the other other 8 projects loaded into the solution.....whereas I
am only working on one project...

So I guess I should get rid of the other 8 projects and then just add 8 dll
references ???
Click to expand...

I have never played around with such a large VB.NET project :-().
 
Eh...correction.....

Add a reference to the projects 'referenced' so that its using the DLL
rather than the code....

Desmond Cassidy said:
You know Herfried....that was what I was going to do next....


I have all the other other 8 projects loaded into the solution.....whereas I
am only working on one project...

So I guess I should get rid of the other 8 projects and then just add 8 dll
references ???
Click to expand...
 
Desmond

I don't think your solution with 9 projects and 300 vb files is
generally too large to handle for VS. We have a VB.NET solution here
with 17 projects and currently 1248 .vb files in them. We used to have
huge IDE performance problems in VS.NET 2002, i.e. stalling for 1 minute
after entering a source code line. But the problems completely went away
when we switched to VS.NET 2003 - MSFT really did a good job on
improving their background compiler! We have no timelag whatsoever now
when editing code.

things to consider IMHO:
- low memory, for a large project you should have 768 MB RAM at least
- slow CPU, anything below a P IV is not suitable
- virus scanner active, disable it for the directories where you have
the project files
- perhaps to work files in the obj directories are corrupt? --> delete
all the obj directories, this already solved many problems for me
- you *are* working on your local harddisk and don't have your project
files on a network share, are you?

I would also consider checking with filemon (www.sysinternals.com) what
the compiler is doing, perhaps he writes working files to unexpected
places or so.
 
Hehe... Yeah... I agree... 80,000+ lines of code.... 3 months of non stop
work...

no.


Desmond Cassidy said:
Unfortunately... a bit late in the day to change to c#.....

Have you seen any reference made to this in the MS Site,.???
Click to expand...
 
Back
Top