I have a Net6 project that I'm using with LLBLGen. I generate a DLL containing Enum versions of all of the lookup status tables in the DB, and I obviously need to use those Enums in both the business logic and the Designer. So I have a few questions:

1. What are the rules regarding creation of DLLs to provide Enums for use in the designer? Does the DLL have to be a .Net Framework v4.x, or can it be .Net standard or Net6 for the designer to recognise them?

2. is a typeimports entry required for every Enum in my library, or can the designer detect the Enums through reflection on the DLL?

3. since I appear to have to specify the 'additional type converter folder', shouldn't the designer let me choose a relative folder? When the code is checked out on different machines the folder will be different, so relative to the llblgenproj file is the logical location. At the moment it appears that if I add a relative path it is relative to the Designer EXE location?

Perhaps it would be better if custom types for Enum fields were detectable via an attribute, in the same way TypeConverters are recognised by class signature. The current system seems quite complicated, and I'd like to see a convention based option to avoid all the manual plumbing.

JSobell wrote:

I have a Net6 project that I'm using with LLBLGen. I generate a DLL containing Enum versions of all of the lookup status tables in the DB, and I obviously need to use those Enums in both the business logic and the Designer. So I have a few questions:

1. What are the rules regarding creation of DLLs to provide Enums for use in the designer? Does the DLL have to be a .Net Framework v4.x, or can it be .Net standard or Net6 for the designer to recognise them?

.net framework, .netstandard 2.0 (or lower) work. .NET Core 3.x/.NET 5+ doesn't, as it's not compatible with .net framework.

1. is a typeimports entry required for every Enum in my library, or can the designer detect the Enums through reflection on the DLL?

An entry is required. It was never anticipated that there would be hundreds of enums to import, and doing a reflection over a dll for all enums is potentially problematic, as it would import all enums, also the ones you don't want; this might not sound problematic at first, but every imported enum is assigned a type shortcut, which will make modeling with all the types problematic. So it's explicit at the moment.

1. since I appear to have to specify the 'additional type converter folder', shouldn't the designer let me choose a relative folder? When the code is checked out on different machines the folder will be different, so relative to the llblgenproj file is the logical location. At the moment it appears that if I add a relative path it is relative to the Designer EXE location?

There are two additional type converter folders: one in the Preferences and one in the Project settings (Entity Model -> General). The one in preferences is an explicit path, as there's no project to base the relative path on. The one in Project settings is relative to the path if it's prefixed with .\. E.g. in our unit test projects we specify .\ to have the typeimport files next to the llblgenproj files.

Perhaps it would be better if custom types for Enum fields were detectable via an attribute, in the same way TypeConverters are recognised by class signature. The current system seems quite complicated, and I'd like to see a convention based option to avoid all the manual plumbing.

The attribute has to be defined somewhere, so that would mean a reference to the assembly the attribute is defined in in your enum dll. This is problematic as which attribute to pick? Even a BCL attribute is problematic, as a .net standard one is different from a .net framework one.

I agree it's cumbersome tho, but it is a cumbersome process regardless, the types to import have to be defined somewhere. One of the alternatives we tried was indeed simply importing everything and then let the user define type shortcuts, but this was a tedious process as well. I think the 'solution' might be somewhere else, namely why the enums are defined in the first place, but that has a bigger scope (see your other thread) and also a bigger impact (which likely won't be followed by many).

The type import files are now pretty strict. We could look into filters and wildcards. E.g. * for typename means all enum types, filters for namespaces (e.g. MyEnumNamespace, which means all enums inside that namespace... ).

OK, thanks for that.

I couldn't face writing a whole lot of T4 templates (as I've done in the past) so I hacked up a tool to generate all this stuff. https://github.com/jsobell/DBEnumCreator

I use this to create the Enums for the designer, application, and javascript all in one command. It's very cludgy but works for the immediate needs I have, and makes the whole process surprisingly painless. The only thing missing is a means of associating the generated enums automatically with the fields in the Designer.

I've added a readme just in case anyone else has a use for it, but feel free to use it for inspiration on a decent built-in feature if you like.

Thanks for sharing. Sorry for the inconvenience the current (rigid) system produces. We'll try to make it easier in the future.

Hi we renewed our Licences on the basis of your documentation saying that LLBLGen is compatible with .Net6.0 and EntityFramework 6. Now we find that we have a lot of difficulty in dealing with enums because LLBLGen V5.9.1 cannot read .Net60 dlls when specified in the typeimports files. Even the designer documentation doesn't mention this limitation. Are you going to provide a way of reading .Net60 dlls in the near future?

It's not possible for the designer to always support a DLL compatible with every library version, which is why I wrote the utility to generate the version shown above. I'd suggest you look at the utility I wrote, as I use it for every project I wrote. It generates the source for the enums in your code, let's you have db based copies of your enums (which is fantastic for views and reporting), creates the type library and DLL for the designer, and even creates JavaScript libraries in case you want them for your client. Ping me if you have any questions.

Ghostrider203 wrote:

Hi we renewed our Licences on the basis of your documentation saying that LLBLGen is compatible with .Net6.0 and EntityFramework 6. Now we find that we have a lot of difficulty in dealing with enums because LLBLGen V5.9.1 cannot read .Net60 dlls when specified in the typeimports files. Even the designer documentation doesn't mention this limitation. Are you going to provide a way of reading .Net60 dlls in the near future?

The designer is .net 4.8 and that's likely to stay that way. You can do what JSobell does (which is a nice solution), or multi-target your enum dll's csproj file. This way you get 2 versions of the dlls: one build for .net framework and one build for .net 6. As they originate from the same source and created when you build the project, they are always up to date. You use the .net framework one for the project in the designer and the .net 6 one in your generated code. These dll's don't have to be the same. The designer uses the dll's to gather types, nothing more. Enums aren't complicated things so you won't run into incompatibilities with code that's not compatible with .net framework.

example:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFrameworks>net6;net472</TargetFrameworks>
  ....

We tried to port the designer to .net 6 but there's just so much code to fix when we do (as we need to swap out libraries like the diagramming library and there's no equivalent one on .net 6) that we decided the gain is very little. The extensibility is a problem, but it's luckily relatively minor as the extensibility is usually not about code that uses .net 6+ constructs.