I find myself regenerating so often during early phases of development. Is there a way not to click 20 times to do it. Like a template for each project?

Sure, go to the extra's section in the customer area and download the command line code generator Place it in the llblgen pro folder and you can generate code on teh command line

The .EXE file seems to be missing from the zip file for CommandLineGenerator.zip

Readme.txt says, "if you want to compile the source, do something..." making me think the exe should already be there.

Is this correct?

The .exe is not included. just load the solution in visual studio and compile the solution, you'll then have the .exe.

Got the 3 references in, but I'm getting 5 similar messages about GenerateCore:

C:\cg\Generator\Engine.cs(59): 'SD.LLBLGen.Pro.GeneratorCore.Generator' does not contain a definition for 'ActionProcedures'

Do I maybe need to upgrade?

I have: v1.0.2003

The upgrade did it.

Your upgrades are going pretty darn smooth now!

Thanks again.

Terry Voss

No problem, Terry

I got the auto-regens going and for small projects the regen takes no time at all. Just a few seconds, and for our largest project of about 1,000 tables, it takes 6 minutes.

This is a great help to productivity.

I am having this problem though.

If I simply lengthen a char field, the regeneration does not reflect the change. I suppose this is because the .lgp file is used to get database connectivity info, but that is where the schema is also?

So if the project is not new, the generated classes are not new, just a new set of classes off the same schema?

Is there a way to automate the whole schema/regen process?

And if not, could you tell me how people use this cliGenerator. Do they edit the project, and then regen? Or what purpose is the cliGenerator.

Fill me in on this please

the cligenerator uses the same code as when you press F7 and make selections. So to generate code that reflects a change in the database, you first have to refresh the catalog, eventually add entities which are new etc. Because this can require manual actions, there is no cli catalog refresher.

The cligenerator is often used for automated tests, so you can generate code first, then build it and run the unittests.

In what file and type is the schema held?

If it was text maybe we could write a program to change the data there to match the database or write a program that creates that file off the database from script.

I need to find some way to reduce time for generations.

Thanks,

Terry

tvoss wrote:

In what file and type is the schema held?

In the .lgp file. An .lgp file is a binary serialized object graph of the complete project object graph with the catalog object graph included.

If it was text maybe we could write a program to change the data there to match the database or write a program that creates that file off the database from script.

That's what the refresher does for you, if I understand what you want to do correctly .

I need to find some way to reduce time for generations.

6 minutes is rather long indeed... Be sure you've build the cligenerator in release build mode.

All limitations of the amount of entities to process (for example by selecting the entity which is changed in the generator configuratoin dialog) can help, but also affects for example constantsenums.vb, something which you don't want because it creates maintenance misery and probably takes more time than to generate the complete project again.

What thus can help the most is to make schema changes not 10 times a day, but once a day, generate the code then. (but this of course has to be possible with the way you develop your project).

By the refresher, you mean, I assume, going into the designer, opening a project, choosing project, refresh catalog, typing in password, connecting, and clicking on a button, waiting a few seconds, saving project, closing designer.

Then doing an auto-regen.

A large fraction of each day is spent in such button clicking process. It seems to be the main negative aspect of using an ORmapper.

Everything else is great!

Does this make more sense why this is so important?

Terry

tvoss wrote:

By the refresher, you mean, I assume, going into the designer, opening a project, choosing project, refresh catalog, typing in password, connecting, and clicking on a button, waiting a few seconds, saving project, closing designer.

Then doing an auto-regen.

A large fraction of each day is spent in such button clicking process. It seems to be the main negative aspect of using an ORmapper.

The clicking process is indeed somewhat tedious at the moment, and it is scheduled to be streamlined real soon (estimated release date early january) which lets you refresh the catalog with one command without hassle.

You could of course also hit F7 and enter after the refresh is done. (set the preferred generator config as the default in the preferences first). This will generate the code at the same spot as last time, using the same template set and namespace.

It is not that hard to create a command line refresher. The point is that when refreshing the catalog, the changes perhaps require you to do some actions, like renaming some fields, or adding a new entity/view/proc call, so only in several situations the commandline refresher would be useful.

This is interesting, but in our cases, many clients, we never rename or do anything manual in the designer except what we are forced just to match the database names and keep from manual motions.

Glad January will have some reprieve, but consider many smaller developers like us really need the ability to run a cligen for instant productivity as client changes are always adding fields, datatype length changes.

You can charge us for it too!

It would save me $100 a day!

Thanks, Terry MS MVP - ASP.NET

I'll look into a cli-gen tool, it's not a big deal, really.

Just out of curiosity: why do you need to change the schema that often?

Hi,

We'd love to have a cmd line that behaves like what Terry wants, that is: * Refresh catalog from a given (configured) data source, keeping the default namespace, etc. * Add all new tables as entities * Add new typed views and stored procs (though quite less important than adding the new tables) * Sync all field names and lengths * Regenerate to a given (configured or taken from the project properties) folder

We are currently developing a big project and we chose to do it incrementally so typically each new functionality requires creating some new tables. As features are shown to customers we get their feedback and add a couple of fields, remove another, change a datatype. That's why we would save a lot of time with such a tool. We would include refreshing the catalog / generating the code into our build process and no one would have to waste time because they have to add a new field to a certain table.

Cheers, álvaro.-

Except from the fieldname syncing, which is not yet build into the refresher engine, the rest can be done with a cli refresher. I'll investigate how much time it will take to implement such a tool.

It is the way the projects develop.

Agile versus planned ahead I guess would be one way to describle it.

We develop top down a structure that will handle basically the type of thing the client is describing and then fill out actual reality requirements as we go along, so it is not so much new tables, but add one field to handle some newly described requirement.

To regen everything for one field is the usual requirement so you can see the need for automation of regen.

As soon I as I see one field will solve problem, then I want to use it and test its functionality right away.

Does this explain what you were asking about?

Yes, thanks for giving this feedback, Terry. I've planned to make refreshing a catalog much easier and when that logic is implemented, a command line refresher will be released as well which will utilize that new logic. Expect something around end january 2005.

I know of a lot of developers I work with that will be happy about this.