TypeConverters reference handling

Posts   
 
    
khorvat avatar
khorvat
User
Posts: 65
Joined: 17-Feb-2011
# 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

daelmo avatar
daelmo
Support Team
Posts: 8245
Joined: 28-Nov-2005
# 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 Support Team
khorvat avatar
khorvat
User
Posts: 65
Joined: 17-Feb-2011
# 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

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39763
Joined: 17-Aug-2003
# 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 | Lead developer LLBLGen Pro
khorvat avatar
khorvat
User
Posts: 65
Joined: 17-Feb-2011
# 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

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39763
Joined: 17-Aug-2003
# 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 | Lead developer LLBLGen Pro