[Netreflector-develop] Re: Precise error information

[Owen R. <exo...@gm...>]

hi szymon,

On 18/09/05, Szymon Kobalczyk <s.k...@so...> wrote:
> Back in April I wrote to you few suggestions on how to extend
> NetReflector. I've already implemented some of them and been using them
> since then. I see that recently you have started again some work on the
> project so I hope this would interest you.

thanks for the patches.  i've briefly looked through them, and i like
the idea.  improving the error information from netreflector is
something that is really needed.

could you please tell me a little about how you are using
netreflector?  i'm interested in learning about how others are making
use of this tool.  i'm also curious as to why people might choose
netreflector over the default xml serialisation support in the .net
framework.

> My colleagues who were writing the config files that I deserialized with
> NetReflector complained that it does not tell them the location of the
> error in file. So attached is a path for latest version (as of this
> writing) with modifications to extend exception messages to include line
> information from source file. I've used LineInfoDocument class that I
> found somewhere on MSDN. I can't add files to repository so there are
> several files that you need to copy manually.

ok, i'll try to locate it on msdn.  i'm a little worried about
including 3rd party code into netreflector in case there are some
licensing issues.

> There are also some other unrelated minor changes -- you can ignore them
> or keep them.

thanks.  i'll review them.  i'm intending to add some more
functionality this week, such as support for deprecating elements.

> I've seen that you started some work on XmlDocumenter. I've also played
> a bit with it but this looks more complicated that I though. But it
> would be handy to have up to date schemas for all these config files so
> I can attach them in XML editor. What are your plans with that?

i agree; however, unfortunately the format of the xml that
netreflector can parse does not lend itself well to generating
schemas.  eg. netreflector doesn't distinguish between attributes and
simple elements, and it uses attributes (such as type) to support
polymorphic types.  this probably means that i should change some of
the design of netreflector, but i'm worried about the configuration
changes that this might entail and how this could affect our user
base.

cheers,
owen.
--
Owen Rogers | http://dotnetjunkies.com/weblog/exortech |
CruiseControl.NET - http://ccnet.thoughtworks.com