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 (??)