LLBLgen 5.0.4 SelfServicing

I think this is easier to explain and understand with some made up names.

Scenario: We have the following repositories Company.Data (LLBLgen generated code) Company.Cache Company.Shop Company.Content Company.Education Company.Frontend

All repositories have one project and generate a nuget package. Cache uses Data Shop, Content, Education use Data and Cache Frontend uses all of the above.

Currently we need to update all projects when a new version of Company.Data is made to not get issues with wrong prefetch paths because they depend on enums in constantsEnum.cs - etc EntityType enum.

(We currently have 9 of such projects we need to update)

I was thinking that we could get away with that need if the enums always kept there values on code regeneration. Both when a table/field is added or removed.

Is it as simple as that? Is it doable with a setting or custom templating atm? Will it be possible in the future?

Best regards, Jacob

I'm not sure I'm following.

You are using enum say..EntityType in projects that reference the generated code. And you use an enum like this, even if you want the integer value....

EntityType.CustomerEntity or (int)EntityType.CustomerEntity

Either way, if the CustomerEntity position has changed after code regeneration, you are still reference it by name, so the position or integer value wouldn't matter.

Now, if the customer table has been dropped from the database, and hence the CustomerEntity, and then the EntityType enum will drop the CustomerEntity, you should go back to your referencing projects and take care of any CustomerEntity reference, whether using the EntityType enum or in general. Code compilation will report all the bas references then.

So I'm not sure what you need to do or what you mean by letting the enum keep the values across code generations.

I think it's related to the notion that if you have an enum E in assembly A1 with fields X, Y and Z, then Y is '1', and if you use E in an assembly A2, the compiler will hardcode 1. If you then insert a value in front of X into E, Y will become 2 in A1, but will still be 1 in A2 unless you recompile A2. I think the question is to avoid that recompiling of A2, correct?

I think it's related to the notion that if you have an enum E in assembly A1 with fields X, Y and Z, then Y is '1', and if you use E in an assembly A2, the compiler will hardcode 1. If you then insert a value in front of X into E, Y will become 2 in A1, but will still be 1 in A2 unless you recompile A2. I think the question is to avoid that recompiling of A2, correct?

Thats correct

I'm afraid that it's not doable. It might look doable when the order is kept the same (so new ones are added at the end), but if one is removed, that slot has to be kept (otherwise everything is moved up) so that leads to a lot of crap over time.

With enums a hard-coded value could be given to an enum element, which at first looks like a good idea, but that too leads to crap over time, with the field list of an entity using numbers that don't make any sense due to the field removals/additions.

I kind of understand your view. But giving that the current solution costs some hours 2-4 times a month i'll try to persuade you a bit.

Personally I would be happy with a solution where we need a rule saying. If Column or Table is removed. Update/Recompile everything.

As in everything new should be added last in the list.

For hard-coded values We don't use the int values of the enums today. If the numbers are 5 or 4567 doesn't matter to us. (oh, Maybe this will be visible in the designer interface?)

jacob wrote:

I kind of understand your view. But giving that the current solution costs some hours 2-4 times a month i'll try to persuade you a bit.

How about this: you automate the generation of code, compilation of the generated code and the compilation of the depending projects? You can generate code on the command line with the cligenerator we include in the installer, compiling on the command line can be done with msbuild or dotnet.exe, packaging the packages can be done too and setting up the local nuget source for the packages just built will make sure the depending assemblies are rebuilt as well.

Personally I would be happy with a solution where we need a rule saying. If Column or Table is removed. Update/Recompile everything.

As in everything new should be added last in the list.

For hard-coded values We don't use the int values of the enums today. If the numbers are 5 or 4567 doesn't matter to us. (oh, Maybe this will be visible in the designer interface?)

The generated code will become a mess over time. The only thing that helps is hardcoded enum values, the other things won't: as removing a value from an enum will change all other values unless the value is kept, e.g. 'reserved1' etc. which is silly. Hardcoded values are an, albeit lame, option to solve this somehow, but a better way is to automate the builds.

You can even trigger this from within the designer with a small plugin you bind to a designer event (which can be done inside the designer with the UI), so you kick off the script that starts the builds when you e.g. save the project.

Here we have a script that automates the generation of all test code, builds the runtime libs, builds the test projects and runs the tests. Takes almost no code, just a few lines in a cmd file (or ps if you prefer).

Ok. Should be doable.

We already have part of this. We currently commit llblgenproj to git. Teamcity will generate, compile and publish nuget package.

Every project that depend on it will have their own repository and teamcity will build and publish to nuget.

The missing link is how to get the dependent projects to update automatically.

I'm not sure about this line. " local nuget source for the packages just built will make sure the depending assemblies are rebuilt as well. "

If you can point me in the right direction for this. It will be great. But its a bit outside of LLBLgen support, so fine if we close it here.

jacob wrote:

Ok. Should be doable.

We already have part of this. We currently commit llblgenproj to git. Teamcity will generate, compile and publish nuget package.

Every project that depend on it will have their own repository and teamcity will build and publish to nuget.

The missing link is how to get the dependent projects to update automatically.

I'm not sure about this line. " local nuget source for the packages just built will make sure the depending assemblies are rebuilt as well. "

If you can point me in the right direction for this. It will be great. But its a bit outside of LLBLgen support, so fine if we close it here.

You don't need to upload a package to nuget to consume it as a package locally. You can define any folder on disk as a nuget package source. These are defined in %AppData%\NuGet\NuGet.config. Type on a command line nuget sources and you see the sources defined. Inside vs 2017 -> tools -> options -> Nuget package manager -> Package sources you can add one with a gui if you want (or edit the file in a text editor if you want).

E.g. we use a local folder for the algorithmia packages, it builds them to that folder. dotnet.exe restore will automatically pull the packages from that folder if they've changed (new version number) so rebuilding a depending project will update it automatically. msbuild has a directive to restore too, simply us /r to restore packages.

So this should give you a quick rebuild pipeline without the necessity of waiting for nuget's utterly slow verification process, fully automated: just build everything after each other, the local package is there when the build of the depending projects starts