Among the other coolness of Rotor, it includes an implementation of the XML Schema Definition tool (XSD.exe) from the .NET SDK. It’s somewhat limited compared to the production version (no support for generating DataSets, schema inference, XDR or Visual Basic) but it does provide the primary goal of generating classes from XSD and generating XSD from classes. Spelunking around just the build process of Rotor’s XSD.exe yielded interesting discoveries.
- The Rotor build process uses the C++ compiler to generate AssemblyAttributes.cs and AssemblyRefs.cs. AssemblyAttributes has all the assembly level attributes (similar to the AssemblyInfo file that is generated by all the VS.NET project wizards). AsseblyRefs has a class named ThisAssembly with much of the same info available programmatically plus a variety of other assembly reference strings and public key information. The C++ compiler is being used as a preprocessor to insert concrete values into a generic files (AssemblyAttributes.cspp and AssemblyRefs.cspp in the ssclirotorenvbin directory).
- There’s a really useful perl script named gensr in the ssclirotorenvbin directory. It reads a text resource file and creates string constants for every resource name. It also provides useful utility methods including type-safe and culture aware GetBoolean, GetChar, GetByte, GetShort, GetInt, GetLong, GetFloat and GetDouble. It also overloads GetString to support format strings (like string.Format).
I haven’t done much with localization, but I should, so the discovery of the gensr script is particularly useful for me. Of course, I want a compiled utility version of it. 😄 The question is rewrite in C# or use the ActiveState Perl Dev Kit which includes their PerlNET compiler. I’ll probably go C# due to my severe lack of perl skills. In the meantime, I used Perl2exe. Works OK, except that the resulting exe is almost 700kb while the original script is 9kb. That’s a lot of bloat, but I guess that’s the price of convenience.