>On 2013-10-25, Dominik Psenner wrote: > >>> * the next release will be 1.3.0 and require .NET 2.0 or better > >>> I.e. we remove support for .NET 1.0 and 1.1, Compact Framework 1.0, >>> Mono < 2.0, SSCLI and CLI 1.0 frameworks > >> That's even worth a +2! ;-) > >>> * the main assembly will get a new name like log4net-13.dll, only be >>> signed by the new key > >>> * we provide two assemblies named log4net.dll signed with the old and >>> new key respecitvely that contain type forwards to the new assembly >>> only > >> I'm afraid that I can't quite grasp all the stuff we could break. We should >> definitely work out every possible usecase we may break. We have messed >> enough and should try to not raise the tempers even more. > >Understood, I'll take that to the user list for a bigger audience - >maybe people will see problems that we are overlooking.
Worth a try. >>> stuff we haven't talked about, yet: > >>> * I'd like to split log4net-13.dll so that the main assembly can be used >>> for the client profile and a separate assembly contains the stuff that >>> requires System.Web - this way we no longer need the -cp builds. > >> The client profile was dropped with .NET 4.5 and previous versions are >> automatically upgraded to include the missing DLLs once somebody runs an >> update. Thus I'm not sure if we should really split the library and double >> the required efforts. > >I see. I wasn't aware the client profile was dropped again - spending >most if not all of my working hours in Java land has made me lose track, >or so it seems. In that case splitting the assembly doesn't make to >much sense. > >And the client profile builds can be removed when log4net drops support >for .NET 4.0 ten years from now ;-) True. I wanted to quote where I have this information from: http://msdn.microsoft.com/en-us/library/cc656912.aspx
