As part of a specialised build tool, I need to use a Generator object. However, it appears to require an ApplicationConfiguration object in order to do anything, which seems very tightly bound to LLBLGen's innards. I've managed to create a simple wrapper that does the job of locating the installed LLBLGen app and loads the configuration information, but instantiating ApplicationConfiguration will read from my app's config file, not LLBLGen's.

Is there any way around this? Am I even supposed to be using these parts of the API?

Only if the user of the software you're writing has a valid LLBLGen Pro license. You aren't allowed to distribute designer / code generator engine assemblies to a non-licensee.

I already discussed the legal aspects in another thread. This is an in-house tool only, so licensing isn't an issue.

The SDK docs don't seem to cover this part of the API, and if something's tied this strongly to the app's own config file I get the impression it's not supposed to be tinkered with. This isn't a huge problem (I can override the ConfigurationManager by using reflection) but it does make my code rather brittle should .NET's private internals ever change.

Alex wrote:

I already discussed the legal aspects in another thread. This is an in-house tool only, so licensing isn't an issue.

Ok (we've a lot of threads on the forum, so sorry for missing that detail)

The SDK docs don't seem to cover this part of the API, and if something's tied this strongly to the app's own config file I get the impression it's not supposed to be tinkered with. This isn't a huge problem (I can override the ConfigurationManager by using reflection) but it does make my code rather brittle should .NET's private internals ever change.

The SDK reference manual covers this api.

The simple thing you have to do is copy the necessary things into your own config file See as an example the commandline refresher and generator tools.

I think you should start with the commandl ine generator tool, in the SDK, as that tool also starts a generator cycle, loads a project etc. the things you need to do. It has its own config file with the necessary tags for making the assemblies of llblgen pro work

The problem with copying over the keys is that we then have to make the directories listed either absolute or relative to our tool's location. This isn't really possible, since we cannot guarantee a consistent location of either LLBLGen or our tool on the build machine.

I found a workaround involving reflection which swaps the configuration object used by ConfigrationManager for a custom one that references the installed LLBLGen Pro instance. It's not particularly nice, but it does the job remarkably well.

The command line tool does not do what we need. We need to be able to create a project, import tables, modify them programmatically, and then generate them. The GUI tool does certain integrity checking which we're circumventing (regarding the mapping of enumeration types to integer database fields, which doesn't really require any form of type conversion beyond casting and will otherwise require one TypeConverter per enumeration) and I assume the command line tool does too.

[edit] Gah, just found the SDK download (after managing to locate our login info ). That's going to make things a little easier from here on, although thus far I've managed to write a program that creates a project and generates code with no documentation besides the VS2005 autocomplete. Chalk another one up for LLBLGen's sensible design!