Home
Help
Register
Log in

Search

 
   Active Threads  

You are here: Home > LLBLGen Pro > Architecture> TypeConverters reference handling
 

Pages: 1
Architecture
TypeConverters reference handling
Page:1/1 

  Print all messages in this thread  
Poster Message
khorvat
User



Location:
Osijek, Croatia
Joined on:
17-Feb-2011 14:47:25
Posted:
65 posts
# Posted on: 04-Apr-2017 11:07:23.  
Hi,

I have type converters distributed using NuGet packages so I'm not sure what is the proper way to register/point/etc. type converters inside LLBLGen project ?

If I try to use AdditionalTypeConverterFolder I need to update this on every Nuget version change.

Regards
Kristijan Horvat | Baasic Lead Developer | LinkedIn | Twitter  Top
daelmo
Support Team



Location:
Guatemala City
Joined on:
28-Nov-2005 23:35:24
Posted:
8022 posts
# Posted on: 04-Apr-2017 12:23:01.  
Hi Kristijan,

I don't understand the real problem. You have a project folder, in there you should have a .llblgenproj and a .net solution (along other folders, including the /packages), right? Something like:

/myproy
/scripts
         ...
/llblgen
    MyProy.llblgenproj
/code
     /dal
         ...
     /gui
         ...
    /packages
    MyProy.sln
     ...


Normally, your packages folder is relative to your .llblgenproj and your .sln files. Unless you manage your packages in a local central packages repository, which is also configurable.

Please elaborate more on what is your structure and your dilemma with additional type converters path.


David Elizondo
LLBLGen'ing (articles and code snippets) | linkedin | twitter
 
Top
khorvat
User



Location:
Osijek, Croatia
Joined on:
17-Feb-2011 14:47:25
Posted:
65 posts
# Posted on: 05-Apr-2017 09:03:20.  
Hi Daelmo,

main problem with NuGet approach is the fact that path to NuGet contains the version number, and in case NuGet is upgraded then the path is broken and I need to setup the path again.

So I'm asking is there any other better approach to overcome this?

Thanks
Kristijan Horvat | Baasic Lead Developer | LinkedIn | Twitter  Top
Otis
LLBLGen Pro Team



Location:
The Hague, The Netherlands
Joined on:
17-Aug-2003 18:00:36
Posted:
37186 posts
# Posted on: 06-Apr-2017 10:17:46.  
Hmm. it's a problem that doesn't have an easy solution I think. Does the API change a lot / type converters inside a dll? The designer only needs to see the types and uses the CanConvertTo/From methods. If these are rather stable, you can use a dll on a known location which contains these types. With the generated code you then refer to the nuget packages (with the same types/signatures, but with the actual conversion code up to date) which are versioned through nuget.

Are these converters very special or e.g. tied to enums? As the runtime itself has a lot of type converters built-in so it's often no longer needed to use an external type converter: for enums you can simply import the types in a typeimports file, so no typeconverter is needed for enums as well.


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



Location:
Osijek, Croatia
Joined on:
17-Feb-2011 14:47:25
Posted:
65 posts
# Posted on: 06-Apr-2017 10:37:20.  
Hi,

type converters are not related to enums, right now I have just a few and they don't change a log so this was more of a general question on how to handle this kind of type converter registrations.

For now we are pointing to NuGet package folder (which has specific version defined in the path) and this will work until first change so if there is any better way please advise.

Thanks
Kristijan Horvat | Baasic Lead Developer | LinkedIn | Twitter  Top
Otis
LLBLGen Pro Team



Location:
The Hague, The Netherlands
Joined on:
17-Aug-2003 18:00:36
Posted:
37186 posts
# Posted on: 07-Apr-2017 09:49:53.  
No there's no other way as the designer works with paths without wildcards. Wildcards is what you need which aren't supported here. A junction also doesn't work as it also needs a fixed path, so you can't create a link to the new folder based on a wildcard...

Frans Bouma
LLBLGen Pro / ORM Profiler Lead Developer | Blog | Twitter
 
Top
Pages: 1  


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

Version: 2.1.12172008 Final.