[nant-dev] [ nant-Bugs-1425111 ] Solution task not using includesvfolders
Bugs item #1425111, was opened at 2006-02-06 11:22 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=402868aid=1425111group_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: None Status: Open Resolution: None Priority: 5 Submitted By: mspa (mspa) Assigned to: Nobody/Anonymous (nobody) Summary: Solution task not using includesvfolders Initial Comment: I've got a solution file which contains a C++ project. When building this project using the solution task, the build fails because the include file afxres.h cannot be found. Building in Visual Studio 2003, it works fine because the path to this file afxres.h was entered in the VC++ directories in the Tools-Option menu. As far as I can see, the option 'includesvfolders' for a solution task should include these paths defined in MSVC, but clearly is doesn't? I already tried to set the 'includesvfolders' value to 'true' and 'false' but neither results in the correct behaviour. Is there another way to include these Visual Studio paths? Because now my project always fails to build. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=402868aid=1425111group_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-1425251 ] Creating of a satelite assembly fails
Bugs item #1425251, was opened at 2006-02-06 15:03 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=402868aid=1425251group_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: 5 Submitted By: crus007 (crus007) Assigned to: Nobody/Anonymous (nobody) Summary: Creating of a satelite assembly fails Initial Comment: Creating of a satelite assembly is failing when the project contains a large number of forms or user controls. I find out that the assembly linker al.exe is called using the command line to embed the resources. In my case the number of resources which should be linked to the satelite assembly was to large. For a quick fix I changed the source nant-0.85-nightly-2005-12-13\src\NAnt.DotNet\Tasks\AssemblyLinkerTask.c s to add the Arguments to the temporary command file and set IfDefined to false. I have attached this file to the bug report. My their is better way for fixing this bug. Regards Crus -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=402868aid=1425251group_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-1425518 ] uptodate not working
Bugs item #1425518, was opened at 2006-02-06 19:16
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=402868aid=1425518group_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: 0.85
Status: Open
Resolution: None
Priority: 5
Submitted By: baylor wetzel (baylor)
Assigned to: Nobody/Anonymous (nobody)
Summary: uptodate not working
Initial Comment:
i'm new to nant. Either i don't know how to use the
task uptodate or it doesn't work
Imagine two directories, source and destination. Each
has a file which we'll call s.exe and d.exe.
SourceFiles points to s.exe, TargetFiles points to
d.exe. The target is named Verify and comes after the
target Copy. The Copy target has been verified by hand
and works as expected
Here's what i'm finding:
1. Files are in appropriate places, destination/d.exe
is newer than source/s.exe. Run uptodate. Returns
True. Test works as expected
2. Touch source/s.exe to be newer than
destination/d.exe. Run uptodate. Returns True. i
believe this should have returned False, so this is
not working
3. Erase source/s.exe. Run uptodate. Returns True. i
don't know what should be happening here
4. Put back s.exe, erase destination/d.exe. Run
uptodate. Returns False and the message Destination
file(s) do(es) not exist.. Test works as expected
i'm testing these a couple of ways. First, i set
failonerror=True. This never works no matter what.
Second i set the required property variable and echo
the value. Third, i use the property variable with if
and ifnot statements which in turn use echos and, when
it's false, a fail
Here is a snippet of my most recent nant script. All
other steps not shown here (which is just the file
copy) work as expected
uptodate property=files.uptodate verbose=true
failonerror=true
sourcefiles
include name=profiler.exe /
/sourcefiles
targetfiles
include
name=${output.path}/profiler.exe /
/targetfiles
/uptodate
if test=${files.uptodate}
echo message=files.uptodate is true.
Value='${files.uptodate}' /
/if
ifnot test=${files.uptodate}
echo message=files.uptodate is false.
Value='${files.uptodate}' /
fail message=Failed verification step /
/ifnot
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=402868aid=1425518group_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-1425518 ] uptodate not working
Bugs item #1425518, was opened at 2006-02-06 19:16
Message generated for change (Comment added) made by baylor
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=402868aid=1425518group_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: 0.85
Status: Open
Resolution: None
Priority: 5
Submitted By: baylor wetzel (baylor)
Assigned to: Nobody/Anonymous (nobody)
Summary: uptodate not working
Initial Comment:
i'm new to nant. Either i don't know how to use the
task uptodate or it doesn't work
Imagine two directories, source and destination. Each
has a file which we'll call s.exe and d.exe.
SourceFiles points to s.exe, TargetFiles points to
d.exe. The target is named Verify and comes after the
target Copy. The Copy target has been verified by hand
and works as expected
Here's what i'm finding:
1. Files are in appropriate places, destination/d.exe
is newer than source/s.exe. Run uptodate. Returns
True. Test works as expected
2. Touch source/s.exe to be newer than
destination/d.exe. Run uptodate. Returns True. i
believe this should have returned False, so this is
not working
3. Erase source/s.exe. Run uptodate. Returns True. i
don't know what should be happening here
4. Put back s.exe, erase destination/d.exe. Run
uptodate. Returns False and the message Destination
file(s) do(es) not exist.. Test works as expected
i'm testing these a couple of ways. First, i set
failonerror=True. This never works no matter what.
Second i set the required property variable and echo
the value. Third, i use the property variable with if
and ifnot statements which in turn use echos and, when
it's false, a fail
Here is a snippet of my most recent nant script. All
other steps not shown here (which is just the file
copy) work as expected
uptodate property=files.uptodate verbose=true
failonerror=true
sourcefiles
include name=profiler.exe /
/sourcefiles
targetfiles
include
name=${output.path}/profiler.exe /
/targetfiles
/uptodate
if test=${files.uptodate}
echo message=files.uptodate is true.
Value='${files.uptodate}' /
/if
ifnot test=${files.uptodate}
echo message=files.uptodate is false.
Value='${files.uptodate}' /
fail message=Failed verification step /
/ifnot
--
Comment By: baylor wetzel (baylor)
Date: 2006-02-06 19:18
Message:
Logged In: YES
user_id=186776
Forgot to mention - version=0.85.1932.0; rc3
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=402868aid=1425518group_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] New XML tasks and functions
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.CheersJohnOn 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 itDriesJohn 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 you can find out
Dries John Ludlow [EMAIL PROTECTED] wrote:
Hmmm... It would have to be implemented on more than just the echo task - I just included that as an example, but I think that useage wouldn't be as useful as, say, the property task. You could do something like that for the property task, I guess, but there's other situations where properties are useful. If you wanted to take the values of an XML document and post them to a database, for
example, ou could use the XML functions within the nantcontrib sql tasks. Similarly, to append to a document or merge the contents of a document into another, you can (with my patch to the xmlpoke task, or with my xmlpoke2 task) do something like this:
xmlpoke file=xmlfile.xml xpath//data ![CDATA[ ${xml::get-xml(other.xml, '//data[test = 'true']')} myothertag value=123/
]]/xmlpoke I'm not sure where you'd put the xmlns:x definition in this case. I suppose you could put them as attributes of the xmlpoke task:xmlpoke file=
xmlfile.xml xpath//x2:data xmlns:x=
http://www.gordic.cz/shared/project-config/v_1.0.0.0 xmlns:x2=
http://www.gordic.cz/shared/project-config/v_2.0.0.0 ![CDATA[ ${xml::get-xml(other.xml, '//x:data[test = 'true']')} myothertag value=123/ ]]
/xmlpokeWould this work? If so, I'd suggest these modifications to the base Task class, so that this can be used in any task.John On 03/02/06,
Dries Verbeke [EMAIL PROTECTED] wrote:
Hi, maybe a stuppid idee but why cant we have some kind of mechanisme to add the NamespaceManager of our nant build xml file to the task so you can add multiple Namespace in an xml fashioned way ... echo message=${xml::get-value-using-ns('
test.xml', '/x:configuration/x:appSettings/x:[EMAIL PROTECTED] = ''server'']/@value')} xmlns:x=
http://www.gordic.cz/shared/project-config/v_1.0.0.0 xmlns:x2=
http://www.gordic.cz/shared/project-config/v_2.0.0.0/To do this we only need to add an extra property to the abstract Task class and fill it with the
NamespaceManager available at that moment ... and from their on every task can use this extra property. just brain storming ... Dries
Get the latest photos from your camera to your friends family fast and easy with
PhotoMail from Yahoo! Mail.
Yahoo! Autos. Looking for a sweet ride? Get pricing, reviews, more on new and used cars.
[nant-dev] [ nant-Bugs-1425659 ] CombinePaths error with ending path seperator on first path
Bugs item #1425659, was opened at 2006-02-07 08:20 Message generated for change (Tracker Item Submitted) made by Item Submitter 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: Open Resolution: None Priority: 5 Submitted By: Andrew Davey (asdavey) Assigned to: Nobody/Anonymous (nobody) 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. -- 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] Continuing work on msbuild-solution
Has anymore work been completed on the msbuild-solution task?Looking through the archives there was mention of moving it into NAnt-Contrib, but the last time I looked that hasn't happened.I've downloaded the binaries and source that Martin posted in January, and they work ok (except for a bug in FileUtil.CombinePaths which is stuffing up Path references). But I would like to investigate adding support for the 'solution' property as well as a few other things (like would it be possible to add a OutputDir property to the msbuild task). I don't want to start making changes however, until it's clear that msbuild-solution is the way that NAnt is going to go. Somewhat related, below is a rant on why the msbuild*** tasks are important, and why IMHO it is crucial that more noise be made about NAnt's plans to support VS 2005.I believe that the solution task was an important win for the NAnt project. People (like me) who don't have a complicated solution/project structure and who use VS for their day to day compiles didn't want the hassle of updating their NAnt scripts every time they added/removed a file from their project. Without the solution task, I don't know if I would have been able to justify using NAnt as a build process. (Which is funnymy NAnt scripts are around the 3000 line mark, of which maybe 100 lines deals with the actual compile). 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). A casual browse around the NAnt site, and there is no mention of what NAnt plans to do (or not do) regarding VS 2005 and Net 2.0. This isn't good. It makes it look like NAnt is dead (which is what I was starting to think). It wasn't until I started to browse this list's archive that I could see that NAnt was alive and that work was being done to get NAnt working on VS 2005. The sooner this work is made more visible (ie getting it into the nightly build of either NAnt or the Contrib), is blogged about, has a code project article etc etc the better off NAnt will be. Anyways, that's what I think.AndyPS Martin I'm very grateful for the work that you've done towards the msbuild-solution task. Has made my decision to stick with NAnt a lot easier as has the process of migrating my build process for 2005 solutions/projects.
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.JohnOn 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 itDriesJohn 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 you can find out
Dries John Ludlow [EMAIL PROTECTED] wrote:
Hmmm... It would have to be implemented on more than just the echo task - I just included that as an example, but I think that useage wouldn't be as useful as, say, the property task. You could do something like that for the property task, I guess, but there's other situations where properties are useful. If you wanted to take the values of an XML document and post them to a database, for
example, ou could use the XML functions within the nantcontrib sql tasks. Similarly, to append to a document or merge the contents of a document into another, you can (with my patch to the xmlpoke task, or with my xmlpoke2 task) do something like this:
xmlpoke file=xmlfile.xml xpath//data ![CDATA[ ${xml::get-xml(other.xml, '//data[test = 'true']')} myothertag value=123/
]]/xmlpoke I'm not sure where you'd put the xmlns:x definition in this case. I suppose you could put them as attributes of the xmlpoke task:xmlpoke file=
xmlfile.xml xpath//x2:data xmlns:x=
http://www.gordic.cz/shared/project-config/v_1.0.0.0 xmlns:x2=
http://www.gordic.cz/shared/project-config/v_2.0.0.0 ![CDATA[ ${xml::get-xml(other.xml, '//x:data[test = 'true']')} myothertag value=123/ ]]
/xmlpokeWould this work? If so, I'd suggest
Re: [nant-dev] Continuing work on msbuild-solution
Andy Davey wrote: Has anymore work been completed on the msbuild-solution task? Nothing official that I know of, beyond what you've seen in the archives. I tend to agree that, unless you make the effort to dig back through this list's archives, NAnt looks like it's basically dead in the water :( But word is that a new release is due any time now so hopefully that's a temporary problem. But I would like to investigate adding support for the 'solution' property as well as a few other things (like would it be possible to add a OutputDir property to the msbuild task). I don't want to start making changes however, until it's clear that msbuild-solution is the way that NAnt is going to go. It would be a mistake to build any logic to parse VS2005 solution files into NAnt because that file format is almost certainly going away in the next version. (The only reason it's not an MSBuild file now is because MS basically didn't have time to finish it for VS2005). However, it's also not important: msbuild.exe knows how to parse the solution format. It doesn't matter if you supply a project file or solution file, it will just build. -- -- Mike Still using IE? Get Firefox! http://www.spreadfirefox.com/?q=affiliatesid=6492t=1 --- 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
Mike wrote, It would be a mistake to build any logic to parse VS2005 solution files into NAnt because that file format is almost certainly going away in the next version. (The only reason it's not an MSBuild file now is because MS basically didn't have time to finish it for VS2005). I'm not sure that I entirely agree with that. Using MSBuild to perform the actual build is a great idea. Nant is so powerful in so many other areas it doesn't loose anything by pushing the compiling work over to MSBuild (especially when you consider that MSBuild may be used to compile for/target Mono [http://blogs.msdn.com/jomo_fisher/archive/2005/08/31/458658.aspx]). But at the same time there are a couple things you can do with solution that I haven't found easy to replicate with an msbuild task. The show stopper for me at the moment is getting MSBuild to direct all build outputs to a particular folder (I'm not saying it can't be done...I just haven't found a solution that is as nice as the 'outputdir' property of the solution task). Considering the progress that Martin has made with the msbuild-solution, I don't think it would take much effort to add support for solution's 'Solution' property. VS 2005's sln format is not that much different to VS 2003. I don't know about any proposed changes to the 2005 sln format (except to say I wouldn't be surprised if they dothey have always in the past), but that bridge can be crossed when we come to it. I also think that having a msbuild-solution will make it clearer to Nant users of a relatively smooth migration path for updating Nant scripts to work with VS 2005. However, it's also not important: msbuild.exe knows how to parse the solution format. It doesn't matter if you supply a project file or solution file, it will just build. Agreed. I just need to work out a way to mimic 'outputdir' functionality that I used with solution. Andy --- 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 06:00 Message generated for change (Tracker Item Submitted) made by Item Submitter 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: Open Resolution: None 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] New XML tasks and functions
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 you can find out DriesJohn Ludlow [EMAIL PROTECTED] wrote: Hmmm... It would have to be implemented on more than just the echo task - I just included that as an example, but I think that useage wouldn't be as useful as, say, the property task. You could
RE: [nant-dev] Continuing work on msbuild-solution
Hello, Has anymore work been completed on the msbuild-solution task? No, nothing serious since early january. I'm testing overall stability and performance on our enterprise build. But most of our projects are still on net-1.1. Anyway, it looks very well. Looking through the archives there was mention of moving it into NAnt-Contrib, but the last time I looked that hasn't happened. It do not happens yet. Mainly becouse of needed patch to main solution task, which wasn't still submitted (or I do not know about it). But I would like to investigate adding support for the 'solution' property as well as a few other things (like would it be possible to add a OutputDir property to the msbuild task). I don't want to start making changes however, until it's clear that msbuild-solution is the way that NAnt is going to go. Exactly the reason why I do not continue the work. If I know, its the way where NAnt would like to go, I'd gladly improve it somewhat. Gert, Ian? How you see it? I believe that the solution task was an important win for the NAnt project. People (like me) who don't have a complicated solution/project structure and who use VS for their day to day compiles didn't want the hassle of updating their NAnt scripts every time they added/removed a file from their project. Without the solution task, I don't know if I would have been able to justify using NAnt as a build process. (Which is funnymy NAnt scripts are around the 3000 line mark, of which maybe 100 lines deals with the actual compile). Very same here :-) Really funny thing - 3000 line script and only few lines about building itself. In contrast, msbuild files (scripts) are all about build. In fact, I like it much (better than solution), but it (main) purpose it elsewhere. And I see NAnt/MSBuild coexistence useful. Ok, it is competetive in some respects, but It could be also nice complement. It wasn't until I started to browse this list's archive that I could see that NAnt was alive and that work was being done to get NAnt working on VS 2005. The sooner this work is made more visible (ie getting it into the nightly build of either NAnt or the Contrib), is blogged about, has a code project article etc etc the better off NAnt will be. I feel it simmilar. I know, there is real work and NAnt is just pet project like many open-sources. Even that officical releases are so rare add to this feel. I wish next release will be soon and with stable msbuild support :-) PS Martin I'm very grateful for the work that you've done towards the msbuild-solution task. Thanks much! :-) You are (of couse!) free to experiment with that solution handling. It shoudn't be difficult. And btw: I'm not afraid of .sln parsing. We could handle new format at time MS publishes it. Regards, 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
[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? btw: Martin
