make deliberate and documented choice about platform

created by @derammo on 2020-01-22 02:17:38 +0000 UTC
assignees: derammo

why are we building Any CPU with 32 bit preference?

why do we have 32 bit third party nlua instead of 64 bit?

why are we installed as a 64 bit application but have 32 bit components in general?

Comments:

comment by @derammo on 2020-01-24 13:18:47 +0000 UTC

can we get on a civilized platform like suggested? I would certainly like to be on a late Core or Framework with the latest language version set.

comment by @BlueFinBima on 2020-01-26 12:49:30 +0000 UTC

When I moved to 64 bit, I had a few people griping. I guess for those people running control center on a different machine, it could be very old kit, and potentially a 32-bit Windows. For example, I have a Windows tablet which I run control center on, and it is only 32 bit Windows because the processor is 32 bit.
Although I don't remember why I changed to 64 bit (there seemed to be a necessity at the time), I did not end up creating a 32-bit for general availability. If we have a technical need for later framework or core, then happy to increase the required level, but I'd prefer to allow Mr/Ms BackLevel to have a trouble free installation. Also, I was wanting to be very cautious about changing the code which interfaces with games because I have no way to test all the code. BMS communicates via shared mem is one example of why I want to be cautious.
Completely agree that it is a mess at the moment. What is your thinking about what constitutes "civilised platform" in addition to 64-bit across the board?

comment by @derammo on 2020-01-26 14:19:47 +0000 UTC

I believe "civilized" is something our new team member could best determine. For me, the interest is twofold:

1) I would like the latest language version that I can get, so I can write tighter code. New C# language versions come together with Framework releases. So each Framework has a "native" language that it was released with. Visual Studio automatically (unless your override it) set the language appropriately. Right now, we have Framework set to 4.5 but are using language version 7 (presumably that is the floor now that Visual Studio will select?) I suspect nobody ever cared about it and it just slowly and silently got bumped up over the years. So we have a mixture of ancient code and some modern code and makes me vomit a little. Let's make a decision and actually set it in the projects. I suspect there is a small "shearing force" over time if you use a very high language version compared to the Framework you select, but I am totally willing to take that risk. The hard requirement is obviously in the other direction (you need high enough language version to compile the API lol.) So even latest language version with old Framework helps me out.

2) Third party and first party (Microsoft) packages have requirements. Microsoft is doing some good work on JSON and hopefully JSON Schema that I wanted to use but I can't. It claims to require Framework 4.6 but can't actually be debugged unless you are on 4.7+. So that was a bunch of wasted time and I finally had to use third party JSON.Net and the schema generator cost me $99 per seat license. It's also seems silly to use ancient third party code for something MS has.

None of my reasons for upgrading are super important compared to supporting user deployments. So I will survive if you choose 32 bit windows with .NET Framework 4.5 as your platform. But at least let's choose that then and actually set the projects that way instead of the mess we have now. Same for the AnyCPU vs x86 vs x64. Let's make a choice and eliminate the Configuration Manager entries for all the other ones.

If you choose an older language level, I will just move my work to an external DLL that I can compile any way I want. HelBIOS (my DCS-BIOS native interface with a super punny name) is already an external DLL plugin for Helios.

comment by @BlueFinBima on 2020-02-19 23:05:55 +0000 UTC

I think we're all x64 now 7d4da6073ed5059a6687c57d7c668d3d81e82dd9

comment by @derammo on 2020-02-21 13:48:45 +0000 UTC

@BlueFinBima will you still need me, will you still feed me?

comment by @derammo on 2020-02-21 13:50:51 +0000 UTC

we still need to choose a .NET platform and language level. i had moved this to 1.6 already, so we don’t need to do that now

comment by @BlueFinBima on 2020-02-21 13:54:02 +0000 UTC

@derammo True, is there anything you think we need that is not included in 4.5? Not sure where you specify language level.

comment by @derammo on 2020-02-21 14:13:08 +0000 UTC

@BlueFinBima I want to give Miroslav a chance to provide input also. But this request started when I wanted to use Microsoft's JSON nuget package and can't, because they require 4.7.x.

Here is another thing to consider (https://support.microsoft.com/en-us/help/17455/lifecycle-faq-net-framework): .NET Framework 4.5.2: Support for .NET 4.5.2 follows the lifecycle policy of the parent OS. It is supported as a Windows component on the latest required operating system update for Windows Vista SP2, Windows 7 SP1, Windows Server 2008 SP2, Windows Server 2008 R2 SP1, Windows 8.1 Update, Windows Server 2012, and Windows Server 2012 R2.

comment by @derammo on 2020-02-21 14:14:24 +0000 UTC

Windows 10 supports Framework 4.6+.

comment by @derammo on 2020-02-21 14:15:57 +0000 UTC

We can override the language level in the build options. That's not the hard part. The hard part is making an educated decision about what value to choose. Can we choose something higher than our target Framework normally targets? Technically yes, but is it a good idea? Hence I want to wait for the expert to chime in.

comment by @BlueFinBima on 2020-02-21 14:26:25 +0000 UTC

@Derammo Sorry for missing the 64 reference, but it has been a hard day's night.

comment by @BlueFinBima on 2020-02-21 14:41:17 +0000 UTC

I think we do need an expert opinion. There are claims of backwards compatibility, but I don't know how real they are. My preference is to have as low a level as a possible to avoid people needing to install a higher framework release which we don't ever exploit.

comment by @derammo on 2020-02-21 14:48:04 +0000 UTC

I completely agree. I want low risk also. So I would aim in the middle, picking something that isn't about to be abandoned by MS and that doesn't force us to use ancient versions of nuget packages. To get that right, we need to do the survey of what is in our product first. Keeping this open for 1.6 gives us time to get smart.

comment by @derammo on 2020-04-08 15:18:35 +0000 UTC

I chose .net framework 4.7.2 for 1.6 because it supports all the libraries I want to use and is always available on Windows 10. I don't care about older windows.

created a not-done for 1.4 since this decision doesn't apply to 1.4

comment by @derammo on 2020-05-24 23:57:48 +0000 UTC

still need to verify if running as AnyCPU with 64 bit preference will result in correctly installing all third party libraries twice in 32 bit and 64 bit flavors

HeliosVirtualCockpit / Helios