hxcs command options

[skial]

These two small changes allow the user to control which csc compiler gets used by hxcs.

1. Using -D csharp-compiler=C:/path/to/csc now works on windows. Before, this resulted in hxcs looking for a .bat file.
2. Using -D NET_35 will stop findMsvc looking for a newer csc on a matched version, in this case .net framework 3.5.

I'm not entirely comfortable with the -D NET_ change, but its a lot simpler for the user to define than looking up the path to csc, especially if they have never done any C# before.

Are there any foreseeable problems that these changes might raise?

[skial]

ping @waneck

[Neverbirth]

Using -D NET_35 will stop findMsvc looking for a newer csc on a matched version, in this case .net framework 3.5.

So it won't use newer compilers if available? I think that's not right, because you should be able to target older .Net versions with newer compilers. When using .NET it allows to use newer language features while still using older frameworks.

[skial]

So it won't use newer compilers if available?

Yes, this tells hxcs to stop searching if/when it finds csc.exe whose path matches -D NET_xx, eg -D NET_35.

I think that's not right, because you should be able to target older .Net versions with newer compilers. When using .NET it allows to use newer language features while still using older frameworks.

In relation to FD_SamplePlugin, using hxcs as it is, will use the latest csc compiler on your machine, which for me is .NET 4. But FlashDevelop does not appear to load a dll built with .NET 4, because I assume FD is built with .NET 3.5? I'm not aware of how to tell csc from .NET 4 to build a .NET 3.5 compatible file?

[Neverbirth]

Yes, FD is built targetting .NET 3.5. But that shouldn't be a problem, for example, you can use Visual Studio 2015, use C# 6 language features (therefore using latest compiler, but I think latest SDKs don't even include older ones?), and target .NET 3.5 with no problems.

There has to be something else wrong in there. AFAIK when using the command line it should be enough to pass /p:TargetFrameworkVersion="v3.5" to MSBuild... but maybe there is more to it...

[skial]

There has to be something else wrong in there. AFAIK when using the command line it should enough to pass /p:TargetFrameworkVersion="v3.5" to MSBuild... but maybe there is more to it...

Nice, I'll give that a go tomorrow, thanks 😄

[skial]

There has to be something else wrong in there. AFAIK when using the command line it should be enough to pass /p:TargetFrameworkVersion="v3.5" to MSBuild... but maybe there is more to it...

I should have remembered when I read this yesterday, hxcs uses the latest csc.exe which, as I understand it, is specific to each .NET version, so in my case it is csc.exe found in .NET 4.5. Hxcs doesn't use msbuild.exe, again as far as I'm aware.

In the FD_SamplePlugin repo, removing -D NET_35 allows hxcs to set the version its self, in FD_SamplePlugin's case, -D NET_20, the default hxcs sets. The changes in this pr will use csc.exe found in .NET 2.0 directory.

Using hxcs from haxelib results in it using .NET 4.5 csc.exe, generating a 4.0 dll, which I assume it does because hxcs includes the 4.0 netlib dll's. Setting -D net-ver=20 still results in a 4.0 dll, with version 2.0 and 4.0 dll references.

Let me know if any of this is wildly wrong, I'm relatively new to all of this 😄.

[Neverbirth]

Oh, so csc is used. I didn't know that. In that case check this link.

EDIT: I never used csc directly, so I haven't tried this approach, another thing that can be of help is to check the different .targets files used by MSBuild. You can find them under the different Windows/Microsoft.NET folders. Maybe they hint something.

[ncannasse]

Ping @waneck