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.