Jump to content

Recommended Posts

I think the more important question is - is there any real benefit to moving to a new version of .NET?

Software development is driven by both technical and business decisions, through cost-benefit analysis. Given that KSP is currently built around .NET 3.5, migrating to a newer version may require significant refactoring/rewriting of existing code, which is likely to require far more time and resources compared with adding and improving new gameplay features on the existing version of .NET. "But it'll be awesome/worth it!" isn't really pragmatic decision making.

Here's a real-life example from one of my past jobs:

Spoiler

I used to work at a company whose products were essentially embedded Linux computers running a custom Java application. We identified an issue where the internal clock of the embedded computers inside the products would sometimes forget what time zone it was in, causing the generated log files to have the wrong time stamps.

I eventually determined that the version of the Java Runtime Environment running on our embedded computers had a bug with its time synchronization feature, which was already fixed with a newer and publicly-available version of the JRE. I confirmed the fix by actually building and running our custom app against the new JRE.

However, we realized that migrating to the new JRE would be very risky because many of our app's mission-critical features relied on third-party libraries officially certified for use with the current (older) JRE - verifying, updating or finding replacements for all the libraries would be very time consuming and costly (we would have to pay licensing fees for any updated libraries on every product we ship or have already shipped, whereas we had currently been using older, free and open-source libraries up until now). Not to mention all the extra time required to verify that the new JRE doesn't break any of our other features.

In the end, the head of software development (and my boss at the time) simply wrote a cron job to manually sync time zones for the buggy JRE - a hacky but time and cost-saving workaround.



 

Link to post
Share on other sites
On 5/9/2019 at 8:44 AM, LVLVbNH said:

Any plans for up NET Framework version from 3.5? Any reasons why it can't be done?

To expand upon @sumghai's explanation -- there is little benefit for KSP (or rather Unity) to use newer .NET versions.  In fact, they don't even use the .NET compiler, they use Mono (or Roselyn in recent versions of Unity).  Moreso, this isn't a decision made specifically by the KSP devs, but rather is a limitation of the Unity version that KSP is built with.

However, personally I found that if I use Visual Studio as a stand-alone I am able to compile .dll's using newer C# language features that are not supported by the older .NET 3.5 target (such as inline 'out' variables from C#6/7).  So if your only goal is to get access to the newer language features -- you already can.  You only need to target the older versions if you are letting Unity compile your .dlls.

https://www.lifehacker.com.au/2016/05/a-primer-for-unity-developers-what-the-heck-is-mono/

 

Link to post
Share on other sites
1 hour ago, Shadowmage said:

To expand upon @sumghai's explanation -- there is little benefit for KSP (or rather Unity) to use newer .NET versions.  In fact, they don't even use the .NET compiler, they use Mono (or Roselyn in recent versions of Unity).  Moreso, this isn't a decision made specifically by the KSP devs, but rather is a limitation of the Unity version that KSP is built with.

However, personally I found that if I use Visual Studio as a stand-alone I am able to compile .dll's using newer C# language features that are not supported by the older .NET 3.5 target (such as inline 'out' variables from C#6/7).  So if your only goal is to get access to the newer language features -- you already can.  You only need to target the older versions if you are letting Unity compile your .dlls.

https://www.lifehacker.com.au/2016/05/a-primer-for-unity-developers-what-the-heck-is-mono/

 

According this post there is some problems with 4.x dll`s.

Currently i just wanted to know why in 2019 moddevs still should use 3.5. At this point @sumghai gave an exhaustive answer.

Link to post
Share on other sites
  • 1 month later...

It's understandable for not upgrading, but the world is changing fast, more and more third-party software never support .Net Framework 3.5, for example, GRPC requires .Net Framework 4.5+, and GRPC has no plan to support 3.5.(I'm planning to create a new plugin based on GRPC, but unfortunately, I find KSP requires .Net framework 3.5)

On 5/11/2019 at 6:47 AM, sumghai said:

Given that KSP is currently built around .NET 3.5, migrating to a newer version may require significant refactoring/rewriting of existing code, which is likely to require far more time and resources compared with adding and improving new gameplay features on the existing version of .NET. "But it'll be awesome/worth it!" isn't really pragmatic decision making.
 

I'm also a programmer, I believe "refactoring/rewriting of existing code" is an important part of a long-term software project such as KSP, the key is how to balance the effort between "refactoring/rewriting of existing code" and new feature development. Many times, I have seen a software finally corrupted and became so hard to maintain that it was replaced by a totally new software, at the cost of huge resources and time investment.

Maybe for now, KSP hasn't reach the point that SQUAD has to upgrade .Net Framework, otherwise KSP is too painful to add new features for the dev, or too painful for the community to develop a new plugin/mod. But that day will finally come, as long as KSP is still alive, the later that day is, the more effort "refactoring/rewriting" KSP will require.

I can see some signs already in recent years. Even Microsoftware won't end 3.5's life before 2028-10-10, depending on an "unofficially outdated" framework is not a good idea for me, especially when we are talking about KSP, which is still under development and "young".

I bravely estimate that, in three years, KSP will upgrade .Net Framework, before SQUAD finds it's too late.

Edited by Xavier513
add a link
Link to post
Share on other sites
5 hours ago, Xavier513 said:

(I'm planning to create a new plugin based on GRPC, but unfortunately, I find KSP requires .Net framework 3.5)

Well, we already got kRPC, might be helpful for you to peek at their code :)

 

 

Link to post
Share on other sites
7 hours ago, 4x4cheesecake said:

Well, we already got kRPC, might be helpful for you to peek at their code :)

Thanks.

Indeed, KRPC is a great mod, and I spent alomost a whole last week reading the source code(I'm totally new to C sharp and KSP plugin development), I learnt A LOT from @djungelorm's great work!

But I prefer using existing RPC framework(for example, GRPC, Thrift), rather than building my own RPC framework. 

Good news! I find Thrift still supports .Net framework 3.5, and in fact I have already ran a "HelloWorld.exe" successfully.

The bridge between local process and KSP is through! Now I can continue my development focusing on "bussiness logic".:D

 

Link to post
Share on other sites
  • 2 months later...
This thread is quite old. Please consider starting a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...