From: Jason D. <ja...@in...> - 2001-10-13 17:59:08
|
> 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. |