Moving to .Net 4.0

[hopscc]

I'm thinking that we are probably not going to put much effort into supporting codegen for .Net versions prior to Net 4.0 now, yes?

i.e if we want to target a .Net2.0 system say using the Net2.0 compiler, we would have to revert cobra -> C# codegen to use only those constructs supported by .Net 2.0 rather than the newer .Net4.0 ones.

Would this indicate suppressing/removing the cobra compile option -native-compiler ( for CLR at least) ?

[Charles]

Unless someone speaks up that pre-4.0 .NET is important, I don't see the point of supporting it.

No, we would not get rid of -native-compiler:foo for a couple reasons:

(1) It's a general purpose tool that lets you control which C# compiler Cobra will invoke.

(2) It's how we boosted Cobra from CLR 2 to CLR 4 and it could/will be used for that purpose again in the future (CLR5, etc.)

(3) iOS/iPhone development requires it:

Code: Select all

-native-compiler:/Developer/MonoTouch/usr/bin/smcs


from "iPhone"

Is there a reason you ask?

[hopscc]

OK needed for
- later Frameworks
- platform variants

But what of native-compiler pointing backwards?

i.e. (Assuming have revved cobra to use (codegen) to some Net4.0 features)
What do you anticipate happening when you do this?

Code: Select all

-native-compiler:/WINDOWS/Microsoft.NET/Framework/v2.0/csc.exe


i.e downrev to an earlier Framework/compiler that doesnt handle .Net4.0 constructs (or libs).
Just let it run and (maybe/probably) fail C# compilation (depending on exactly what constructs your cobra code used)
or detect down Frameworking compiler and suppress it


Theres another complication I'm just getting a handle on (looking at ticket:330)
Net4.0 needs ref an additional dll (System.Core) that earlier revs did not (supports additional Net4.0 stuff like HashSet<of T>)
(csc 4.0 detects use of classes from this dll (or just the use of Net4.0 framework) and auto adds a ref to it - presumably? Cobra currently does not so we get weird unexpected errors).
Its a little onerous to expect a developer to know/work out they need specify an extra ref explicitly when using (some) Net4.0 specific classes so cobra should do-the-right-thing
If we make cobra always add this ref itself (presuming Net4.0 or greater) designating an earlier compiler version/framework will fail when the
dll is looked for...
(Its a different variant of the above issue)..

I asked about earlier Framework support to determine whether could ignore it and just always include use of extra dll ( in which case also probably need some suppression on -native-compiler to (at min) preclude back pointing) or continue to provide alternative codegen for supporting earlier frameworks (if so why use new Net4.0 facilities at all?) and be a lot more active about detecting Net4.0 or later use or do something else YTBD.

I'm in favor of the 'no-earlier-framework rev' position but it requires more choking down on -native-compiler (at least)
perhaps minimally try and detect back pointing compilers and emit a compiler warning (??)

[hopscc]

OTOH maybe its acceptable to just do the compile and have the resulting .exe throw a BadImageFormatException
(either due mismatched compiler and .Net runtime (clr-profile) or mismatched .exe and Cobra runtime (4.0 built).

With fix for ticket:330 cant build with embedded cobra runtime (-ert) to anything prior to 4.0 it since uses HashSet<of T>.

[Charles]

-native-compiler is an advanced feature that most Cobra devs will never even use. And when they do, it will be for specific situations like iOS. I don't think we need to add any error checking to it. We can always add it later if we see that's a problem.

Re: System.Core.dll, Cobra already auto-refs mscorlib.dll and System.dll. I see no reason why System.Core.dll shouldn't be added as part of bumping the min requirement of Cobra to CLR 4.

[hopscc]

Me neither - see patch on ticket:330

[hopscc]

FWIW I'm really liking the optional and named parameter capability in cobra....
simplifies/removes overloads massively.
ticket:325 and ticket:326

[Charles]

Patch on 325 applied. This is a nice feature. Thanks.

[hopscc]

I think I've almost got the named parameter capability sorted.
I just need to generate a few more tests - named parameters alone and in conjunction with optional params
Easier now that optional param code is in the source tree.
Thx.