Project-system: DataSet designer error in .net standard 2.0 library

[vsfeedback]

1. Create .NET Standard 2.0 Library
2. Add a new item - DataSet
3. Error - System cannot be referenced
   (of course - not work)

_This issue has been moved from https://developercommunity.visualstudio.com/content/problem/63351/dataset-designer.html
VSTS ticketId: 444396_
_These are the original issue comments:_

John Hart [MSFT] on 01/06/2017, 02:48 AM (543 days ago): Thank you for reporting this issue to us. We have changed the title to better describe the problem so others can find and engage with it
Lucy Yang [MSFT] on 01/06/2017, 06:14 PM (542 days ago):

Thank you for providing feedback on Visual Studio, we're investigating the issue you reported.

Norman Hadfield on 04/10/2017, 06:55 PM (417 days ago):

I also get this in 15.3.5 but the designer does load and you can work with it. However the csproj structure doesn't seem to be right as its lacking the 'dependantupon' entries for the xsc and xss files etc. Also the MSDataSetGenerator doesn't generate the designer code so you cant compile.

Norman Hadfield on 05/10/2017, 08:20 AM (417 days ago):

Modifying the csproj file seems to sort out the structure but the code behind is never generated. This post seems to identify the problem - the custom tool MSDataSetGenerator is never run in Net Standard projects.

https://github.com/dotnet/project-system/issues/2687

Matt Comstock on 13/12/2017, 11:35 AM (347 days ago):

I'm getting it too, on VS 2017 15.5.1. I'm hoping I can simply generate the designer code in another type of project.

William Ziebell on 20/12/2017, 09:16 AM (341 days ago):

Seeing the same issue. Posted a Stackoverflow question, see https://stackoverflow.com/questions/46467682/encrypting-connectionstrings-section-in-net-core-2

[davkean]

A few things here;

• We need to decide what do about templates that add "old style" references. If we remove these references, they'll no longer build in a project without these references.
• We need to figure out why the code behind doesn't actually generate - I suspect there's some issues around when we run the generator - probably being tracked by CPS.

[davidwengier]

In d16.0stg the code behind does generate (though doesn't compile) but there are still quirks, like double clicking the designer surface generates a DataSet1.cs file that is blank, or has multiple namespace declarations by no class declaration.

.NET Core exhibits the same problem with DataSet1.cs, but as above the code behind generates fine, in this case also compiles fine.

[davidwengier]

In Dev16 the designer file generates correctly, and manually adding a Nuget reference to System.Data.DataSetExtensions allows the library to build.

[davidwengier]

Template issue is probably a dupe of #4486

[davidwengier]

4486 has fixed the error that pops up, and all files are generated correctly.

The only remaining issue is that the templates have no way of referencing System.Data.DataSetExtensions, so its a manual operation for the user to add from Nuget.

[davkean]

How are we going to address that? Perhaps have a way for a template to add a PackageReference?

[davidwengier]

I'm not sure. Specifying a PackageReference seems good, but there would presumably be issues around versioning - we wouldn't want to put the version number into the template - and it may bring back the problem of need to perform different steps for different target frameworks, as .NET Framework doesn't need the Nuget package.

[davkean]

@terrajobst @nguerrera @dsplaisted ^

[davkean]

Either we fork the template, or we have a way to mark a reference for a particular framework. The version number situation is very interesting, and agreed putting a version number in them sounds like constant churn.

[davidwengier]

Turns out there is already support for Nuget packages in templates via NuGet.VisualStudio.TemplateWizard, see the SignalR template for example (MS Internal only). The versioning question remains, SignalR (and other ASP.NET) templates seem to use hardcoded versions

[terrajobst]

@davkean

How are we going to address that? Perhaps have a way for a template to add a PackageReference?

For .NET Core 2.1, there is a NuGet package System.Data.DataSetExtensions. For .NET Core 3.0, it's part of Microsoft.NETCore.App and thus referenced by default. /cc @divega

[divega]

@terrajobst I believe we missed adding a couple of types from System.Data.DataSetExtensions that would have allowed the generated code to build for on a .NET Standard 2.1 project: TypedTableBase<T> and EnumerableRowCollection<T>.

[davidwengier]

Confirmed that for .NET Core 3 this just works now.

[divega]

Confirmed that for .NET Core 3 this just works now.

Same here, and confirmed that for .NET Standard 2.1 the generated code doesn’t build.

[terrajobst]

@divega

That sucks. Could you submit a PR for the missing APIs (or just gimme the list)? I'm willing to take them to ship room.

[divega]

@terrajobst TypedTableBase<T> and EnumerableRowCollection<T> are the ones I found if I add mock versions of them the project the code compiles. But presumably these are just the tip of the iceberg.

In https://github.com/dotnet/corefx/pull/36528, I remember we ended up pulling all of System.Data.DataSetExtensions into System.Data.Common in the framework in .NET Core 3.0 (that is why the generated code works on if the project targets .NET Core 3.0), but I cannot remember if we did anything there that would prevent the types from being added to .NET Standard.

See https://github.com/dotnet/corefx/pull/36528#discussion_r271427614 for more details. Also,
@ericstj worked on that PR, and maybe he has some insight on this.

[terrajobst]

I've submitted a PR to add the types listed in the @ericstj's CoreFX PR.

[terrajobst]

The change to .NET Standard 2.1 is merged and will go out post-preview9. My expectation is that this should address this issue.

[tmeschter]

At this point you can add a DataSet to a .NET Standard 2.1 or .NET Core 3.0 library, add items to the design surface, and everything will generate and build just fine.

If you add a DataSet to a .NET Standard 2.0 project, the item will be added and the generator will run correctly, but you will get errors about missing types when you build. This can be fixed by adding the System.Data.DataSetExtensions package; the latest stable version at this time is 4.5.0.

I'm attempting to see if there is a way to add this package automatically when adding an item to a .NET Standard 2.0 project.

[tmeschter]

I don't see a way to conditionally include a package, unfortunately.

Given that this is working for .NET Standard 2.1 and .NET Core 3.0 and later, I'm going to close this issue.