[jira] [Updated] (LOG4NET-322) Conditional compilation symbols for .net4 Release
[ https://issues.apache.org/jira/browse/LOG4NET-322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Iso Su updated LOG4NET-322: --- Attachment: ReleaseConditionalSymbols.patch Here's the change I used to fix it for myself Conditional compilation symbols for .net4 Release - Key: LOG4NET-322 URL: https://issues.apache.org/jira/browse/LOG4NET-322 Project: Log4net Issue Type: Bug Components: Builds Affects Versions: 1.2.11 Environment: log4net.vs2010 project Reporter: Iso Su Attachments: ReleaseConditionalSymbols.patch While Debug configuration has a proper list of Conditional compilation symbols (NET;NET_2_0;NET_4_0), the Release configuration has them set to STRONG;NET;NET_1_0;. This causes problems with a lot of appenders and LogicalThreadContext is not working, since it uses SetData(), not LogicalSetData() -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (LOG4NET-322) Conditional compilation symbols for .net4 Release
[ https://issues.apache.org/jira/browse/LOG4NET-322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig resolved LOG4NET-322. Resolution: Fixed Fix Version/s: 1.2.12 Thanks! Patch applied in svn revision 1239458 Conditional compilation symbols for .net4 Release - Key: LOG4NET-322 URL: https://issues.apache.org/jira/browse/LOG4NET-322 Project: Log4net Issue Type: Bug Components: Builds Affects Versions: 1.2.11 Environment: log4net.vs2010 project Reporter: Iso Su Fix For: 1.2.12 Attachments: ReleaseConditionalSymbols.patch While Debug configuration has a proper list of Conditional compilation symbols (NET;NET_2_0;NET_4_0), the Release configuration has them set to STRONG;NET;NET_1_0;. This causes problems with a lot of appenders and LogicalThreadContext is not working, since it uses SetData(), not LogicalSetData() -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (LOG4NET-322) Conditional compilation symbols for .net4 Release
Conditional compilation symbols for .net4 Release - Key: LOG4NET-322 URL: https://issues.apache.org/jira/browse/LOG4NET-322 Project: Log4net Issue Type: Bug Components: Builds Affects Versions: 1.2.11 Environment: log4net.vs2010 project Reporter: Iso Su While Debug configuration has a proper list of Conditional compilation symbols (NET;NET_2_0;NET_4_0), the Release configuration has them set to STRONG;NET;NET_1_0;. This causes problems with a lot of appenders and LogicalThreadContext is not working, since it uses SetData(), not LogicalSetData() -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Compilation Symbols
On 2011-08-21, Roy Chastain wrote: 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. Agreed. 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 Going forward I pretty much agree with you - but then again we may not need to think about 1.x and compact framework at all then 8-) For the 1.2.x branch I'd prefer to stick with the current approach in order to minimize code changes. 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. I'm not even convinced we'll need much Mono specific code at all - outside of appenders, maybe. Buth then again I must admit that there are quite a few parts of trunk that I never really looked into, so I may be wrong. 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. +1 Stefan
RE: Compilation Symbols
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
Compilation Symbols
Hi all, before I started to modifiy things for 4.0 and client profile the NAnt build was setting a compilation symbol for the family like NET, NETCF, MONO and one for the specific version NET_1_1, NET_2_0 and so on. Also the conditional compilation sections seem to not assume NET_2_0 was a superset of NET_1_1. What I have done for now is piggy-back on NET_2_0 for both cases. I have added CLIENT_PROFILE and NET_4_0 and define them in addition to NET_2_0 and NET as this required the least changes to the code base. This way I didn't need to hunt down all places that say NET_2_0 and add a || NET_4_0. But I start to feel that the correct way would have been to define NETCP as a new family, NETCP_3_5 ans NETCP_4_0 as new versions and to also change all conditionals that rely on NET_2_0 so they apply to the (then) two 4.0 and NETCP_3_5 as well. So #if NET_2_0 would become #if NET_2_0 || NET_4_0 || NETCP_3_5 || NETCP_4_0 This would create more complex conditionals but at the same time be consistent with what has been done for the existing codebase. What do you think? Stefan
