Home
Help
Register
Log in

Search

 
   Active Threads  

You are here: Home > LLBLGen Pro > LLBLGen Pro Runtime Framework> Using a Generator object from outside LLBLGen
 

Pages: 1
LLBLGen Pro Runtime Framework
Using a Generator object from outside LLBLGen
Page:1/1 

  Print all messages in this thread  
Poster Message
Alex Davidson
User



Location:
Bristol, UK
Joined on:
18-Sep-2006 17:51:08
Posted:
21 posts
# Posted on: 04-Oct-2006 16:41:10.  
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?
  Top
Otis
LLBLGen Pro Team



Location:
The Hague, The Netherlands
Joined on:
17-Aug-2003 18:00:36
Posted:
38044 posts
# Posted on: 04-Oct-2006 18:09:53.  
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.



Frans Bouma
LLBLGen Pro / ORM Profiler Lead Developer | Blog | Twitter
 
Top
Alex Davidson
User



Location:
Bristol, UK
Joined on:
18-Sep-2006 17:51:08
Posted:
21 posts
# Posted on: 04-Oct-2006 18:28:39.  
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.
  Top
Otis
LLBLGen Pro Team



Location:
The Hague, The Netherlands
Joined on:
17-Aug-2003 18:00:36
Posted:
38044 posts
# Posted on: 04-Oct-2006 19:04:58.  
Alex Davidson wrote:
I already discussed the legal aspects in another thread. This is an in-house tool only, so licensing isn't an issue.

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

Quote:
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 Regular Smiley 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 Regular Smiley


Frans Bouma
LLBLGen Pro / ORM Profiler Lead Developer | Blog | Twitter
 
Top
Alex Davidson
User



Location:
Bristol, UK
Joined on:
18-Sep-2006 17:51:08
Posted:
21 posts
# Posted on: 09-Oct-2006 09:48:47.  
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. Laugh

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 Tongue). 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!
  Top
Pages: 1  


Powered by HnD ©2002-2007 Solutions Design
HnD uses LLBLGen Pro

Version: 2.1.12172008 Final.