Question about NT8 8.1.2.0 .NET Framework targeting

[carnitron]

You can see in the NinjaTrader.Custom.csproj file that NT8 8.1.2.0 targets .NET Framework 4.8, like so:

<TargetFramework>net48</TargetFramework>

But you can see here:

https://learn.microsoft.com/en-us/do...nguage-version

That the highest C# language version supported by ANY version of .NET Framework is C# 7.3.

So how is NT8 supporting C# 8?

This is now sort of an issue on my end, b/c the "bridge" DLL that sits between the NT8 Custom executable and my main engine DLL (which is .NET Standard 2.0) is built against .NET Framework 4.8, so it can speak to both the NT8 exe and my engine DLL.

B/c it targets .NET Framework 4.8, VS2022 will only let me use C#7.3 on that DLL. Overall, NT8 supporting C#8 has enabled me to move my direct NT8 code from 5.0 to 8.0 and my main engine code from 7.3 to 8.0, so it is still a huge win for me.

But it is odd that I now have this one DLL stuck on 7.3 b/c it is following rules that NT8 seems to be breaking.

Is there a simple explanation for this?

Cheers.

P.S. I may work around this issue by simply merging my bridge DLL into the main NT8 exe, since .NET Framework 4.8 talks to .NET Standard 2.0 just fine.

[QuantKey_Bruce]

If you notice, at the link you posted, C# 7.3 is the DEFAULT when targeting .NET Framework but you can override this by editing your project file. I don't think it's really a MAXIMUM is it? What should probably happen is NT should output this in the project file:

<PropertyGroup> <LangVersion>8.0</LangVersion> </PropertyGroup>

Wouldn't that resolve it completely?

[carnitron]

So, the plot has thickened considerably here.

I have for a long time been thinking I'll eventually need to take more serious measures to get into the higher versions of C#, based on these sentences from that prior link:

"This default choice also ensures you don't use a language that requires types or runtime behavior not available in your target framework. Choosing a language version newer than the default can cause hard-to-diagnose compile-time and runtime errors."

More serious measures being something like what is suggested here:

https://learn.microsoft.com/en-us/pr...84200(v=vs.100)

But THIS article adds rather interesting context:

https://btburnett.com/csharp/2020/12...t-dotnet5.html

Unlike C++, C# has pretty strong safety mechanisms up and down the stack, so I find myself wondering whether the above warning is overkill, just to reduce support headaches for Microsoft and I will not, in fact, be opening myself up to mysterious, impossible-to-diagnose crashes by pushing the boundaries here.

Anyhow, when I tried moving my bridge DLL to 8 before, I got some compile error/warning from VS2022, but I cannot figure out how I got the error and after following your suggestion, have since gotten my bridge DLL working on 8 just fine.

So now the question is how high can I go version-wise on the bridge and engine DLLs?

I think I'm going to CAREFULLY go in stages, first 9, then 10, then 11.

The fix this guy recommends for init-only setters is not terrible.

[QuantKey_Bruce]

Anyhow, when I tried moving my bridge DLL to 8 before, I got some compile error/warning from VS2022, but I cannot figure out how I got the error and after following your suggestion, have since gotten my bridge DLL working on 8 just fine.

Great!

So now the question is how high can I go version-wise on the bridge and engine DLLs?

I think I'm going to CAREFULLY go in stages, first 9, then 10, then 11.

Please keep us posted how this goes.

[carnitron]

Well one update is that you cannot change the language version of NinjaTrader.Custom.csproj to 9 and use C#9 features like you can in DLLs. I think NT8 ignores the setting and just compiles with C#8 regardless. Which makes sense, given that the .csproj file is not the source of truth, but is instead a final output. I wonder if there is an equivalent setting in an NT8 file somewhere?

So far, I am updating both of my DLLs with C#9 code and it is working smoothly. As expected, init-only properties didn't work out of the box, but after adding the compiler services changes in the above post, they seem to work just fine. As do records in my super minimal tests so far.

I have not yet looked into what might be necessary to make C#10, 11 and 12 work.

[carnitron]

More posts on the topic.

https://stu.dev/csharp8-doing-unsupported-things/

https://sergiopedri.medium.com/enabl...es-ce384d8debb

Basically, there are three categories of language feature support that can work against .NET Framework 4.8/.NET Standard 2.0:

1. Features that will "just work".
2. Features that can be enabled.
3. Features that will never work and would require a .NET migration.

Various features in BOTH C#8 and C#9 fall into each of these categories.

I have not found any similar articles for C#10, b/c presumably the general market has moved far enough past .NET Framework 4.8/.NET Standard 2.0 that people have stopped needing to write these articles. But that's just a guess. I will probably try C#10 just to get a few more syntactic sugar features.

[carnitron]

File-scoped namespace declarations from C#10 DO work, so I'll probably run with those too.

[QuantKey_Bruce]

A good explanation of how C# development parallels the move away from .NET Framework is here https://www.reddit.com/r/csharp/comm...k_vs_net_core/. C# 7 is the last C# that had a .NET Framework release - C# 8 is in the .NET Core only era, so that's why there's less out there talking about this with .NET Framework. Still, it's great that NT was able to get it to be supportable under .NET Framework without reworking the application as .NET Core which is a heavy lift.

[carnitron]

FWIW, just to follow up here. I have been using C#11 with my two AddOn DLLs for months now without issue. I just upgraded them to C#12 a week ago and that works as well (yay primary constructors and collection expressions). Well, excepting certain known features that would require a newer version of the CLR, like covariant returns and default interface members.