Advantages of recompiling old mods under new SDK?

[Fwiffo]

I have several mods that were built against earlier versions of KSP, but nonetheless have been working great under 1.0.4. Now that 1.0.5 is out, I'm revisiting my 50 or so mods and refreshing them. For projects that are abandoned or no longer releasing updates, I'm wondering:

[B]Would it be worth the hassle to grab the source and recompile them myself under the 1.0.5 DLL's?[/B]

I understand the "SDK" for Kerbal consists of [COLOR=#333333]UnityEngine.dll, [/COLOR][COLOR=#333333]Assembly-CSharp.dll and [/COLOR][COLOR=#333333]Assembly-CSharp-firstpass.dll. i.e. You reference them in your C# project, gaining access to any public functions, and compile (ideally against the same versions you'll be playing with). I assume the UnityEngine.dll that comes with the game is fairly static, and won't change until 1.1 is released (with UE5 support). But I see the latter two DLL's have changed slightly (although Squad annoyingly doesn't update their file version numbers).[/COLOR]

Is it fair to assume there are no performance improvements from compiling under new Squad DLL's (since your mod is dynamically linked to the latest ones at runtime)?

If so, that just leaves compatibility factors. Could anyone shed some light on how Squad handles backwards compatibility, changes to function signatures, deprecation, etc? Or do they generally just leave the old stuff alone and add new? If a mod tries to call a function who's signature has changed, I assume KSP would barf and crash, right? If a mod tries to call a function who's signature looks the same but behaves differently than when the modder coded and tested against it, I assume KSP and the .NET framework just chug along like normal and unknown behavior may occur (i.e. looks like a duck but doesn't quack like a duck).
[COLOR=#333333]
[/COLOR]Here are examples of some of the mods I play with which haven't yet (or won't ever) be updated to 1.0.5:

[spoiler=Examples]MapShowNavball
EnhancedNavBall
KerbalEngineer
DockingPortAlignment
QuickGoTo
KSPAlternateResourcePanel
RCS Sounds and Lights
Procedural Fairings
Vessel Viewer
NavUtilities
ShipEffects Sound Mod: Dynamic Sound Effects (Maintenance)
Chute Safety Indicator
GCMonitor
KSPTot
StripSymmetry
[/spoiler]

[Boris-Barboris]

Your chain of thoughts is correct. It's not worth it, if mods behave correctly - if not, they'll need more than recompiling anyways. SQUAD is pretty consistent and game core code is very static.

[JPLRepo]

That said :- in 1.0.5 one change that is I know about is squad changed the sciencedata class. Any old mods won't function correctly if they are using science containers.
You can glean info about what changes they may have made from the release notes. As well as these forums and your mod won't compile or function correctly. Then you go hunting for the change. There were other changes to heat and aero to name a few. Edited November 18, 2015 by JPLRepo

[Kobymaru]

[quote name='Fwiffo']If so, that just leaves compatibility factors. Could anyone shed some light on how Squad handles backwards compatibility, changes to function signatures, deprecation, etc?[/QUOTE]
They don't.

[quote name='Fwiffo']Or do they generally just leave the old stuff alone and add new?[/QUOTE]
Exactly this. However, note that they are usually changing few aspects of the game instead of rebuilding everything. So "most stuff" should still work after an update. That excludes the 1.1 update, because I feel a disturbance in the force about that one.

[quote name='Fwiffo']If a mod tries to call a function who's signature has changed, I assume KSP would barf and crash, right?[/QUOTE]
Pretty much this. This is also one of the main reasons for breakage of Mods between versions, and if you have access to source code (which you should have), you can fix many of those error quite easily. That would be the only reason for a recompile.

[Fwiffo]

Thanks guys; appreciate the feedback and confirmation!