..is the frequency of having the generated code not compile first time round.

Surely it shouldn't let you generate code that's not going to compile?

I've got many many mesages saying stuff like..

'VideoTracking.FactoryClasses.EventEntityFactory' does not implement interface member 'SD.LLBLGen.Pro.ORMSupportClasses.IEntityFactory2.CreateEntityFromEntityTypeValue(int)'

Now what I usually do is just keep fiddling with the tasks and deleting everything that's already there until it works.

I personally have never had a problem like that in the 3 years I've used LLBLGen. If I ever did it was because I had my references all screwed up in my project.

Ian wrote:

..is the frequency of having the generated code not compile first time round.

Surely it shouldn't let you generate code that's not going to compile?

I've got many many mesages saying stuff like..

'VideoTracking.FactoryClasses.EventEntityFactory' does not implement interface member 'SD.LLBLGen.Pro.ORMSupportClasses.IEntityFactory2.CreateEntityFromEntityTypeValue(int)'

Now what I usually do is just keep fiddling with the tasks and deleting everything that's already there until it works.

1) always make sure you examine the generation REPORT that's shown to you after code generation. If files weren't overwritten, you can see it in that report. 2) we use an automated set of code generation tasks to check whether code compiles or not. We generate for all presets for both languages for all platforms for all databases code using a variety of projects,including inheritance etc. and if something breaks, we'd know and fix it up front. 3) the error you post above is typically caused by the fact that the generated code references an ormsupportclasses dll of a previous version. Normally this shouldn't happen though, as our unittest projects use generated dals as well and we never have this problem. If you have 2 different versions of llblgen pro installed, it might be vs.net picks the wrong version, but you have to correct that manually once. Next time you generate code on top of that project, the references are kept.

I get the feeling you generate in an empty folder each time, correct?

I've been using LLBLGen Pro for almost 3 years too. I did have 100s of code generations and compiles, and I've never had a single issue in compiling the generated code.

Would you please provide more info about your environment and the LLBLGen Pro version you are using?

Also are there any older versions installed side by side.

Please check the following thread guidelines and try to provide as many details as the ones listed there: http://www.llblgen.com/TinyForum/Messages.aspx?ThreadID=7722

Also it would be better if you attach the LLBLGen project from which you are generating the code that doesn't compile.

Me too. Very happy with it.

3) the error you post above is typically caused by the fact that the generated code references an ormsupportclasses dll of a previous version. Normally this shouldn't happen though, as our unittest projects use generated dals as well and we never have this problem. If you have 2 different versions of llblgen pro installed, it might be vs.net picks the wrong version, but you have to correct that manually once. Next time you generate code on top of that project, the references are kept.

Yes this was the cause this time. But no I don't usually geenrate into an empty folder.

I'll pay attention the next time this happens (when its not so obvious) and give you some more detailed info. If I recall correctly, a lot of these occurrences have been VS caching stuff. Surely I'm not the only one to have suffered that?

If you mean: vs.net scr*ws things up because it cached dlls ? Oh yes, don't get me started on that. Unfortunately, it's not really something we can fix, otherwise I'd have done so. SP1 of vs.net 2005 fixes a lot of these issues though.

The first time I used LLBLGen Pro, I got a bunch of source code files. I added them to a project, added references and tried to compile them without much luck. (Did I mention that I used the standard Ok-Next-Finish philosophy when selecting the options in Generate?)

It's only later that I realised I had to select the Target platform, which was by default set to CF.NET 1.0. After I picked .NET 2.0, LLBLGen Pro automagically created the project files and all I had to do was open them and build!

Somebody ought to see the U.I. guys about setting the default Target platform to .NET 2.0 :-)

It's only later that I realised I had to select the Target platform, which was by default set to CF.NET 1.0. After I picked .NET 2.0, LLBLGen Pro automagically created the project files and all I had to do was open them and build!

Somebody ought to see the U.I. guys about setting the default Target platform to .NET 2.0 :-)

I believe this has been fixed before, so most probably you are using an old version.

nitin.reddy wrote:

The first time I used LLBLGen Pro, I got a bunch of source code files. I added them to a project, added references and tried to compile them without much luck. (Did I mention that I used the standard Ok-Next-Finish philosophy when selecting the options in Generate?)

It's only later that I realised I had to select the Target platform, which was by default set to CF.NET 1.0. After I picked .NET 2.0, LLBLGen Pro automagically created the project files and all I had to do was open them and build!

Somebody ought to see the U.I. guys about setting the default Target platform to .NET 2.0 :-)

We realized this was pretty dumb indeed and made .NET 2.0 the default platform in v2.5 .

Yes, I'm running LLBL Gen Pro v2.0.0.0 (July 6th, 2007).

A couple of developers at the firm I work at used this version before, so I'm hoping to catch up with concepts using this version and then switch to a newer version.