.NET 3.5 and KSP 1.8

[FreeThinker]

.NET 3.5 is said to be deprecated , but would a mod compiled under .NET 3.5 still function correctly? EXactly what are the advantage of 4.x over 3.5 compilation?

Apperently it doesn't even want to compile under KSP 3.5 anymore

Edited October 18, 2019 by FreeThinker

[FreeThinker]

I still wonder what would be the best .Net version to compile it with for maximum performance with KSP. There are so many version of .NET 4.x or it realy doesn't matter?

[zer0Kerbal]

On 10/18/2019 at 8:42 AM, FreeThinker said:

I still wonder what would be the best .Net version to compile it with for maximum performance with KSP. There are so many version of .NET 4.x or it realy doesn't matter?

I asked the same - and all I have learned is - nothing. I will be going for 4.5 if not 4.7 or even 4.8. Its the wild-Wild-WILD .NET out there.

In some ways, being stuck at 3.5 was good - was a standard, and I like standards.

Edited November 1, 2019 by zer0Kerbal

[FreeThinker]

13 minutes ago, zer0Kerbal said:

I asked the same - and all I have learned is - nothing. I will be going for 4.5 if not 4.7 or even 4.8. Its the wild-Wild-WILD .NET out there.

In some ways, being stuck at 3.5 was good - was a standard, and I like standards.

I guess it doesn't matter at all, then it comes down what is conveniant which would be 4.7.2, which is still supported by older version of visual studeo

[NermNermNerm]

On 10/18/2019 at 2:11 AM, FreeThinker said:

I guess it doesn't matter at all, then it comes down what is conveniant which would be 4.7.2, which is still supported by older version of visual studeo

Per this guidance, it doesn't matter:

 

FWIW, I've got the debugger working, but I too am being hit with the ~10sec delay after attaching the debugger.

The guidance also now specifies copying in a new version of UnityPlayer.dll and WinPixEventRuntime.dll, which could use some commentary on the following in the OP:

1. Is this really necessary or do the old DLL's work (haven't tried it yet in that configuration)
2. If it's really necessary, then it's kindof a breaking change in that you're pretty much forced to keep a development KSP folder around, one that's not Steam-Updated, as Steam's likely to stomp those back into its own version.  That was sortof a good idea anyway, but it was never an idea that I followed since I spend as much time or more playing the mod as I do developing it, I like to play it in non-debug mode.

[Electrocutor]

Unity's website says to target .NET Standard 2.0.

https://docs.unity3d.com/2019.2/Documentation/Manual/dotnetProfileSupport.html

 

As an note, .NET Framework is now end-of-life after the release of 4.8 earlier this year.

Edited October 26, 2019 by Electrocutor

[Lisias]

10 minutes ago, Electrocutor said:

Unity's website says to target .NET Standard 2.0. I'm curious if KSP itself was compiled against .NET Framework 4.x instead of .NET Standard 2.0.

https://docs.unity3d.com/2019.2/Documentation/Manual/dotnetProfileSupport.html

As an note, .NET Framework is now end-of-life after the release of 4.8 earlier this year.

The System.dll I found on the managed folder tells 4.6.57.

From the page you linked:

Quote

Stable scripting runtime

The stable scripting runtime supports two different profiles: .NET Standard 2.0 and .NET 4.x. The name of the .NET Standard 2.0 profile can be a bit misleading because it is not related to the .NET 2.0 and .NET 2.0 Subset profile from the legacy scripting runtime. Instead, Unity’s support for the .NET Standard 2.0 profile matches the profile of the same name published by the .NET Foundation. The .NET 4.x profile in Unity matches the .NET 4 series (.NET 4.5, .NET 4.6, .NET 4.7, and so on) of 

Also: https://support.microsoft.com/en-us/help/17455/lifecycle-faq-net-framework

Quote

Beginning with version 4.5.2 and later, .NET Framework is defined as a component of the Windows operating system (OS). Components receive the same support as their parent products, therefore, .NET Framework 4.5.2 and later follows the lifecycle policy of the underlying Windows OS on which it is installed.  

There is no change to the lifecycle policy for .NET Framework 4.x and its updates which continue to be defined as a component of the OS and assume the same lifecycle policy as the Windows version on which it is installed.

This page https://support.microsoft.com/en-us/lifecycle/search/548 states that .NET Framework begun its life cycle at April,18 this year.

We have a lot of problems, dude. But this one is not one of them.

On 10/18/2019 at 5:42 AM, FreeThinker said:

I still wonder what would be the best .Net version to compile it with for maximum performance with KSP. There are so many version of .NET 4.x or it realy doesn't matter?

It's all about the compiler. not the toolchain.

You are not deploying System.dll or anything, just a DLL that will be linked at load time to whatever is running at the moment. So it really doesn't matter the .NET 4.x version you are using on compile time, because the compiler is essentially the same - perhaps one optimization or two on newer versions, but as long the CIL code it generates is understandable by whatever KSP is using at the moment, it will work the same.

[Lisias]

On 10/18/2019 at 4:58 AM, FreeThinker said:

.NET 3.5 is said to be deprecated , but would a mod compiled under .NET 3.5 still function correctly? EXactly what are the advantage of 4.x over 3.5 compilation?

Apperently it doesn't even want to compile under KSP 3.5 anymore

I did a brute force analysis on TweakScale thread. From the functional point of view, it didn't mattered too much using 3.5 or 4.6 while compiling for KSP 1.8 (performance not measured, the testing was focused on functionality). For KSP < 1.8, you need 3.5 as the runtime doesn't understands 4.x CIL - but the 4.6 runtime understands CIL from 3.5 . 

It worths to mention that I managed to compile a DLL on 3.5 against the DLLs from KSP 1.8, and the resulting DLL worked absolutely fine on KSP 1.7.3.

Edited October 26, 2019 by Lisias
yeah. tyops.