Silverlight 4 support

[ioancrisan]

Hi guys,
I added support for Silverlight 4, could you merge my changes to the main trunk? I also updated the nuget.spec file. I would be grateful if you would publish the nuget package, I need support for both .NET 4.0 and Silverlight 4.0 for my work.

Thanks,
Ioan

[Daniel-Svensson]

Silverlight 4 support sounds promising, do you think it would be possible to create a portable class library (instead?), that would be really usefull

[ioancrisan]

Hi Daniel,
I added also support for portable class library and also updated the nuspec file. However NuGet 2.1+ is required for portable class library. I left also the Silverlight 4 project, there are a some things supported on SL 4 and unsupported on PCL, like LogManager.GetCurrentClassLogger() and ConsoleOutLogger* classes.

Have a nice day,
Ioan

[Daniel-Svensson]

Hi Ioan

I have begun to improve the portable version of common.logging and so far I've added an implementation of LogManager.GetCurrentClassLogger() which works for portable libraries when running under Silverlight and .Net 4+ (https://github.com/Daniel-Svensson/common-logging)

Hovewer thera are some further work required to have the portable library truly useful and since I have not worked with creating nuget packages I would appreach some feedback on my ideas before I send you a pull request.

My idea is to move the core of common.logging into a portable library (lets call it common.logging.core for now) and move out platform specific code to a separate project/assembly (we can call it common.logging). This way we would use the same portable .dll in projects targeting silverlight, .net 4, .net 4.5 and windows store applications.

For existing .net applications this would have the implications that they instead of referencing only the "common.logging" they would have to include both "common.logging.core" (for ILog, LogManager etc) and "common.logging" (for ConsoleOutLogger and System.Diagnostocs trace logger).

1: How should we name the assemblies?
My suggestions are

• Common.Logging.Core or for the portable part
• Common.Logging as the name for platform specific assemblies or Common.Logging.Desktop/ Common.Logging.Net40 för .Net and Common.Logging.SL for silverlight specific assembly in case we have any silverlight specific code

2: How should this be deployed through nuget?
My suggestion is

• one nuget package for the portable core assembly ex Common.Logging.Core which should be referenced by all libraries using common.logging
• one nuget package for the platform specific assembly ex Common.Logging which in turn have a dependency on the Common.Logging.Core package
  I guess this that this would allow existing user of common.logging to update the current "common.logging" nuget package and still have exactly the same functionality but now with a added references to Common.Logging.Core also. Do you have enough experience with nuget to know if this is a feasible upgrade option?

3; How to enable targeting net 3.5?
Can the "Common.Logging.Core" package contain a .net 3.5 specific dll for .net 3.5 and a portable dll for all other platform targets or is it a a much better aproach to provide a "Common.Logging.Net35" package which does not depend on Common.Logging.Core but contain a non-portable .NET 3.5 specific implementation of the two assemblies

I am open for ideas and suggestions.

[ioancrisan]

Hi Daniel,

1. Common.Logging.Core and Common.Logging should be fine, because, as you've mentioned, the current users will want to preserve the current functionality on upgrading. It should be fine to have in SL one or two loggers less, anyway the specific loggers will be used (NLog, log4net, s.o.)
2. I didn't test it in production, but as the documentation on http://docs.nuget.org/docs/release-notes/nuget-2.1 says, a SL/NET version will be preferred over portable if one exists. However, I don't find it bad to have in the nuget package .NET 3.5, 4.0, SL and portable flavors. The question is if we want to have the overhead of multiple VS projects - which I think is not so high.
3. I think I answered above. We could also target 2.0 if we'd wanted. A Common.Logging.Net35 is not necessary and would only be confusing, I guess.

Have a nice day,
Ioan