Something else to look at. A quick google search says that nhibernate is LGPL. I'm not sure which version though.
I am not a laywer but I would think that GPL (NAnt's current license) and LGPL would be compatible. I would appreciate additional insight if there are those who are more familiar with license compatibility than I. Thanks, Ryan On Wed, May 18, 2011 at 11:34 PM, Richard Birkby <rbir...@gmail.com> wrote: > NHibernate solved that by building a logging proxy into NHibernate.dll > and then dynamically binding to log4net. > > Are the licenses compatible? You could borrow their implementation. > > Richard > > On 18 May 2011, at 23:26, Ryan Boggs <rmbo...@gmail.com> wrote: > >> The problem isn't NAnt targeting net-4.0-client. The problem is that >> one or more of NAnt's dependencies doesn't run well on the client >> profile. For example, log4net depends on System.Web which isn't >> included in the client profile. It's already been reported in NAnt's >> bug report while back if I remember right. >> >> Thanks, >> Ryan >> >> 2011/5/18 Martin Aliger <martin_ali...@gordic.cz>: >>> I do not see problem _targeting_ "net-4.0-client" Framework. No real need to >>> be hosted in that, imho. >>> >>> Martin >>> >>> -----Original Message----- >>> From: Ryan Boggs [mailto:rmbo...@gmail.com] >>> Sent: Wednesday, May 18, 2011 9:52 PM >>> To: Martin Aliger >>> Cc: nant-developers@lists.sourceforge.net >>> Subject: Re: [nant-dev] reference assemblies and net-4.0 >>> >>> Hi, >>> >>> See inline. >>> >>> On Wed, May 18, 2011 at 9:19 AM, Martin Aliger <martin_ali...@gordic.cz> >>> wrote: >>>> I miss some assemblies in this list (latest nightly) for net-4.0. >>>> Mostly WindowsBase and PresentationFramework. Looks like the list is not >>> complete. >>>> Perhaps those should be added with wildcard? >>> I need to ask about the wildcards in app.config but in the meantime, I went >>> ahead and committed the two files in question to the app.config file. I'll >>> perform another nightly build either tonight or tomorrow for further >>> testing. >>>> >>>> >>>> >>>> Also there is something called "NET 4.0 Client Profile". If we want to >>>> introduce this as separate "Framework" (targettable), there is >>>> different path for those Reference Assemblies >>>> ("%ProgramFiles%\Reference >>>> Assemblies\Microsoft\Framework\.NETFramework\v4.0\Profile\Client") >>> This was brought up in the past. I think the big issue with this right now >>> (if I remember right) is that log4net isn't currently setup for the client >>> profiles. I recently posted a log4net update I received on this issue to >>> the nant-dev list but I am not sure if anything was done on their side yet. >>> In the meantime, anyone have any thoughts on the matter? >>>> >>>> >>>> >>>> >>>> <reference-assemblies >>>> basedir="${environment::get-folder-path('ProgramFiles')}/Reference >>>> Assemblies/Microsoft/Framework/.NETFramework/v4.0"> >>>> >>>> >>>> <include name="Microsoft.Build.Conversion.v4.0.dll"/> >>>> >>>> >>>> <include name="Microsoft.Build.dll"/> >>>> >>>> >>>> <include name="Microsoft.Build.Engine.dll"/> >>>> >>>> >>>> <include name="Microsoft.Build.Framework.dll"/> >>>> >>>> >>>> <include name="Microsoft.Build.Tasks.v4.0.dll"/> >>>> >>>> >>>> <include name="Microsoft.Build.Utilities.v4.0.dll"/> >>>> >>>> >>>> <include name="Microsoft.CSharp.dll"/> >>>> >>>> >>>> <include name="Microsoft.JScript.dll"/> >>>> >>>> >>>> <include name="Microsoft.VisualBasic.Compatibility.Data.dll"/> >>>> >>>> >>>> <include name="Microsoft.VisualBasic.Comptatibility.dll"/> >>>> >>>> >>>> <include name="Microsoft.VisualBasic.dll"/> >>>> >>>> >>>> <include name="Microsoft.VisualC.dll"/> >>>> >>>> >>>> <include name="Microsoft.VisualC.STLCLR.dll"/> >>>> >>>> >>>> <include name="mscorlib.dll"/> >>>> >>>> >>>> <include name="PresentationBuildTasks.dll"/> >>>> >>>> >>>> <include name="PresentationCore.dll"/> >>>> >>>> <include name="WindowsBase.dll"/> >>>> >>>> <include name="PresentationFramework.dll"/> >>> These two entries were just committed. >>>> >>>> <include name="PresentationFramework.Aero.dll"/> >>>> >>>> >>>> <include name="PresentationFramework.Classic.dll"/> >>>> >>>> >>>> <include name="PresentationFramework.Luna.dll"/> >>>> >>>> >>>> <include name="PresentationFramework.Royale.dll"/> >>>> >>>> >>>> >>>> >>>> >>>> Martin >>> >>> Thanks, >>> Ryan >>> >>> ---------------------------------------------------------------------------- >>> -- >>> What Every C/C++ and Fortran developer Should Know! >>> Read this article and learn how Intel has extended the reach of its >>> next-generation tools to help Windows* and Linux* C/C++ and Fortran >>> developers boost performance applications - including clusters. >>> http://p.sf.net/sfu/intel-dev2devmay >>> _______________________________________________ >>> nant-developers mailing list >>> nant-developers@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/nant-developers >>> >>> >> >> ------------------------------------------------------------------------------ >> What Every C/C++ and Fortran developer Should Know! >> Read this article and learn how Intel has extended the reach of its >> next-generation tools to help Windows* and Linux* C/C++ and Fortran >> developers boost performance applications - including clusters. >> http://p.sf.net/sfu/intel-dev2devmay >> _______________________________________________ >> nant-developers mailing list >> nant-developers@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/nant-developers > ------------------------------------------------------------------------------ What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay _______________________________________________ nant-developers mailing list nant-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nant-developers
