I know this is more of a Visual Studio question but wanted to see if you had any perspective on this before calling MS tech support on this.

When we first generated with open source version of LLBLGen v1.? with our 1,000 table database, suddenly the project was very slow with opening for edit, compiling, opening projects etc. New faster computers solved this, but now with the LLBLGen Pro, the one table many classes has VS totally stalled. No file will open for edit, the project with the new llbl project added will never finish compiling. This is with 1 gigabyte of memory.

Your pro program generated very fast, about one minute, for the whole database. It is VS which seems to not like projects with a lot of files in it.

I've mentioned this to many people, but no one has had the experience.

Do you have any experience with this?

Thanks,

Terry

Visual studio is slow with a lot of classes. However you could try to compile the generated code on the command line, and just reference the assembly in vs.net. VS.NET brings a lot of overhead to the table when you have lots of classes due to the intellisense. (because it has to parse all the classes, if you reference an assembly it can do that a lot quicker)

You can compile everything on the commandline using a buildtool like Hyppo.net or Nant. You can also write a simple .bat file with the following commands and execute it in the root dir of your generated code project.

vsvars32.bat
csc /out:dal.dll /t:library /recurse:*.cs /o /r:"C:\Program Files\Solutions Design\LLBLGen Pro\RuntimeLibraries\DotNet11\SD.LLBLGen.Pro.ORMSupportClasses.NET11.dll","C:\Program Files\Solutions Design\LLBLGen Pro\RuntimeLibraries\DotNet11\SD.LLBLGen.Pro.DQE.SqlServer.NET11.dll"

This will compile the generated code to 'dal.dll'. Alter the paths if you installed LLBLGen Pro somewhere else.

It might take a while but you then can compile the code and work with your own code in your vs.net solution.

Since I'm using vb.net I used this since it didn't understand the /o:

C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\vbc /out:tal.dll /t:library /recurse:*.vb /o /r:"C:\Program Files\Solutions Design\LLBLGen Pro\RuntimeLibraries\DotNet11\SD.LLBLGen.Pro.ORMSupportClasses.NET11.dll","C:\Program Files\Solutions Design\LLBLGen Pro\RuntimeLibraries\DotNet11\SD.LLBLGen.Pro.DQE.SqlServer.NET11.dll"

The compilation did not succeed and reached the maximum number of errors with mostly: This code cannot appear outside a method "else"

Do you know how to compile this with vbc?

Ok, that took a few minutes instead of a second

vbc /out:dal.dll /target:library /sdkpath:C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322 /recurse:*.vb /optimize /r:"C:\Program Files\Solutions Design\LLBLGen Pro\RuntimeLibraries\DotNet11\SD.LLBLGen.Pro.ORMSupportClasses.NET11.dll","C:\Program Files\Solutions Design\LLBLGen Pro\RuntimeLibraries\DotNet11\SD.LLBLGen.Pro.DQE.SqlServer.NET11.dll",system.dll,system.data.dll,system.enterpriseservices.dll,system.xml.dll /imports:system

I just got the brilliant idea that it doesn't matter which I compile it with I will be able to use it fine right?

It seems to be compiling with the csc just fine.

Does it matter which I compile with?

Your program llblgen is c#, the output is vb classes, so what should it be compiled with since we are linking in two dlls that are c# right?

Haven't done much manual compiling here.

tvoss wrote:

I just got the brilliant idea that it doesn't matter which I compile it with I will be able to use it fine right? It seems to be compiling with the csc just fine. Does it matter which I compile with?

No it doesn't You can generate the code in C#, compile that on the command line and reference it in your VB.NET project (.NET assemblies are C# also).

Your program llblgen is c#, the output is vb classes, so what should it be compiled with since we are linking in two dlls that are c# right? Haven't done much manual compiling here.

heh well, VB.NET is a pain from the commandline, as you can see. You need to reference all kinds of assemblies it can find on its own perfectly.. ah well...

Thanks for your help. Are most of the llblgen pro people from the Netherlands?

I compiling with C# now and am on the validator classes. I am getting lots of errors that I can see once in a while in the flow like:

A namespace does not directly contain fields or methods

Is this normal?

I just realized that I had changed the recurse param to vb, so starting compile over.

Maybe that was the cause of the errors.

When I use your code for compiling after fixing the vb param thing, except for addition of the path of csc, the compile errors out almost right away with:

"Location of symbol related to previous error"

Previous error was:

Error CS0101: "The namespace '?' already contains a definition for '?'

Previous to that error was:

Error CS1001: "Identifier Expected"

I am using the generation configuration for 1.1 that only creates the entity with no base since I won't be able to modify the entity in my vb projects anyway. Is that okay?

We're a dutch company yes (The Hague)

You can't mix the two commandline statements I gave you The first one I gave you was for C#, so if you want to compile C#, use that one. If you want to compile VB.NET code, use the one I gave later on. You can't just use the VB.NET one for C# code by changing the compiler and the extension of the files

(You mentioned earlier the C# code compiled fine, so I'm a little confused )

I understand I can't mix the two compile statements, that was inadvertant.

I said the c# started compiling without errors and was looking good, but it won't complete.

Is it because I used the first config method instead of the last to reduce the number of files involved?

tvoss wrote:

I said the c# started compiling without errors and was looking good, but it won't complete. Is it because I used the first config method instead of the last to reduce the number of files involved?

If you first generated code using two-class scenario and then generate ON TOP of that using the general scenario, the code won't compile. You can't mix the two. (because not all files will be overwritten)

Generate the code in a new directory, using the general scenario (good thinking indeed, that will decrease the amount of classes ) and try again. You now have a messed up set of files.

It won't compile using the c# compile syntax with same errors mentioned before.

I created a new project in same location but one folder off with ticllblgenproproject instead of the LLBLGen Pro Projects folder.

How does the compile statement know of the change I just made to the location of the source class code? Is it the recurse parameter or the dlls that are being linked to?

I get the same error set whether I use vb compile statement or the c# one.

By the way, what is the time difference? So I know when is a good time for this forum. I'm in pacific standard time it is 10:05 AM here now.

Thanks for your help on this.

tvoss wrote:

I get the same error set whether I use vb compile statement or the c# one.

I execute the statements in the dir where the code is in. So if the code is in C:\temp\MyDal, then I go to that directory and start the statement.

If you have visualstudio.net installed on your machine, you can just type on a commandprompt: vsvars32.bat

and the paths to the SDK are added to your path. Then CD to the dir of your project (in your case thus the new dir wherein you generated the code) and start the statement.

By the way, what is the time difference? So I know when is a good time for this forum. I'm in pacific standard time it is 10:05 AM here now. Thanks for your help on this.

The time your postings gets is my time (Server is in Amsterdam, I'm in The Hague, 60 KM more south). That's 9 hours time difference. But don't worry, I'll try to answer a.s.a.p.

I finally figured out that I have .vb output so I must use vbc.exe and then I must execute the statement from the project directory or it won't work.

This compile then and the main problem is solved in that I can open web pages and work on converting.

When Intellisense is used there is slowness, but after converting all the current pages, I can delete 680 .vb source files from the old llblgen version and that should speed things up again.

Thanks for your input. I should have introduced myself as total compiling newbie right off

No problem Terry

I ran into a vb commandline compiler issue while checking out how to formulate the compile statement, googled and ran into an old question of mine about exact the same thing (and it was properly answered) We have a saying here in Holland: A mule never hit his foot on the same rock... well.. I felt pretty dumb when I read my old question on google groups

Just for the record:

The speed problems were all solved by compiling except for the top level: Dim customer as New CustomerEntity was very slow (many seconds) because many thousands of classes were all trying to get into that intellisense list.

I deleted all but a few of the imports statements that put them all into that list since I only have very few top level references to make in one web page and now intellisense is instant again.

Might be a tip for someone.