RE: [nant-dev] resgen speed
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Martin Aliger Sent: dinsdag 7 februari 2006 8:03 To: nant-developers@lists.sourceforge.net Subject: [nant-dev] resgen speed Gert, you wrote (in response to one issue report): Resgen should be a lot faster in the nightly builds of NAnt (http://nant.sourceforge.net/nightly/latest). Can you try this and let us know if performance is acceptable ? I tried and there is very significant speed improvement (45min-17min). I believe it's on resource handling. Where was the catch? We now first check whether a resx might contain references to non-system types, and if not, do not bother copying the referenced assemblies to a temp directory to allow resgen to resolve these types. Note: on .NET 2.0, we do not need to copy the referenced assemblies at all (or check whether copying is needed), as resgen now has command line options for passing a set of referenced assemblies. Gert --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ nant-developers mailing list nant-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nant-developers
[nant-dev] [ nant-Bugs-1415272 ] ResGen issue with long paths if assembly references used
Bugs item #1415272, was opened at 2006-01-26 10:38 Message generated for change (Comment added) made by drieseng You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=402868aid=1415272group_id=31650 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tasks Group: cvs Status: Open Resolution: None Priority: 5 Submitted By: Bernard Vander Beken (jawn) Assigned to: Nobody/Anonymous (nobody) Summary: ResGen issue with long paths if assembly references used Initial Comment: Related issue: 1153724. Issue: - The resgen task already batches multiple resgen.exe calls when the command line is too long (around 3), however the assembly references are not taken into account to determine this length. When the command line without assembly references is just less than the limit, this may cause problems anyway. Context - Discovered by using solution task to build a VS2003 web project on .NET 2.0. - Can be reproduced using just the resgen task. Attached: - Sample build files, must be unzipped to directory 'C:\testLongDirNametestLongDirNametestLongDirNametestLongDirNametestLongDirNametestLongDirNametestLongDirNametestLongDi' or a directory name with the same length to reproduce the problem. The build file resgenNoAssemblyRefWORKS.build and resgenWithAssemblyRefBROKEN.build do the same, except for assembly references. - Note that both the contenst of the assemblies and resx files do not matter here. -- Comment By: Gert Driesen (drieseng) Date: 2006-02-07 10:17 Message: Logged In: YES user_id=707851 Bernard, Can you send me the repro (including resx files, and assemblies) by email ([EMAIL PROTECTED]) ? Thanks ! -- Comment By: Bernard Vander Beken (jawn) Date: 2006-01-26 10:42 Message: Logged In: YES user_id=25244 Note: I cannot upload the sample build files since the file size is to large, I can mail it if requested. This is the contenst of the breaking sample: ?xml version=1.0? project name=ResGen command line limit example default=rebuild target name=clean description=remove all generated files delete fileset include name=output/** / /fileset /delete /target target name=build resgen todir=output assemblies include name=assemblies/*.dll / /assemblies resources include name=resx/*.resx / /resources /resgen /target target name=rebuild depends=clean, build / /project -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=402868aid=1415272group_id=31650 --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ nant-developers mailing list nant-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nant-developers
RE: [nant-dev] resgen speed
Good, thanks for explanation.
btw: (that one I forgot to write before :)
If (targetframework==framework_nant_is_running on) {
we could use ResouceWriter class as someone suggested?
is it only condition or there are other catches?
}
Since I think, this condition is usually met, it could be worth of. Mainly
since in large solutions, resgen time is crutial (every ms counts).
Martin Aliger
-Original Message-
From: Gert Driesen [mailto:[EMAIL PROTECTED]
Sent: Tuesday, February 07, 2006 9:56 AM
To: 'Martin Aliger'; nant-developers@lists.sourceforge.net
Subject: RE: [nant-dev] resgen speed
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Martin Aliger
Sent: dinsdag 7 februari 2006 8:03
To: nant-developers@lists.sourceforge.net
Subject: [nant-dev] resgen speed
Gert,
you wrote (in response to one issue report):
Resgen should be a lot faster in the nightly builds of NAnt
(http://nant.sourceforge.net/nightly/latest).
Can you try this and let us know if performance is acceptable ?
I tried and there is very significant speed improvement
(45min-17min). I believe it's on resource handling. Where was the
catch?
We now first check whether a resx might contain references to
non-system types, and if not, do not bother copying the
referenced assemblies to a temp directory to allow resgen to
resolve these types.
Note: on .NET 2.0, we do not need to copy the referenced
assemblies at all (or check whether copying is needed), as
resgen now has command line options for passing a set of
referenced assemblies.
Gert
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642
___
nant-developers mailing list
nant-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nant-developers
RE: [nant-dev] resgen speed
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of Martin Aliger
Sent: dinsdag 7 februari 2006 10:33
To: 'Gert Driesen'; nant-developers@lists.sourceforge.net
Subject: RE: [nant-dev] resgen speed
Good, thanks for explanation.
btw: (that one I forgot to write before :)
If (targetframework==framework_nant_is_running on) {
we could use ResouceWriter class as someone suggested?
is it only condition or there are other catches?
}
That would be an option, yes. We'd need to perform this in a separate
appdomain, to avoid having the default appdomain cluttered with assemblies
from every project that is being built.
But I'm not sure we want to maintant two separate implementations.
Since I think, this condition is usually met, it could be
worth of. Mainly
since in large solutions, resgen time is crutial (every ms counts).
I understand your pain ...
Gert
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642
___
nant-developers mailing list
nant-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] New XML tasks and functions
The updated task (using the code from Dries) is at home :( I'll email it tonight (I meant to copy it to my MP3 player or my GMail drive, but forgot. Sorry)Wouldn't the NamespaceManager on Project be a different instance to the one on the Task, therefore have a different set of namespaces? JohnOn 07/02/06, Martin Aliger [EMAIL PROTECTED] wrote: Namespacemanager on Element should be there for namespace handling of nant build file itself. I do not test this funcionality, but we're solving this issue some time ago. I'm looking forward to get a look into your changed tasks. Is it on nightlies already or have you a patch somewhere? Thanks, Martin From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of John LudlowSent: Tuesday, February 07, 2006 12:21 AMTo: Dries Verbeke; nant-developers@lists.sourceforge.netSubject: Re: [nant-dev] New XML tasks and functions Ok, I've integrated your changes into my copy, Dries. I can forward you the binaries if you want to test it, but I'm not sure what kind of a difference this will make. As far as I know, the updated XmlPoke I did should support namespaces. Probably the XmlPoke2 task doesn't, but that was probably why Ian asked if I could merge my task with the existing one. There is the Xml-Foreach task which this might come in handy for, but I haven't submitted that. The functions still don't support namespaces because they're not element-aware, and I think the original question was could they support namespaces. I think it might be an idea if the functions could find out where they were called from, and get the namespacemanager that way. (BTW, there is a namespacemanager in the Element class, so it's possible that we could just get that rather than needing a base class for XmlTask. Having said that, there's a case for having an XmlTask base anyway as there's some common functionality there.) I get the feeling I'm missing something fairly obvious. Anyway, I'm off to bed since I'm tired and I have an interview tomorrow. :) See ya later.John On 06/02/06, John Ludlow [EMAIL PROTECTED] wrote: I'm pretty new to it myself ;) I'll take a look at the changes and see if I can get it built and tested, and I'll let you know what happens.CheersJohn On 06/02/06, Dries Verbeke [EMAIL PROTECTED] wrote: Hi John,i re-read the original thread and concluded that what they wanted was just the same behaviour as the xmlpeek and xmlpoke task so I refactored the functionality out of those task and put it in an abstract base class 'XmlTask'. Nowyour new tasks can easily inherit from this task and have the same functionality (read multiple namespaces). In the attachments a cvs patch file. Keep in mind that I'm new to this opensource thing and didn't add a lot of comments to the changes. I also placed the abstract class in the same namespace as the other default task. So check it out and let me know what you think of it DriesJohn Ludlow [EMAIL PROTECTED] wrote: Hi,Unless I'm missing something, it's a slightly larger job than that. I've added a property into my copy of the NAnt source, but I can't see how to make the _expression_ evaluator care about that property. It doesn't reference Task at all, so I don't think it could (in its current implementation) know that a namespace has been specified on the task and it should apply that namespace. I'll see if I can get it to work out the task instance that has been run and from there whether or not to apply a namespace. If anyone has any ideas, please email me.CheersJohn On 03/02/06, John Ludlow [EMAIL PROTECTED] wrote: Ok, wasn't sure if that's what you meant. I'm working on something else at the moment but I'll take a look when I get the chance. On 03/02/06, Dries Verbeke [EMAIL PROTECTED] wrote: That 's correct it needs to be added to the Abstract Task class so we can add it as a default property and (but this needs to be checked out) I think it doesn't matter where you put the namespace references the NamespaceManager will contain all namespace declarations of an xml document it's associated to. In the microsoft doc's there is something mentioned as scope management. It could be that only the task tag or any parent tags are useable ...At the moment I don't have a compilable version of the Nant source as soon as can I'll check this or if you have some time ... the only thing we need to agree is the name of the Property ... it may not conflict with existing properties in any subclass ...so let me know what
[nant-dev] [ nant-Bugs-1425659 ] CombinePaths error with ending path seperator on first path
Bugs item #1425659, was opened at 2006-02-06 23:20 Message generated for change (Comment added) made by drieseng You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=402868aid=1425659group_id=31650 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core Group: cvs Status: Closed Resolution: Fixed Priority: 5 Submitted By: Andrew Davey (asdavey) Assigned to: Gert Driesen (drieseng) Summary: CombinePaths error with ending path seperator on first path Initial Comment: If path1 ends with a trailing path seperator, and path2 makes use of '../' , then the returned combined path is incorrect. Example: Combining C:\Test\Whatever\ ..\Whatever\Test.txt should result in: C:\Test\Whatever\Test.txt instead you get: C:\Test\Whatever\Whatever\Test.txt I've attached a tarball with the patch for the fix as well as a patch for the tests. -- Comment By: Gert Driesen (drieseng) Date: 2006-02-07 12:52 Message: Logged In: YES user_id=707851 This is now fixed in cvs. I had to make some modifications to your patch though, as it introduced regressions. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=402868aid=1425659group_id=31650 --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ nant-developers mailing list nant-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nant-developers
[nant-dev] [ nant-Bugs-1423931 ] comments description is missing in msdn like help...
Bugs item #1423931, was opened at 2006-02-04 08:15 Message generated for change (Comment added) made by drieseng You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=402868aid=1423931group_id=31650 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core Group: 0.85 Status: Open Resolution: None Priority: 9 Submitted By: Pooja (pooja_sh5) Assigned to: Nobody/Anonymous (nobody) Summary: comments description is missing in msdn like help... Initial Comment: Have downloaded NAnt 0.85 nightly build to support .net framework 2.0 but while creating MSDN like documentation using task ndoc, no comments are present at all under Description column. Whereas comments specified within all the tags(summary, remarks, params etc) are present in the generated xml files. Please suggest. If NDoc version is not the updated one then please fix this issue.. Thanks in advance. -- Comment By: Gert Driesen (drieseng) Date: 2006-02-07 12:54 Message: Logged In: YES user_id=707851 Can you send me a repro for this issue ? Thanks ! -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=402868aid=1423931group_id=31650 --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ nant-developers mailing list nant-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nant-developers
[nant-dev] [ nant-Bugs-1425826 ] status for request 1423931
Bugs item #1425826, was opened at 2006-02-07 07:00 Message generated for change (Settings changed) made by drieseng You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=402868aid=1425826group_id=31650 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: 0.85 Status: Closed Resolution: Duplicate Priority: 5 Submitted By: Pooja (pooja_sh5) Assigned to: Nobody/Anonymous (nobody) Summary: status for request 1423931 Initial Comment: submitted a request on 2006-02-04. it is open. want to know the status and the response time...in urgent need. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=402868aid=1425826group_id=31650 --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ nant-developers mailing list nant-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] Continuing work on msbuild-solution
Has anymore work been completed on the msbuild-solution task? However, developers who are in a similar position as myself, who have relatively easy to compile solutions and are migrating their applications over to VS 2005, are forced to make a decision. Do we stick/use NAnt, or do we go with what Microsoft is pushing (or the third option, going with an expensive visual build system). FWIW, I've had great success just using the exec / task for running MSBuild. It works just fine, and I can pass in any of the parameters I want. We started using it just about 5 minutes after we started building our .NET 2.0 applications, i.e. long enough to modify the build files to accomodate it. /bs --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ nant-developers mailing list nant-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nant-developers
RE: [nant-dev] Continuing work on msbuild-solution
FWIW, I've had great success just using the exec / task for running MSBuild. It works just fine, and I can pass in any of the parameters I want. We started using it just about 5 minutes after we started building our .NET 2.0 applications, i.e. long enough to modify the build files to accomodate it. Sure, exec works for almost everything. But I guess, you'll soon find, you miss some features from solution which msbuild do not solve. Like resolving project dependences. Or something NAnt specific. Martin --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ nant-developers mailing list nant-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] Continuing work on msbuild-solution
FWIW, I've had great success just using the exec / task for running MSBuild. It works just fine, and I can pass in any of the parameters I want. We started using it just about 5 minutes after we started building our .NET 2.0 applications, i.e. long enough to modify the build files to accomodate it. Sure, exec works for almost everything. But I guess, you'll soon find, you miss some features from solution which msbuild do not solve. Like resolving project dependences. I haven't had any problem resolving project dependencies. MSBuild seems to be smart enough to navigate the hintpaths defined in the various project files and deals with those just fine. Even the COM Interop stuff is working just peachy keen. Or something NAnt specific. Like what? --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ nant-developers mailing list nant-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nant-developers
RE: [nant-dev] Continuing work on msbuild-solution
I haven't had any problem resolving project dependencies. MSBuild seems to be smart enough to navigate the hintpaths defined in the various project files and deals with those just fine. Even the COM Interop stuff is working just peachy keen. There are issues, believe me. Maybe its not problem for you, but it is for many of us. You're not obliged to use any specific task if you dont want to - just stick to exec if you like :-) Hintpathes are ok in some cases, but in they are not in many others. But to be right: msbuild is much smarter than just navigate hintpathes. In fact, it does very good job on reference resolving. Just not good enough in some cases. There are even MS blogs about it, if you like to find them. It do _not_ follow project build order when building more projects at once. It could read order from .sln file, but thats all. It never try to find out correct build order for list of projects like NAnt do. And this one was showstopper for me. Or something NAnt specific. Like what? Like assemblyfolders, projectreferences. Or resolving assembly reference from its output filename, which is added value even for vs2003 solutions. Or, for example, what about mixing VS2003 and VS2005 projects? Crosscompiling would be other example (even I'm not sure it could be done with msbuild. Maybe net-2.0 - mono-2.0 crosscompile?). I saw some blogs about msbuild be able to target net-1.1. Not sure about those though. Martin --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ nant-developers mailing list nant-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] New XML tasks and functions
That was meant to say This zip file has the updated source and NAnt.Core.dll :/JohnOn 07/02/06, John Ludlow [EMAIL PROTECTED] wrote:This zip file has the On 07/02/06, John Ludlow [EMAIL PROTECTED] wrote: The updated task (using the code from Dries) is at home :( I'll email it tonight (I meant to copy it to my MP3 player or my GMail drive, but forgot. Sorry)Wouldn't the NamespaceManager on Project be a different instance to the one on the Task, therefore have a different set of namespaces? JohnOn 07/02/06, Martin Aliger [EMAIL PROTECTED] wrote: Namespacemanager on Element should be there for namespace handling of nant build file itself. I do not test this funcionality, but we're solving this issue some time ago. I'm looking forward to get a look into your changed tasks. Is it on nightlies already or have you a patch somewhere? Thanks, Martin From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of John LudlowSent: Tuesday, February 07, 2006 12:21 AMTo: Dries Verbeke; nant-developers@lists.sourceforge.netSubject: Re: [nant-dev] New XML tasks and functions Ok, I've integrated your changes into my copy, Dries. I can forward you the binaries if you want to test it, but I'm not sure what kind of a difference this will make. As far as I know, the updated XmlPoke I did should support namespaces. Probably the XmlPoke2 task doesn't, but that was probably why Ian asked if I could merge my task with the existing one. There is the Xml-Foreach task which this might come in handy for, but I haven't submitted that. The functions still don't support namespaces because they're not element-aware, and I think the original question was could they support namespaces. I think it might be an idea if the functions could find out where they were called from, and get the namespacemanager that way. (BTW, there is a namespacemanager in the Element class, so it's possible that we could just get that rather than needing a base class for XmlTask. Having said that, there's a case for having an XmlTask base anyway as there's some common functionality there.) I get the feeling I'm missing something fairly obvious. Anyway, I'm off to bed since I'm tired and I have an interview tomorrow. :) See ya later.John On 06/02/06, John Ludlow [EMAIL PROTECTED] wrote: I'm pretty new to it myself ;) I'll take a look at the changes and see if I can get it built and tested, and I'll let you know what happens.CheersJohn On 06/02/06, Dries Verbeke [EMAIL PROTECTED] wrote: Hi John,i re-read the original thread and concluded that what they wanted was just the same behaviour as the xmlpeek and xmlpoke task so I refactored the functionality out of those task and put it in an abstract base class 'XmlTask'. Nowyour new tasks can easily inherit from this task and have the same functionality (read multiple namespaces). In the attachments a cvs patch file. Keep in mind that I'm new to this opensource thing and didn't add a lot of comments to the changes. I also placed the abstract class in the same namespace as the other default task. So check it out and let me know what you think of it DriesJohn Ludlow [EMAIL PROTECTED] wrote: Hi,Unless I'm missing something, it's a slightly larger job than that. I've added a property into my copy of the NAnt source, but I can't see how to make the _expression_ evaluator care about that property. It doesn't reference Task at all, so I don't think it could (in its current implementation) know that a namespace has been specified on the task and it should apply that namespace. I'll see if I can get it to work out the task instance that has been run and from there whether or not to apply a namespace. If anyone has any ideas, please email me.CheersJohn On 03/02/06, John Ludlow [EMAIL PROTECTED] wrote: Ok, wasn't sure if that's what you meant. I'm working on something else at the moment but I'll take a look when I get the chance. On 03/02/06, Dries Verbeke [EMAIL PROTECTED] wrote: That 's correct it needs to be added to the Abstract Task class so we can add it as a default property and (but this needs to be checked out) I think it doesn't matter where you put the namespace references the NamespaceManager will contain all namespace declarations of an xml document it's associated to. In the microsoft doc's there is something mentioned as scope management. It could be that only the task tag or any parent tags are useable ...At the moment I don't have a compilable version of the Nant source as soon as can I'll check this or if
[nant-dev] [ nant-Bugs-1423931 ] comments description is missing in msdn like help...
Bugs item #1423931, was opened at 2006-02-04 07:15 Message generated for change (Comment added) made by pooja_sh5 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=402868aid=1423931group_id=31650 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core Group: 0.85 Status: Open Resolution: None Priority: 9 Submitted By: Pooja (pooja_sh5) Assigned to: Nobody/Anonymous (nobody) Summary: comments description is missing in msdn like help... Initial Comment: Have downloaded NAnt 0.85 nightly build to support .net framework 2.0 but while creating MSDN like documentation using task ndoc, no comments are present at all under Description column. Whereas comments specified within all the tags(summary, remarks, params etc) are present in the generated xml files. Please suggest. If NDoc version is not the updated one then please fix this issue.. Thanks in advance. -- Comment By: Pooja (pooja_sh5) Date: 2006-02-08 06:54 Message: Logged In: YES user_id=1443619 In the NAnt.chm file description field is not showing the appropriate info. Am not able to attch the zip file containg code. Hope this info. is sufficient for providing help. In case of further ref. please contact soon. Thanks -- Comment By: Gert Driesen (drieseng) Date: 2006-02-07 11:54 Message: Logged In: YES user_id=707851 Can you send me a repro for this issue ? Thanks ! -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=402868aid=1423931group_id=31650 --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ nant-developers mailing list nant-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nant-developers
