c#, DataSet and CLS Compliance

[news.microsoft.com]

The question is, is a DataSet CLS compliant?

Minimally implemented code, with an attribute [assembly:
CLSCompliantAttribute(true)] in the assemblyinfo.cs compiles just fine (is
it possibly the data INSIDE the dataset that could invalidate its
compliancy?):

using System;
using System.Data;

namespace ConsoleApplication1
{
/// <summary>
/// Summary description for Class1.
/// </summary>
class Class1
{
/// <summary>
/// The main entry point for the application.
/// </summary>
[STAThread]
static void Main(string[] args)
{
Class2 class2 = new Class2();
DataSet newDs = class2.getDataSet();
}
}
}

using System;
using System.Data;

namespace ConsoleApplication1
{
/// <summary>
/// Summary description for Class2.
/// </summary>
public class Class2
{
public Class2()
{
//
// TODO: Add constructor logic here
//
}

public DataSet getDataSet()
{
DataSet newDS = new DataSet("newDatSet");
return newDS;
}
}
}

However, earlier today I was thinking:

Evidence seems to indicate that they Datasets are not CLS compliant.
In Googling, I found a few comments like:

Eventually, I wound my way to the ECMA site
(http://www.ecma-international.org/)

List: http://www.ecma-international.org/publications/standards/Standard.htm
C# Standard:
http://www.ecma-international.org/publications/standards/Ecma-334.htm (CLS)

From Appendix D Standard Library I culled the following namespaces:
// Namespace: System, Library: BCL
// Namespace: System, Library: ExtendedNumerics
// Namespace: System.Collections, Library: BCL
// Namespace: System.Diagnostics, Library: BCL
// Namespace: System.Globalization, Library: BCL
// Namespace: System.Security, Library: BCL
// Namespace: System.Security.Permissions, Library: BCL
// Namespace: System.Text, Library: BCL
// Namespace: System.Threading, Library: BCL

(Note there is no System.Data namespace)

My speculation trail is rather short. If the intent of CLS is to promote
cross-platform development and cross language development then how do you
tell java or small talk or any non-ms type language what a DataSet is?

This is not to say that a DataSet cannot be used privately, it's just that a
DataSet type cannot be exposed in any public member.

FWI, this is an inferred conclusion. I have not seen anything concrete that
says yea or nay.


Thoughts appreciated. Thanks!

Rob

 

[Mickey Williams]

The question is, is a DataSet CLS compliant?

Yes. CLI inclusion is a separate issue from CLS compliance.

--
Mickey Williams
Author, "Microsoft Visual C# .NET Core Reference", MS Press
www.servergeek.com

Minimally implemented code, with an attribute [assembly:
CLSCompliantAttribute(true)] in the assemblyinfo.cs compiles just fine (is
it possibly the data INSIDE the dataset that could invalidate its
compliancy?):

using System;
using System.Data;

namespace ConsoleApplication1
{
/// <summary>
/// Summary description for Class1.
/// </summary>
class Class1
{
/// <summary>
/// The main entry point for the application.
/// </summary>
[STAThread]
static void Main(string[] args)
{
Class2 class2 = new Class2();
DataSet newDs = class2.getDataSet();
}
}
}

using System;
using System.Data;

namespace ConsoleApplication1
{
/// <summary>
/// Summary description for Class2.
/// </summary>
public class Class2
{
public Class2()
{
//
// TODO: Add constructor logic here
//
}

public DataSet getDataSet()
{
DataSet newDS = new DataSet("newDatSet");
return newDS;
}
}
}

However, earlier today I was thinking:

Evidence seems to indicate that they Datasets are not CLS compliant.
In Googling, I found a few comments like:

Eventually, I wound my way to the ECMA site
(http://www.ecma-international.org/)

List: http://www.ecma-international.org/publications/standards/Standard.htm
C# Standard:
http://www.ecma-international.org/publications/standards/Ecma-334.htm (CLS)

From Appendix D Standard Library I culled the following namespaces:
// Namespace: System, Library: BCL
// Namespace: System, Library: ExtendedNumerics
// Namespace: System.Collections, Library: BCL
// Namespace: System.Diagnostics, Library: BCL
// Namespace: System.Globalization, Library: BCL
// Namespace: System.Security, Library: BCL
// Namespace: System.Security.Permissions, Library: BCL
// Namespace: System.Text, Library: BCL
// Namespace: System.Threading, Library: BCL

(Note there is no System.Data namespace)

My speculation trail is rather short. If the intent of CLS is to promote
cross-platform development and cross language development then how do you
tell java or small talk or any non-ms type language what a DataSet is?

This is not to say that a DataSet cannot be used privately, it's just that a
DataSet type cannot be exposed in any public member.

FWI, this is an inferred conclusion. I have not seen anything concrete that
says yea or nay.


Thoughts appreciated. Thanks!

Rob

 

[Rob Waggoner]

Yes. CLI inclusion is a separate issue from CLS compliance.
I'm sorry, I'm not sure what that means. Would you be kind enough to expound
just a bit more?

Thanks.
Rob

 

[Mickey Williams]

I'm sorry, I'm not sure what that means. Would you be kind enough to expound
just a bit more?

The Common Language Interface is specification.
The Common Language Runtime is an implementation of the CLI spec, as is the
work done by the SSCLI team at Microsoft, and the Mono team over in
open-source land.

The CLI covers the minimum behavior and class libraries that are required
for a .NET platform to be conforming - so you can depend on specific
behavior for core APIs and classes. However, some of the CLR (as well as
some of the SSCLI and Mono implementations) is not covered by the CLI, so
code that uses Windows Forms, or ADO.NET might not run on a cross-platform
implementation of the CLI.

These issues are separate from Commmon Language Specification (CLS)
compliance. CLS is used to ensure that C#, Visual Basic .NET, Eiffel, and
other .NET languages can have a consistent way of using types and
components. It describes how constructors are called, how types are named,
specifies types that must not be exposed outside an assembly, etc. For
example, unsigned scalars are non-compliant other than System.UInt16 (byte).