Re: SaxonCS 11.0 is available

OK, thanks, we'll experiment with this.

I think we're being a little conservative in our use of new C# language features. We're not using default interface members, I think, though we probably would have done if they'd been there when we started: we use them in Java and it would have removed quite a bit of complexity from the transpiler. Similarly result type covariance (I experimented with this and found it worked only for overriding of concrete methods, not of interface methods -- but perhaps I got that wrong.)

Probably the main issue is the combinatorial explosion in the number of different combinations of options we need to test.

Michael Kay
Saxonica

> On 7 Oct 2021, at 06:20, Emanuel Wlaschitz <[email protected]> wrote:
> 
> I can try at least - I guess.
> 
> You likely also generated a csproj file that is later used to compile the C# code (or at least something that in turn generates a csproj file). It probably has a <TargetFramework>net5.0</TargetFramework> tag in there somewhere.
> It should be as easy as replacing it with <TargetFrameworks>net5.0;netstandard2.0</TargetFrameworks> (for example, since .NET Standard 2.0 is also "implemented" by .NET Framework).
> 
> If need be, you can place code specific to a framework in preprocessor blocks; they will automatically define NET and NET5_0 for .NET 5, NETSTANDARD and NETSTANDARD2_0 for .NET Standard 2.0; as well as NETFRAMEWORK and NET48 for .NET Framework 4.8.
> But I'm guessing that is not really necessary, unless you use new APIs (and the more interresting part about this: runtime features such as Default Interface Members) available only in .NET 5. At least I can't think of much that would be specific to either in Saxon.
> 
> Simple case: replace that one line in the csproj, and see if it compiles. From following the dotnet/roslyn and dotnet/runtime repositories on GitHub, you're more likely to find issues in the .NET 5 compiler than the .NET Framework variants, but as usual YMMV since it's different for each and every project out there.
> 
> And while I do agree that .NET 5 (and its successors) will be the future, not everyone can simply switch over due to deprecated facilities such as WCF, Remoting and other things that simply have no replacements (yet) or things that cannot easily be replaced (again, like a WCF server in an enterprise application cannot "just" be replaced with a different communication technology in a short period of time).
> 
> -----Original Message-----
> From: Michael Kay <mike-JkSD5nQpfvpWk0Htik3J/[email protected]> 
> Sent: Wednesday, October 6, 2021 23:29
> To: Mailing list for the SAXON XSLT and XQuery processor <[email protected]>
> Subject: Re: [saxon] SaxonCS 11.0 is available
> 
> If you can help us understand what's involved in this, I'm prepared to look at it. Is it just a question of building the product a different way and re-testing, or will it involve source code changes?
> 
> Although I've learned a lot about .NET in the last few months, there are still many areas of knowledge I haven't explored, and we've been pretty focused on getting everything working under .NET 5 which clearly represents the future.
> 
> Michael Kay
> Saxonica
> 
> _______________________________________________
> saxon-help mailing list archived at http://saxon.markmail.org/
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/saxon-help