Using LLBLGen Pro 5.11.3, just upgraded from 5.9

When I open my llblgen project file, the designer has lost all information about my enumerations, previously imported with a .typeimports file. Hence, the <TypeShortcuts> section is modified like e.g:

<TypeShortcut Shortcut="DiskUsageType" Type="NHL.Admin.DataModelEnumerations.DiskUsageType, NHL.Admin.DataModelEnumerations" /> changes to <TypeShortcut Shortcut="DiskUsageType" Type="System.String" /> (along with the remaining other 9 enumerations, all converted from the correct type to System.String.

In project settings, under Entity Model -> General -> Additional type converter folder, I have (for many years now) had the value ".\NHL.Admin.DataModel\LLBLGen Type Converters" to indicate the folder where I copy my compiled dll file and the handcrafted .typeimports file to. However, under Tools -> View loaded external types... the expected enumeration types are not visible, so I'm guessing the designer cannot see the typeimports or load the dll. There are no errors in "Application Output".

Clicking "Re-scan for TypeConverters and .typeimports files" does not help, and does not result in any errors. Nothing happens.

If I change the path in "Additional type converter folder" to just ".\" and copy the .typeimports and .dll files to the "root" folder of my project, where the .llblgenproj file resides, and then clicks "Re-scan for ..." again, the Application Output lists the types as expected, and they appear in the Tools -> View loaded external types window. If I try with an absolute (Fully qualifyed) path instead of ".\" it also doesn't work.

So, since I dont how when I added an enumeration last (correlated to which version of LLBL Gen I had at that time) I'm not entirely sure if it actually worked in 5.9, but it looks like having anything other than ".\" in the "Additional type converter folder" just doesn't work.

I can use the workaround of moving the files for now, but I think there is an error.

Is it important if I compile the enumerations dll with 4.8 or 4.8.1 - and why can't I select 4.8.1, but only 4.8.0 under "Generate code"?

On a side note: As mentioned https://www.llblgen.com/tinyforum/Thread/27070/1 and https://www.llblgen.com/tinyforum/Thread/26914/1 we have discussed a way to avoid having VS build interrupted by a locked .typeimports dll file. Any news in that direction? I'm guessing I would vote for a solution where I can copy the dll at any time with a post-build step, and LLBLGen will try to copy from the specified source location to its own shadow copy location, which will fail if the dll is already loaded. Then I can have LLBL Gen open and do VS builds, and only if I need to add new enumeration, I have to restart LLBLGen in order for the designer to release the loaded shadow dll, and copy a fresh one upon restart.

BR, Jan

So, I just found this

Prior to v5.10, the designer would load all .typeimports files found in the folders for type converters, whether they were specific for the currently loaded project or not. Starting with v5.10, the designer will load all .typeimports files which either don’t contain any “.llblgenproj” in the filename (so are generic files not specific for a project) or are specific for the currently loaded project (so currently loaded project filename.typeimports)

here: https://www.llblgen.com/Documentation/5.11/Designer/BreakingChanges.htm

I read that like: we will load <anything-not-containing .llblgenproj>.typeimports AND <currently-loaded-projectname.llblgenproj>.typeimports

Hence, my files being named NHL.Admin.DataModel.llblgenproj.typeimports and NHL.Admin.DataModel.llblgenproj accidentally matches the very specific naming desires, and should therefore be loaded. But still, only happens from the "root" folder.

Me, choosing that very particular naming principle years ago, and you, "requiring" it... what can I say - "great minds think alike"

/Jan

the change was mainly meant for multiple projects and typeimports being in the same folder causing problems as loading ProjectA.llblgenproj with a typeconverter folder Foo with 2 typeimport files would load both typeconverter files, even if they're not really for ProjectA.llblgenproj. So this has become more restrictive.

I understand that, and I'm sure its a great idea

However, there still is an error there, right?

Even though my .typeimports file is named exactly as it should be (given that it contains .llblgenproj) it only gets loaded if it is next to the project file and the path is set to ".\". So from my perspective, it is not possible to specify a relative subfolder.

Ah I see now. Hmm, might be indeed that we have an issue with relative paths in the check code. As I requested your project and typeimport files in your other thread, I think we can use those to test for this issue as well and look into it why it won't load the right files.

I also see we forgot to answer some questions in the start post:

Is it important if I compile the enumerations dll with 4.8 or 4.8.1 - and why can't I select 4.8.1, but only 4.8.0 under "Generate code"?

As 4.8.1 didn't introduce any relevant change we didn't add another framework version, also because 4.8.1 and 4.8 both target .NET 4.0 versioned assemblies (all .net framework v4.x versions have the same version: v4.0, so no binding redirects have to be implemented, but also no breaking changes can be released)

On a side note: As mentioned https://www.llblgen.com/tinyforum/Thread/27070/1 and https://www.llblgen.com/tinyforum/Thread/26914/1 we have discussed a way to avoid having VS build interrupted by a locked .typeimports dll file. Any news in that direction? I'm guessing I would vote for a solution where I can copy the dll at any time with a post-build step, and LLBLGen will try to copy from the specified source location to its own shadow copy location, which will fail if the dll is already loaded. Then I can have LLBL Gen open and do VS builds, and only if I need to add new enumeration, I have to restart LLBLGen in order for the designer to release the loaded shadow dll, and copy a fresh one upon restart.

We investigated if we should do imports of types using a shadowcopied version, but it caused quite a lot of complexity as we need to keep track of the original folder so we kept it on the back burner, also because there's an easy work around

Reproduced, it does a comparison at path level, but includes the folders, which is obviously wrong. Will fix it

Fixed in hotfix builds 5.10.6 and 5.11.4

Otis wrote:

Fixed in hotfix builds 5.10.6 and 5.11.4

Awesome - thank you