Do you have any advice on how to incorporate LLBLGen(erated) code into source control for team use. Should we just use the same techniques as we use for normal code?

johnh wrote:

Do you have any advice on how to incorporate LLBLGen(erated) code into source control for team use. Should we just use the same techniques as we use for normal code?

I'd be interested in this as well, although it seems to me that since LLBLGen Pro emits pure .net code, that yes, you should check it in and out of source control as needed.

I've just come off a project where we used DeKlarit, and you'd go crazy trying to figure out how to source control all of the various artifacts, because it creates and updates files even when all you do it open the solution!

Anyway, just thought I'd chime in on this!

--Bruce

johnh wrote:

Do you have any advice on how to incorporate LLBLGen(erated) code into source control for team use. Should we just use the same techniques as we use for normal code?

It really depends. One of my testprojects was changed so often (3-10 times a day), sourcesafe went bezerk of all the changes it had to log. This can really increase your sourcecontrol database a lot. Because it is generated code, it really doesn't matter if the source files get removed, you re-generate them again and you'll be fine. I'd store the .lgp files somewhere safe, perhaps in sourcecontrol to be sure you have a backup copy somewhere (and make backups of course, daily).

When you do not have a lot of changes (say once a week) in your generated code, or when you are using the two-class scenario and you're adding code to the generated files, it is recommended you place the complete sourcetree of the generated code in sourcecontrol and handle it like any other project.

A third option would be that you keep a separate solution with the generated code, compile that and reference the build result from that solution from your actual project. That will keep your other projects a little smaller.

bonder wrote:

I've just come off a project where we used DeKlarit, and you'd go crazy trying to figure out how to source control all of the various artifacts, because it creates and updates files even when all you do it open the solution!

Yeah, deklarit... never a dull moment I'd like to see them migrating a 100+ table production database because someone added an entity

Otis wrote:

Yeah, deklarit... never a dull moment I'd like to see them migrating a 100+ table production database because someone added an entity

It's too bad, too, because I like a lot of what they are trying to do. It just doesn't work as well as it should...

--Bruce

Hi.

Just to bring this topic back into life...

I have added the generated code to sourcesafe, the gen'd projects are part of my "Solution" file I have created. The problem I am having is that the project, being part of the solution and of sourcesafe, has all the extra "gubbins" in it, and when I re-generate the code, my project file is re-gen'd and loses its sourcecontrol stuff.

Hmmm, should I just not allow it to change the project file when I re-gen?

Matt, do you use v1.0.2004.1 or an older version, as the 1.0.2004.1 version alters the project file, not overwriting it, which means that the SCC stuff is preserved (the 4 attributes)

Ah, I think I must have been using the old prototype when I looked into this! We are using the new one, and I have just checked and the project source control info is persisted! Thanks!

Cool Thanks for the update.