New project structure in 5.4

Posts   
 
    
acl
User
Posts: 91
Joined: 28-Mar-2012
# Posted on: 17-May-2019 11:47:43   

Hi,

I have about 100 LLBLGen Projects (using LLBLGen Pro Runtime Framework with adapter) that I need to migrate from 5.0 to 5.5 and just noticed a major change in the project structure that came with version 5.4.

Here is the change I'm talking about:

From: https://www.llblgen.com/Documentation/5.4/LLBLGen%20Pro%20RTF/migratingcode.htm

Adapter: the cs/vbproj files generated for .NET full for DbGeneric/DbSpecific VS projects are now generated in the DbGeneric / DbSpecific folders and not in the root folder. The preset will actively remove the original files and generate new ones in the new locations. It's recommended to move the vb/csproj files manually to the DbGeneric and DbSpecific folders respectively prior to generating the v5.4 code on top of an existing code base so the code generator will instead of generating new ones, augment the existing ones. This change brings it in line with the .NET standard setup of the code base and makes the projects more suitable for using Nuget packages without conflicts.

What can we do to avoid this change? Can we do something to our templates? Or is it conceivable to have a parameter that reverts the code generator back to the old behavior?

I really do not see any advantage to this change. We have been using NuGet for years just fine with the old structure (you just have to rename the packages.config file).

This migration is very painstaking, more so if there are about 100 projects to be migrated (not all at once, but as time goes by). Each one of these is under source control. So it's not like you can just move some files around. Also the references inside these files will break, and so on.. frowning

Any help would be great!

Thanks,

acl

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39588
Joined: 17-Aug-2003
# Posted on: 18-May-2019 09:33:54   

There were 2 problems: 1) the netstandard projects are in different locations (inside the dbspecific/generic folders) than the netfull ones and this is required otherwise nuget fails. 2) nuget actually fails when you have the same package referenced in both csproj files: you have to manually reference the assembly in one of them. This has been a pain for years so with the clean up of the code base as a whole we decided to make this move. With more and more people using nuget, this problem needed addressing so we did this in one go.

I can understand this is a pain for you with 100s of projects. I'd still migrate them to the new stuff to stay on the standard templates/presets, but if you think this is too much work, you can revert to the old location of the csproj files.

First open the project settings and specify a folder for 'Additional Tasks folder'. This will be the folder the preset will be saved in.

Open the presets viewer in the designer and select 'LLBLGen Pro Runtime Framework', then select the sd.presets.adapter.general preset and click 'Copy as new'. This gives you your own copy. Select the folder you've specified for 'additional tasks folder' and specify a unique name to save it.

Scroll down to line 176: <taskPreset name="SD.Tasks.Adapter.VsNetDbGenericProjectFileCreator">

Add the following line within the <parameters> element: <parameter name="destinationFolder" value=""/>

What this does is that it sets the parameter for destinationFolder of the task SD.Tasks.Adapter.VsNetDbGenericProjectFileCreator in SD.Tasks.Adapter.tasks, to an empty folder at generation time. It otherwise will pick the default value which is [dbGenericSubFolder].

Do the same for the dbspecific task in the preset at line 224. Then save it.

When generating code, you should now select your new preset and the csproj files should be generated in the rootdestination folder like before.

As Microsoft only invests time in the new csproj project format, we recommend to pick the new csproj format by using netstandard as the generated output and e.g. specify multiple target frameworks in the csproj xml file. This makes sure the code is ready for whatever new tooling microsoft comes up with.

Frans Bouma | Lead developer LLBLGen Pro
acl
User
Posts: 91
Joined: 28-Mar-2012
# Posted on: 18-May-2019 09:44:41   

Only here will you see the lead developer himself answering forum posts on a Saturday morning simple_smile

Thank you, Frans!

Thanks also for explaining the rationale for this change, I understand now. I'll try to implement your suggestion. This will buy me time on many of the small projects. Btw. I never had problems with NuGet, also when referencing the same NuGet Package in both projects (which I do).

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39588
Joined: 17-Aug-2003
# Posted on: 19-May-2019 10:09:43   

acl wrote:

Only here will you see the lead developer himself answering forum posts on a Saturday morning simple_smile

smile

Thank you, Frans! Thanks also for explaining the rationale for this change, I understand now. I'll try to implement your suggestion. This will buy me time on many of the small projects. Btw. I never had problems with NuGet, also when referencing the same NuGet Package in both projects (which I do).

Yeah it will at least not force you to make the transition when you actually want to make another change simple_smile

About the nuget problems: if you generate code with 5.3, and have both projects in a sln, then add the ormsupportclasses package from nuget to one of them, adding it to the second one isn't possible as nuget says it's already installed (as the packages.config file in the sln folder says so). So you then had to manually reference the dll from the package folder. At least that's what we heard from customers and what we experienced ourselves too. It's not a terrible problem to overcome but not the smoothness we want so we changed it. I wished we didn't have to make these changes but alas, you can't predict the future...

Frans Bouma | Lead developer LLBLGen Pro
acl
User
Posts: 91
Joined: 28-Mar-2012
# Posted on: 21-May-2019 09:34:58   

We did as you suggested and it seems to work fine. Thanks! Just one more thing we had to do was remove the following line from the preset:

<taskPreset name="SD.Tasks.Base.FileRemover" displayName="Remove DatabaseGeneric vs project file in old location" requiresCleanCache="false">

For otherwise the vbproj files will be deleted and created from scratch, which results in things getting lost.

Btw. regarding NuGet: what we always do is rename the packages.config files to include the project name. Like this:

packages.Project.Library.config --> goes with Project.Library.vbproj packages.Project.LibraryDBSpecific.config --> goes with Project.LibraryDBSpecific.vbproj

This way, there are **two **packages.config files in the same folder, one per project, and NuGet distinguishes them just fine.

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39588
Joined: 17-Aug-2003
# Posted on: 21-May-2019 10:37:37   

acl wrote:

We did as you suggested and it seems to work fine. Thanks! Just one more thing we had to do was remove the following line from the preset:

<taskPreset name="SD.Tasks.Base.FileRemover" displayName="Remove DatabaseGeneric vs project file in old location" requiresCleanCache="false">

For otherwise the vbproj files will be deleted and created from scratch, which results in things getting lost.

Oops sorry about that! I overlooked that task.

Btw. regarding NuGet: what we always do is rename the packages.config files to include the project name. Like this:

packages.Project.Library.config --> goes with Project.Library.vbproj packages.Project.LibraryDBSpecific.config --> goes with Project.LibraryDBSpecific.vbproj

This way, there are **two **packages.config files in the same folder, one per project, and NuGet distinguishes them just fine.

ah didn't know that! Thanks for sharing simple_smile

Frans Bouma | Lead developer LLBLGen Pro