.NET Standard version

Jan 23 at 11:39 AM
Hi ichbin,

It's really great to see that you are moving over to a more portable solution, by adopting .NET Standard.

I had a look in the latest source code commit, and I notice that you are currently targeting .NET Standard 1.1.

Are you aware that you can target .NET Standard 1.0 with one simple change in the AssemblyInfo.cs file?

If you just exclude the [assembly:Guid(...)] line, the Numerics library can be successfully built for .NET Standard 1.0.

As far as I understand this would be an acceptable change; after all, ComVisible is anyhow set to false. Or do you have other reasons for maintaining the Guid?

Thanks in advance for considering this!

Best regards,
Anders @ Cureos
Coordinator
Jan 25 at 7:52 PM
Hi Anders,

Thanks for pointing this out. I had actually picked 1.1 not because of the Guid attribute, but because the table at https://blogs.msdn.microsoft.com/dotnet/2016/09/26/introducing-net-standard/ doesn't make clear which desktop framework would run with a 1.0 library. When release time gets closer, I will be careful to use the lowest standard version consistent with requirements. The Guid attribute is probably not a requirement, but there are a lot of hosting scenarios (SQL CLR, Windows App Store, etc.) that impose their own special requirements on assemblies, so I would need to do little more work to say that more confidently.

Do you have a particular scenario, such as a Silverlight app, that would work with a 1.0 library but not a 1.1 library?

Regards,
David

By the way: I have not forgotten your desire for local optimization to support boundary constraints!
Jan 26 at 10:20 AM
Edited Jan 26 at 10:21 AM
Thanks for the response, David!

Targeting 1.1 rather than 1.0 might not be a big win more than from a principal point-of-view, the only additional supported platform on 1.0 is Windows Phone Silverlight 8. As far as I understand, Silverlight 5 is not supported by any .NET Standard profile, probably because its close links to .NET 4.0.

BTW, moving to .NET Standard will invalidate the support for .NET Framework 4.0 as well. Do you plan to provide an additional build for .NET 4.0, or will you discard 4.0 from now on?

If you want to maintain .NET 4.0 support alongside .NET Standard support, you might want to consider providing an additional PCL profile 328 build for that purpose. PCL profile 328 is the most compatible "old-school" cross platform profile, including support for .NET Framework 4.0 and Silverlight 5. The only code changes you need to make right now to build a PCL profile 328 library is to comment out (e.g. using compiler directives) the [assembly:ComVisible(false)] and [assembly:Guid(...)] attributes in AssemblyInfo.cs, and comment out the two [MethodImpl(MethodImplOptions.AggressiveInlining)] lines in RectangularMatrixAlgorithms.cs.

(Of course, with a pure .NET Framework 4.0 build you don't need to make any of these changes :-) )

Best regards,
Anders
Jan 26 at 10:25 AM
BTW, I have an example project.json file here, allowing for simultaneous builds of .NET Standard 1.0, .NET Framework 2.0 and PCL profile 328 instances of the csmpfit library. https://github.com/cureos/csmpfit/blob/master/src/csmpfit/project.json

The project.json format is on its way out again though, and I don't know right now how the similar arrangement can be obtain with the new .csproj file format.