We must have "many" conditionals. As you noted 2.0 is not a superset of 1.1 and 4.0 is not a superset of 2.0. Because of CAS and other issues, 2.0 and 4.0 may be in direct opposition.
3.0 and 3.5 are indeed supersets of 2.0, but I doubt their importance as conditionals. I would only see them as important IFF (if and only if) we do release a 3.5 targeted framework WITH a WCF appender. I think the introduction of 3.5 as a tag should wait until later IFF we discover there is enough demand for a 3.5 target. I think that I like the idea of 4_0 and 4_0_FULL. (Allow 4_0_COMPACT to be represented as !4_0_FULL. So any 4_0 specific code that is not compact vs. full conditioned is under 4_0 and if it is only full it is under 4_0_FULL and it if is compact only it is under !4_0_FULL. I fear that NETCP will complicate things as we move from the 1.0/1.1 compact to the 4.0 compact and potentially to a 3.5 compact if that is necessary in the future. (Right now, the 3.5 compact COULD be considered a 2.0 compact. Yes, you must target 3.5 to get the choice of compact, but you do not have to take advantage of 3.5 specific code.) I would further say that any code that works in 2.0 and 4.0 has NO conditionals around it, but not include compatibility with 1.0/1.1 as a requirement for no conditional. To elaborate, the 2_0 tag becomes 2_0 specific code. (Code that does not work in 4.0.) Any 2.0 code that does not work in 1.0/1.1 becomes !1_0 Other than MONO I do not believe the family concept will serve us going into the future. What I am really saying is that the base code will favor 2.0/4.0 of the framework and anything that differs from that requires a conditional. This idea is probably not in keeping with the original concept, but the framework has grown well beyond what was envisioned when the project started and we might need to adjust our thinking to match. ---------------------------------------------------------------------- Roy Chastain
