Re: [nant-dev] sln2nant

[Serge <se...@wi...>]

> I'm going something similar for NDoc 2.0 where
> users will be able to customize the output with stylesheets
Very cool!
Although NDoc's output is really good-looking, maybe someone will want
xsl:fo output or another formatting.
Also I think it's possible that some people will use doc-tags other than
standard summary etc.

> That's something that can't be done without
> extension objects (which don't seem to work in Beta 2).
But this can be done with <msxsl:script>, right?
This renders scripts non-portable, though.

> Users can always exec SAXON or MSXSL or any other command
> line XSL processor right after exec'ing sln2nant.
Or style task from NAnt :-)


Jason, thank you for the detailed response,
Sergey



----- Original Message -----
From: "Jason Diamond" <ja...@in...>
To: <nan...@li...>
Sent: Saturday, October 13, 2001 8:58 PM
Subject: Re: [nant-dev] sln2nant


> > Yes, I understand this issue. I was thinking of two-phase processing -
> first
> > C# sln parser that extracts this data, then it passes this data to XSLT
> via
> > xsl:params. In other words stylesheet must adhere to particular
> "interface".
> > It's just an idea so perhaps I'm missing something.
>
> It's definitely a good idea. I'm going something similar for NDoc 2.0
where
> users will be able to customize the output with stylesheets. Each of the
> user defined stylesheets has to have certain global xsl:param elements in
> order for it to work correctly. For sln2nant we could even convert the
.sln
> file into XML first and then XSLT it while using the document() function
to
> read all the .csproj files. That was one of my ideas but since I wrote
> sln2nant to be reused in NDoc (the sln part--not the 2nant part) I needed
an
> object model that could represent everything in the .sln file and .csproj
> files programmatically.
>
> There's another curious issue, though. VS.NET creates .resx files for each
> Windows Form you include in a GUI application. Most of these .resx files
> contain data (resources) but some don't and are 0 bytes in length. Not
> surprisingly, the .resx files that have no content fail to compile with
> resgen.exe and so cause csc.exe to file when it's looking for the
.resources
> file that was supposed to have been created. So the sln2nant code has to
> check the length of each .resx file in order to know whether or not it
> should add it to the task. That's something that can't be done without
> extension objects (which don't seem to work in Beta 2).
>
> > Anyhow, I agree that named filesets should solve the problem. Really,
> named
> > filesets (patternsets) is a useful feature - it was discussed before in
> > another context.
> > Besides, I guess that slnToNant task output could be post-processed with
> > XSLT if need will arise.
>
> That's very true. Users can always exec SAXON or MSXSL or any other
command
> line XSL processor right after exec'ing sln2nant.
>
> Jason.
>
>
>
> _______________________________________________
> Nant-developers mailing list
> Nan...@li...
> https://lists.sourceforge.net/lists/listinfo/nant-developers
>