Re: [Pnet-developers] Future of resgen

[Marcus]

I agree with keeping a minimal version of resgen in C code for bootstrapping 
but providing a full-featured before in managed code.

Another issue that you did not bring up is that resgen on MS is mostly a 
command-line interface to ResourceReader, ResourceWriter, ResXResourceReader, 
and ResXResourceWriter. If Pnet is to implement these classes anyway, most of 
the work for a managed version of resgen will be accomplished.

There are versions of the classes in Pnet already, but I have been running 
into some bugs. I have been working with ResXResourceReader, and I will be 
submitting patches shortly.



On Thursday 20 January 2005 10:17 pm, Carl-Adam Brengesjo wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I have been working, as some of you know, on resgen and to make it work
> with loading, e.g., a bitmap from a .resx file and then generate a
> .resources file with the data, but I have come to realize something.
>
> Currently, resgen ONLY support string data. It doesn't even try to
> identify the type. And the work needed to be done to simulate
> Serialization and a managed context (assemblies, types etc) is just
> too much to be seriously considered, IMHO.
>
> Example, a bitmap in .resx is loaded using TypeConverter, but is it
> realisticly possible to implement a type converter for allt the types a
> user might eventually want to embedd in a .resx? Or even something like
> a object implementing ISerializable (the object/type itself provides the
> data to be used in serialization), that is impossible without a runtime
> engine.
>
> Primitive data types is doable, not much work needs to be done. But all
> other object types isn't possible in my opinion.
>
> The work I've already done enables resten to be extended to support more
> types-- as long as it doesn't involve serialization. So only primitive
> types should be supported in pnet/resgen. But if anyone want to give it
> a try (native serialization), please, go ahead.
>
> So, question is, should we proceed to extend pnet/resgen, which I
> consider is a no-go (except for other primitive types), or write a
> managed version?
>
> My vote is on extending pnet/resgen to cover primitive types, and
> writing a managed version to cover everything.