I have just committed some logging (r6370) into the DynamicProxy codebase which will be in the soon to be released v2.2.
Krzysztof Koźmic suggested a few weeks back that we should add some logging mainly around type caching and anything else that may help users diagnose common problems.
In the screenshot you can see examples of the logging that you can enable. Note that the blue info messages were logged by the demo console application not by DynamicProxy.
The logging is implemented using the Castle logging infrastructure so Windsor can provide an ILogger directly to a ProxyGenerator. If a ProxyGenerator class is not instantiated by a container the default logger that DynamicProxy uses is a trace logger set to display messages at the warning level. By default this means that any messages at warning or higher logged by DynamicProxy will be visible in the Visual Studio output window.
If you have feedback on the DynamicProxy logging, or ideas for more logging then let us know on the mailing lists.
Castle NVelocity 1.1.0 and the Castle TemplateEngine component 1.1.0 have just been released. Many thanks to the TemplateEngine project lead John Simons.
Visit the
Castle Project web site for download details.
The Castle Project dropped support for .NET 2.0 on the trunk last year, however as project leader of DynamicProxy I decided we would continue to support DynamicProxy on .NET 2.0 until downstream projects (e.g. NHibernate) no longer support it.
Castle Core has had a reference to System.Core for quite some time, however it is conditionally compiled with support for .NET 2.0, Silverlight and Mono.
Up until recently we had been making sure we didn't use any C# 3.0 features in DynamicProxy so we could still build for .NET 2.0 with the .NET 2.0 compiler, however this has always been a little annoying.
I worked out that changing the frameworkdirectory attribute on the net-2.0 framework element in NAnt.exe.config will make NAnt use Csc 3.5. You just need to change 'v2.0.50727' to 'v3.5'.
With this change we can now use the var keyword, lambda expressions, object initializers and anonymous types.
I forgot to mention the new targets in the previous posts. If you want to generate either the NCover or NDepend reports like the ones available from TeamCity use these targets.
If you run "nant coverage" it will enable running nunit-console under NCover to produce the coverage XML log files, and run a build. The target will also generate the summary coverage report.
Using "nant ndepend" will run a build and generate the report from the artifacts.
I'd like to start by thanking Patrick Smacchia from NDepend for the free open source licence of NDepend Professional for use at the Castle Project.
I have finally got around to changing the build scripts to have NDepend running in our build so we can generate the NDepend code analysis report.
You can view the report in the artifacts of one of the coverage/NDepend builds, or with this direct link to the last successful build.
As you can see for yourself the report contains heaps of valuable information. I am yet to get a chance to blog about several things I have realised while playing with NDepend, which I plan to do in the next few weeks when I get some more time.
For now, you can take a look at the report for yourself.