Cleanup capitalization and dependencies

[dsyme]

While working through the build process I noticed a coupe of things

• Fsi.exe should be called fsi.exe systematically. Let's normalize this now.
• Fsi.exe is always called fsiAnyCpu.exe on Mono. Although both are odd names, it's best to use the same as what is already used on case-sensitive file systems. Let's normalize this now.
• Fix dependencies in FSharp.Core nuget description to match project.json
• Simplify propagation of PREFERRED_UI_LANG define

[KevinRansom]

Are you sure this is the right capitalization?
Assembly Names guidance is Pascal casing not camel casing? Although they are in fact case insensitive in the runtime.

If you want to change the output filename on disk to camel case use the TargetFilename property.

[dsyme]

This is not high priority. I'm trying to align these to those used by F# on Linux to help prevent these awkward capitalization errors in the longer term.

github.com/fsharp/fsharp has always used fsiAnyCpu. On Linux we'd expect the executable names are lowercase.exe.there is an argument it should have used fsianycpu , but I think just aligning to the existing F#-on-Linux norm is simplest.

[cartermp]

I had experimented with removing the runtimes node before, but always got build errors. Perhaps something has changed since earlier this Summer?

Also, the RIDs in runtimes prevented me from lowering the netstandard version to netstandard1.3 (the lowest we can go due to the dependency on System.Console). Perhaps we could also lower it here? That lets it build on .NET Framework 4.6.

[dsyme]

@cartermp I put the runtimes back for now. Let's do that separately. Kevin and I discussed and thought it wasn't needed, but maybe it is

[KevinRansom]

Having thought about ... I now think they are needed and probably needed in all project.jsons. Because we shouldn’t take a reference on APIs that are not implemented in specific target platforms.
The runtimes sections will cause restore failures, if we add a dll that isn’t supported by a target platform.

[dsyme]

@KevinRansom So the "runtime" section is a constraint meaning "must run on at least this platform"? Still, it seems really strange to have the names of linux distros in there.

[KevinRansom]

@dsyme perhaps I i's strange ... but the coreclr does have many distro specific implementations of code. We can have a discussion over whether that is the right choice. I'm expecting we would be in agreement over that discussion and probably would wish it were different.

Kevin

[cartermp]

Runtimes are needed for self-contained deployment of applications, but aren't intended for libraries unless you do something like take a dependency on a native binary. We shouldn't need to specify any runtime unless we've got platform-specific dependencies or native code.

I'm not sure how the move to MSBuild will affect this, though.

[KevinRansom]

@cartermp Well I believe that restore fails if you have a dependency on a library that doesn't have a specific native implementation for each of the specified frameworks. So it is kind of irrelevant what the "intent" is.

[cartermp]

So to clarify - you want to protect against the lack of a native implementation on a given target where netstandard1.6 is supposed to run, but we have some custom code in FSharp.Core that might not?