Hi,

Are there any serious draw backs to large projects?

I'm finding that Refactor seems to have a hard time with entity field indexes. Also, my entity dll is now nearly 600k.

I'm not an expert on this but what size would an asp.net dll have to be to start overloading the server? Does this only really depend on the memory available on the server?

Cheers,

Ian.

Ian wrote:

Hi,

Are there any serious draw backs to large projects?

I'm finding that Refactor seems to have a hard time with entity field indexes. Also, my entity dll is now nearly 600k.

I'm not an expert on this but what size would an asp.net dll have to be to start overloading the server? Does this only really depend on the memory available on the server?

Code is not important, as a class' code is shared among all objects instantiated from a class in memory. So even if you have a 10MB assembly, it will only eat 10MB of memory (might be somewhat more).

If you place the generated code into a separate solution and reference the compiled dll from your own project, does that increase VS.NET speed?

I'll have to try it out.

The size of our generic .dll is currently 6 mb, the sqlserver specific is 384 kb and the oracle specific is 36 kb (because it's generated from a small subset of the db).

vs.net has no problem handling that, though Resharper takes its time with heavily overloaded functions (some methods have more than a thousand overloads). Though of course we don't have the generated code inside the project, only the compiled assemblies: having vs.net parse and compile the generated code stopped being a viable option a long time ago, we compile it with nant now.

Most of my team mates have developed Resharper templates for common llblgenpro tasks, such as filtering on a certain field, in order to avoid the dreaded "after-dot" timeout. Resharper delivers the old love-hate relationship in that regard.

cheers álvaro.-

Woah, how many entities do you have? Why is your project so big? I take it its not for an online store.

I'm interested in these templates. Can you explain a bit more? Are you saying that there's a specific template for writing out, for example, 'MyEntity.Field1'?

Ian.

having vs.net parse and compile the generated code stopped being a viable option a long time ago

Why what happened?

We have around 300 tables at the moment, and a few views and stored procedures, so that's what makes it big. It's a credit card processing system. There's a lot of data to remember!

As for the templates, it's a Resharper feature that lets you define a piece of code with to-replace variables and a keyword to invoke. So when you type the keyword, Resharper asks you for the variables and fills in the rest. For example I defined a template for a generic singleton, when I type singleton<tab>, Resharper asks me for the name ("mySingleton"), and generates all this stuff:

    public class mySingleton {
        private static volatile mySingleton instance = null;

        private mySingleton() {
        }

        public static mySingleton GetInstance() {
            if (instance == null) {
                lock (typeof (mySingleton)) {
                    if (instance == null) {
                        instance = new mySingleton();
                    }
                }
            }
            return instance;
        }
    }

So it's pretty convenient, for example to add relations and commonly used filters to a RelationPredicateBucket. I'm sure you get the picture, nothing magical there. cheers álvaro.-

Quote: having vs.net parse and compile the generated code stopped being a viable option a long time ago

Why what happened?

Well, it just took so darn long, it was a pain. My development workstation is a 1.53 GHz Athlon with 1 gb RAM. As I mentioned we use Resharper which takes a while to load a project. So opening the db generic project would take me about 2 minutes in which you can do nothing but check . . After a while we got tired of it, considering we are still changin our db model quite often.

NAnt compiles the generated projects without opening them in about 16 seconds. Quite a gain if you ask me.

We plan to take advantage of the recent new version (good one there Otis!!!) and fully automatize the whole change db - refresh catalog - generate code - compile generated code cycle. Now we have to open the designer and do the refresh manually.

Then the only pain left will be vs.net and its inability to refresh a referenced .dll when an external process changes it on hard disk. Currently whenever we regenerate the llblgenpro code we must close and restart vs.net. I HATE THAT. vs.net + resharper + visual source safe is like a virus. When running it eats up 400 mb RAM and the whole close-restart process takes around 30 minutes for our 500 K LOC.

Not to mention how long it takes to do a full rebuild. Enough to grab a cup of coffe and go for a leisurely stroll.

Well, sorry for rambling on you. To sum it up, in my opinion if you have decent development workstations, generated .dll size won't matter that much. Any server should be able to cope with it.

álvaro.-

I stopped using Resharper as well because of the slowness on large code bases, and large files. (e.g. the project explorer class is 4700 lines and mainwindow is 3900 lines. It was locking things up for 3, 4 seconds while I was typing code...)

VS.NET can't deal with large projects, my unittest solution for adapter contains 17 projects and regularly crashes during compilation. Compiling it at the command line works much better, it's much faster than doing it inside vs.net.

Alvaro: if you're developing a large webproject, perhaps it's better to transform teh webproject into a library project. It then will load much faster.

vs.net blows

I know resharper locks big time on large files, but we found out we couldn't live without it And our files aren't that big on average, just a couple of them get over 2000 KLOC.

Currently our vs.net solution has 33 projects, though no webprojects Our system is winforms, not web. Usually it builds OK, tough it has crashed a couple of times, due to "internal compiler errors" and "out of memory" errors from the compiler, requiring the oh so fun reset solution to get up on business again.

We plan on moving to NAnt builds and a Subversion repository instead of SourceSafe, that should speed up things a bit.

Thanks for the reply Alvaro.

We plan to take advantage of the recent new version (good one there Otis!!!) and fully automatize the whole change db - refresh catalog - generate code - compile generated code cycle.

Where is this feature?

Alvaro wrote:

We plan on moving to NAnt builds and a Subversion repository instead of SourceSafe, that should speed up things a bit.

When I moved to subversion, loading speeds of projects increased dramatically because vs.net didn't check for each file if it was present in the vss repository. You've this problem with every SCC interface using sourcecontrol system (though Vault is faster I think). Any non-vs.net integrated sourcecontrol system is therefore making loading a project much faster, and you also avoid the dreaded read-only files on disk (and the goo inside a project/solution file)

álvaro,

Can you not break your LLBLGen project down into several smaller projects which each deal with a different section of the database?

Quote:
We plan to take advantage of the recent new version (good one there Otis!!!) and fully automatize the whole change db - refresh catalog - generate code - compile generated code cycle.

Where is this feature?

You can achieve this with NAnt and some of the new features from http://www.llblgen.com/pages/secure/news.aspx. There's some work to be done but with the new features it can be done, previously it couldn't.

Check these out: Refresher options: CreateBackupBeforeRefresh, VerboseRefresh, SyncMappedElementNamesAfterRefresh, UpdateCustomPropertiesAfterRefresh, ShowReportAfterRefresh, AddNewElementsAfterRefresh, AddNewViewsAsEntitiesAfterRefresh.

Option to ignore system elements when retrieving entities/typed views from the catalog(s).

User preferences and project properties FieldMappedOnManyToManyPattern and FieldMappedOnOneManyToOnePattern patterns for specifying the format of the field mapped onto a relation. Several pattern elements are available to specify a format.

User preferences now have settings for strip patterns for entity names, typedview names, stored procedure names, entity field names and typed view field names.

Entity, view and stored procedure meta data retrieval now strips prefixes and suffixes and users can specify more than one prefix/suffix.

The preference CorrectNameCasing is now split into 2 preferences: RemoveUnderscoresFromElementName and MakeElementNamePascalCasing.

The name generation for fields mapped on a relation now uses two new patterns defined by the preferences FieldMappedOnManyToManyPattern and FieldMappedOnOneManyToOnePattern to construct the name.

Ian wrote:

álvaro,

Can you not break your LLBLGen project down into several smaller projects which each deal with a different section of the database?

Not really.

I like to use LLBLGenPro entities to hold my data. They already reflect the structure of the data via the generated properties that map the db relations, based on FK constraints.

If I have different projects, then I won't have relationships between entities from in different projects, even if they have FK constraints in the db.

Besides there isn't really good tool support to manage your db design in a structured way, at least that I know of. We use Visio EA which is nice because it allows you to design graphically and generate your model in most rdbms. However it doesn't allow you to structure your model in any way, so it's basically just a giant, flat, 300 table model. You can generate all of it or none of it.

Other tools that I heard of didn't support this either, please correct me if I'm wrong because I'm not so sure about that. Anyway I think they would be too expensive for us.

As you can see I have actually given some thought to this issue. Our systems have a hierarchical structure, like this:

core |--- subA-core-----|---- subsystem1
        |                               |---- subsystem2
        |--- subB
        |--- subC

Where to make things interesting usually each of subA, subB, subC are different projects (I work in core and subA-core) and they all target different databases. LLBLGenPro is a great help to port the core to other databases. The problem is that I have to manually copy the Visio project to another place and remove the tables that don't belong to the core before I do that, and have subB and subC in different visio projects, where they can't have FK to tables in the core. Thankfully subB and subC haven't needed to do that but when they do things will get ugly.

So to sum it up it would be wonderful to split the genpro projects to reflect this structure but neither db design tools or genpro itself will let me do it. The new Multiple catalog support (sqlserver) / multiple schema support (Oracle) would be a way to have my single project built from different catalogs, but what I would need is different, namely to have a genpro SOLUTION composed of different projects that reference each other.

Now i'm not sure if anyone will be able to make anything of those last two paragraphs

And a command line refresher is in the works