The designer generates separate projects for the Model and the 'Persistence layer'. The persistence layer consists of nothing more than the DbContext and the custom ModelBuilder for EF Core.

For me it makes little sense to have a separate project for this because I already have a separate business object project that has a subclass of the generated DataContext so that I can add application specific functionality. In this case I have custom auditing hooked into my DB.

For this use case the extra project for the DbContext is kind of a pain unless I want to add a project with two files which I'd like to avoid. As it stands at the moment I have to explicitly copy the files from the persistence project into the model (or potentially the business object project).

Is it possible to have the DbContext and Model Builder generated into the Model project along side the entities as an option. I totally get why you might want separate projects, but it would make my life a lot easier if I can generate everything into a single project.

+++ Rick ---

If you want everything in the same csproj, you can

In the designer open the preset viewer, (Tools ->Preset viewer). Select the framework you want to use (it preselects the one used in the project).

Then select the preset you're using when generating code. Then click on the right -> Copy as new... In the dialog specify a new name and new filename and hit OK

It will be opened in the xml editor. In there are two task groups. Say you altered the entity framework core 2.2 for netstandard preset. you'll see one task group with description "Generate Entity Framework Domain model with POCO entities" and further down one with description "Generate Entity Framework Database specific code and code first mapping file using DbContext API and POCO entities"

You now move the three SD.Tasks.Base.ConsumeLptTemplate tasks in the second group to the first group, above the "SD.Tasks.Base.GenerateVSNetProject" task at the bottom of that first group. This makes sure all files generated by these 3 tasks are known when the csproj file is generated/altered. In practice this isn't that important anymore as csproj files nowadays don't contain the files anymore but it's good practice to keep the order in which the files should be generated.

Then remove the second task group and save the preset using ctrl-shift-s.

I didn't change the folder layout. If you want to have different folders, you can change them in the preset as well: all <parameter name="destinationFolder" value="..." /> definitions contain the target folder. E.g. remove 'Model' and 'Persistence' in the tasks to have everything in the destination folder.

You should now be able to use your new preset to generate code in a single folder with a single csproj

Thanks Frans. That worked but it took some doing doing due a few UI issues.

Let me say up front though - the process itself in the presets is very nicely thought out. I was able to keep the app.config and project file generation from happening and dump the context and modelbuilder into my model project.

Sweet.

Some feedback here:

• I had a hard time creating a new preset
• First I tried to save the default:
  • Failed because - Program Files Permissions
  • Naming - Copy is not great (Maybe prompt for a better name?)
  • When I tried to manually rename the preset on disk, LLBG didn't find the preset (in user Tasks) - never was able to load it? See attachment.

It's probably not a good idea to save anything into Program Files, first because of permissions, and second because you're likely to forget and not move it to another machine or whereever.

Lost file is probably my fault, but still a bit odd - it was there and I was working on it (even after rename) - then loaded one of the orig presets, tried to reload and - nada.

In the end I threw away my original preset I had created because it just wasn't showing up i n the list and then very carefully went through and recreated a new one with a proper name, and turning off options more selectively. (Good learning experience, but not very user friendly :-))

In the end I got it to work and that's the important part... thanks...

+++ Rick ---

rstrahl wrote:

Thanks Frans. That worked but it took some doing doing due a few UI issues.

Let me say up front though - the process itself in the presets is very nicely thought out. I was able to keep the app.config and project file generation from happening and dump the context and modelbuilder into my model project. Sweet.

The system isn't very straightforward but it indeed is flexible and once you know what to do it's powerful. (More info in the sdk docs btw: https://www.llblgen.com/Documentation/5.6/SDK/GeneratorandTasks.htm )

Some feedback here:

• I had a hard time creating a new preset
• First I tried to save the default:
  • Failed because - Program Files Permissions
  • Naming - Copy is not great (Maybe prompt for a better name?)
  • When I tried to manually rename the preset on disk, LLBG didn't find the preset (in user Tasks) - never was able to load it? See attachment.

It's probably not a good idea to save anything into Program Files, first because of permissions, and second because you're likely to forget and not move it to another machine or whereever.

True, hence we have the additional folders in mydocuments to overcome the program files issue. We should probably move to not pre-selecting that by default. I'll make a workitem to have that changed.

There's a button in the designer to reload the code generation config files (Tools -> Refresh code generation meta data). We don't poll the folders for changes so it's a manual task. This is needed when you rename a file on disk, as the designer doesn't see the change, you then have to tell it to scan for the files again. We could opt for a filesystem watcher in this case but I'm personally not a fan of these, however they could make life a little easier indeed.

the 'copy' suffix is enforced to have a default different name than the one you copy from, so users won't click ok and overwrite an exiting file by accident or have something with the same name. The name can be changed in the copy-as-new dialog, so I'm not sure if we need another popup for the name?

The main problem with the copy / new preset files is that they have to be in scope of the designer. So in older versions we had no enforcement of target folder and people could save these files wherever and then they weren't loadable as the folder they were in wasn't an additional task folder in the settings so the designer didn't know about it.

Lost file is probably my fault, but still a bit odd - it was there and I was working on it (even after rename) - then loaded one of the orig presets, tried to reload and - nada.

In the end I threw away my original preset I had created because it just wasn't showing up i n the list and then very carefully went through and recreated a new one with a proper name, and turning off options more selectively. (Good learning experience, but not very user friendly :-))

Thanks for this feedback! I recon if there had been a filesystem watcher on this, you'd not have this problem I think as the file you renamed on disk would have been loaded automatically?