RE: [nant-dev] Current NAntContrib policy?
Hi James, Thanks << I'll look into fixing #2 early next week... I wasn't aware of #3, so if you want, submit the patches and I'll get them checked in. >> Thanks. I should be able to commit the changes myself (at least, I hope no-one removed my CVS access yet ;)). I wanted to check if anyone has run into that situation and make sure I'm not screwing someone else before commiting the patch. -- Tomas Restrepo [EMAIL PROTECTED] --- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
[nant-dev] Current NAntContrib policy?
Hi Guys, What's the current NAntContrib policy regarding Nant releases? I remember there was once talks of ensuring that NAntContrib worked only with a specific release of Nant, so I'm not sure right now... I needed a new release recently, so I decided to go back and rebuild both nant and nantcontrib from scratch from CVS, and had a little trouble getting nantcontrib to build. Specifically, in case anyone is interested, here are the issues I've found: 1- There seems to be some issues with filesets if a exclude containing a **.* is used. Specifically, In the NAntContrib.build file, in the build task, the sources fileset for CSC task says: For some reason, the last line caused the fileset to end up empty when compiling agains whatever was in CVS on Thursday. Changing it to , fixed the issue. 2- The XSD for the MSI tasks is somewhat old, and needs to be updated to reflect some changes in the nant structure; particularly, the way and was renamed (otherwise, when using recent nant/nantcontrib you will always either get a schema validation error, or a nant warning). 3- The MSI task seems to have a problem some other people have reported, but that doesn't seem fixed, in that running it might cause a "could not create interface" error. It's actually pretty easy to fix correctly, so let me know if you want me to commit the fixes.. I'm sure there are other things around ;) -- Tomas Restrepo [EMAIL PROTECTED] --- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] Solution/Project Parser
Matthew, > I'm also getting close to wanting to use NAnt completely within the > build process. We do this for our project. We actually went a little bit further,and we actually have a single VS.NET solution and project that *never* get built, it's just for intellisense and the vs.net VSS integration ;) Every developer (the main dev team has about 8 people) builds directly with nant everytime (one of my coworkers came up with the idea to add a custom tool to vs.net that fires nant for the project and puts the nant output in the vs.net output window. nifty!). No problems with this setup, really. The project is not too bit, though, consisting of about 20 dlls or so, and 200.000+ lines of code, with a fairly complex build and install process (for gac and COM+ registration). -- Tomas Restrepo [EMAIL PROTECTED] --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
RE: [nant-dev] Namespaces and NAnt.Cnntrib tasks
Hi Ian, Gert, Cc: [EMAIL PROTECTED] Subject: Re: [nant-dev] Namespaces and NAnt.Cnntrib tasks >>NAnt.NUnit.NUnit2 >>NUnitReportTask.cs >> >> > >Hasn't this task been supersedes by http://nunit2report.sourceforge.net ? > > maybe so. I wonder if Gilles will let us ship with it. Its gpl so probably. The NUnitReportTask in NAntContrib only works with Nunit 1 (which afaik we still support). The other one supports NUnit2 that I recall. So it would be nice to have both, certainly. -- Tomas Restrepo [EMAIL PROTECTED] --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
RE: [NAntC-Dev] RE: [nant-dev] NAntContrib update was ( Updating Nant-Contrib to latest Nant)
Hi Ian, << I'm not so sure. I see NAnt.optional as a place for new tasks that may or may not be useful. >> I guess this is what I don't like. Useful? Uhh... If someone wrote the damn thing, I'm sure *they* considered it useful. Who are we to decide what is "useful" and what not? But, if you guys decide we should be so bold as to take on that decision, then it becomes much easier: don't accept things that are *not useful* in the first place, and now you don't need NAnt.Optional again. If you were to say Nant.Experimental, well, that would convey a completely different meaning jejejeje -- Tomas Restrepo [EMAIL PROTECTED] --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
RE: [NAntC-Dev] RE: [nant-dev] NAntContrib update was ( Updating Nant-Contrib to latest Nant)
Hi Ian, << totally. I have been meaning to move about 6 tasks into Nnt.DotNet ( gac, xsd etc ) and some others into NAnt.Win32 ( comRegister etc ) First priority was to get everything compiling. We can move tasks to their appopriate namespaces as needed. However I would still consider tasks like starteam optional - apologiesto those starteam users who consider them crucial. >> Humm That sounds much better. Still, I'd personally prefer not to end with something like Nant.Optional :) I believe we could move these into their own assemblies and then just do whatever we want in how to build them (the organization thingie seems to be creeping up again :P). Anyway I'm guessing the real problem is what should go on in the basic distribution << re I hear you and hopefully this will be the last of the re-structuring for a good while. I think the code base is cleaner for it and it will help us going forward. I apologise for the inconvenience to task writers. However it took only around 3 hours to get all of NAntContrib ( 48 tasks ) compiling. Granted I have more familiarity with the nant sources and what has changed than most task writers so I'd be happy to put together a checklist for moving tasks to compile to the latest nant. >> I also tried moving the sources last night but got a little bored after around 1 hour... Had most of it compiling, too, but then again, I'm fairly familiar with both Nant and NAntContrib (heck, I wrote my fair share of the tasks in NantContrib, after all). The checklist sounds like a very good idea! << re version number - like many open source projects we've just kinda been bumping it every time there is a release. Personally I think that with the recent addition of fileset references, cvs tasks and multiple framework support NAnt is getting close to feature complete. After the upcoming release I propose that we gather a list of required features for 1.0 and start setting up a timeframe. You are right - nant has been out there for quite some time now and is used by more and more people. Its getting stable enough that we can stop making re-structuring changes that will break existing tasks - unless there is really good reasons for adding them. >> That sounds like a real treat. -- Tomas Restrepo [EMAIL PROTECTED] --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
RE: [nant-dev] RE: NAntContrib update
Hi William, << As you say, NAnt is not yet at 1.0, isn't it an unrealistic expectation of us early adopters to use a pre-1.0 release and constrain its developers not to change the system radically as they learn new things in order to get the product to 1.0? >> I know about this. However, I'd argue against the use of the term "early adopter", and even more about the maturity of nant. Let's face it, nant has been usable for a long time. Heck, we've been using it successfully to build our project on a daily basis for more than *a year*. Early adopter? Then, perhaps, but you can hardly talk about preiews and early adopters on a system that has been on public use for year and a half at the least. And allow me to go even further: Look at all the big changes that have been made to nant over the past few months. It has become a much more complex piece of software, and it certainly has a large ammount of new functionality. And yet, with all those big changes, nat has only been declared up toa tentative 0.8.3 release. Heck, we've been strayining on the 0.8.X branch for what? More than six months, certainly. At that pace, how long will it take for a 1.0 release to come out? At least one year more at that speed. If the intention is to keep the nant core so unstable until that time, please, by all means let everyone now so that however wants can just fork over and forget about the actual nant project until that time, because the breaking changes have become so common that it's just not worth it anymore to keep up with it. Now, realize I'm not arguing against changing nant, or improving it. I'm arguing against doing it with no regards to ensuring people can keep up with it. -- Tomas Restrepo [EMAIL PROTECTED] --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
RE: [nant-dev] NAntContrib update was ( Updating Nant-Contrib to latest Nant)
Ian, << OK I bit the bullet on this today and copied all the NAntContrib tasks to a new NAnt.Optional directory under my nant source tree. I went thru and fixed all the issues Mike mentiond and then some. Nothing too difficult just lots of find and replace. It all compiles and the tasks load fine. I'm not going to commit this to the nant tree just yet because: 1) I don't think we are quite agreed that we should move all those tasks into NAnt ( although I'm starting to lean that way ) and 2) if we do move them I'll get the sf admins to import the .rcs files so that we can preserve the history. what I'll do is post the updated source as a zip tomorrow so that people can try it out and test that their favourite nantcontrib tasks are still working. NAnt.OptionalTasks.dll and dependencies weigh in at around 1mb which won't make the distribution too much larger. I'm going to propose that the optional stuff goes into a subdir of bin. so: bin\optional this way there is less clutter in the main bin directory and users will be able to change a taskpath setting in the config file to prevent scanning of NAnt.OptionalTasks.dll for tasks if they don't want to use it. so any feedback on the strategy to take - and stay posted for that .zip. >> Why optional? If we're gonna move them, you might as well move them right. For example, some Nant tasks should go into the main Nant builds... Things like GAC and XSD are fairly common DotNet development operations (I don't know what criteria you guys are using for separating the tasks, though, so I may be mistaken here). That said, I'd like to take the opportunity to vent something that has been nagging me for a while: All the continous Nant restructuring. Granted, some good things have gone on, and the base is much clear. However, I'm going to be brutally honest here: Even though no 1.0 release of nant has ever been done, it has been used by people to build *real* systems for a really long time now. And you know what? Everyone I've met using Nant has created their own tasks to make their builds more powerful/simple/easier, and that's a *good* thing. However, all the restructuring going on keeps breaking their tasks code, and that ain't nice. Hell, we can't even keep NAntContrib compiling and that's supposed to be *the* nant partner-project. How do you expect people to keep up with all the changes you guys do? (and I'll be even more brutal here and say many of those changes have been fairly gratuitous, with very, very little added value). My big point is that many of the changes were done with little or no regard to the impact they might have on code outside the actual nant code base, and that's a problem now. One I personally consider a serious one. The sad part is, many of them could've been done in a gradual maner, deprecating and wrapping things so that people could slowly migrate things over. Things like the logging infrastructure, Option sets, etc, could've been approach in such a way that they didn't force people into having to change perfectly working code all at once, for example. If you want people to use nant effectively, and be able to take advantage of what new builds of Nant offers easily, you need to start taking into consideration just how easy is going to migrate to a new build, and that takes far more than simply ensuring the .build files are valid. Just something to think about. -- Tomas Restrepo [EMAIL PROTECTED] --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] NUnit 2.1
do things as I want them (which I'll be the first one to say is likely not how other people want them to be) for my own personal use, but it will have to wait until I have the time. -- Tomas Restrepo [EMAIL PROTECTED] --- This SF.net email is sponsored by: Scholarships for Techies! Can't afford IT training? All 2003 ictp students receive scholarships. Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. www.ictp.com/training/sourceforge.asp ___ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] attachment etiquette for contribution
Phlip, > I had sent an attachment with my NAntExplorer code and binary, around 250K. > It's stuck in the moderation queue. How do people prefer to have this sent? > If need be I can go source only with a build file, but it would still be over > the 40K list limit I think. My personal preference would be to send anything that big to one of the people with commit access on personal email, once it has been discussed and it has been agreed to be included in NAnt/NAntContrib (which I think it already was :-) ). Once comitted, a simple announcement could then be sent to the lists (nant-users would probably be more appropriate). What do others think? -- Tomas Restrepo [EMAIL PROTECTED] --- This SF.net email is sponsored by: Scholarships for Techies! Can't afford IT training? All 2003 ictp students receive scholarships. Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. www.ictp.com/training/sourceforge.asp ___ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] (no subject)
Mike, I'm certainly not saying drop NUnit 2.0 support in favor of 2.1 support. I'm still asking what those short commings in the runner where. I haven't seen anything on the nunit mailing list, at least not for quite some time. We can't fix it if you won't tell us what the issues are. I'm not getting a lot of complaints on it on the nunit mailing lists. So please tell me what the issues are. I did post about some of them once. I even got a reply from you, but it seems no one still got the crux of the problem. So it seems everyone is just content with how NUnit 2.0 works. I have to admit I had an easier time with the original implementation of nunit2 support than this one. I completely admit that I made a serious error in judgement using the fork attribute. This seemed to cause quite a bit of confusion, but I very very intentionally wrote it to use TestDomain. I knew what the plans for that interface were. I also knew that the interface RemoteTestRunner was much more likely to change than TestDomain. If you want to take it over, be my guest. I'm pretty much dropping NUnit 2.0 myself, and will probably look to either using a different framework or sticking with v1. NUnit 2.0 made it way to complex for my taste to do things how *I* wanted them. -- Tomas Restrepo [EMAIL PROTECTED]
Re: [nant-dev] Nant test-build broken?
HI Ian, > I just backed out your change to NAntTest.cs and it builds and tests for > me. I'm going to commit this so that people can build. Great, thank you :) I was just able to run all tests, and committed the NUnit2 patch for the current directory thingy. -- Tomas Restrepo [EMAIL PROTECTED] --- This SF.net email is sponsored by: Scholarships for Techies! Can't afford IT training? All 2003 ictp students receive scholarships. Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. www.ictp.com/training/sourceforge.asp ___ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
[nant-dev] Nant test-build broken?
Hi Guys, OK, is it just me, or is NAnt's build/test broken? During build on my machine, when the unit tests get running, NAnt seems stuck in an infinite loop spanning instances of NAnt.exe :( -- Tomas Restrepo [EMAIL PROTECTED] --- This SF.net email is sponsored by: Scholarships for Techies! Can't afford IT training? All 2003 ictp students receive scholarships. Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. www.ictp.com/training/sourceforge.asp ___ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] NUnit2.1
Hi Mike, <> Quick question here: Are you proposing wew dump NUnit 2.0 support in favor of 2.1, or keep them both? Unless we deal with this correctly, it could become a mess Notice: I haven't taken a look at the new version yet. I certainly hope several of the runner shortcomings have been fixed, but I'm not much hopeful. -- Tomas Restrepo [EMAIL PROTECTED] --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] Behavioral differences between NUnit V2.0.6 and th e task
Mike, << That will allow it to find the assemblies, but it still does not help tests that use relative paths in their code. Could be I'm missing something. >> This was discussed quite a bit of time ago here. I was the one to argue that NUnit2's behavior is dangereous, in the sense that using relative paths like this usually leads to code that is subtly broken, and certainly feeble. IOW, relying on the current directory to be the directory where the exe/dlls are stored is a terrible idea. I say this from experience: I've seen way too many people getting bitten by this in the long run not to care about it. However, quite a few people seem to think that's the best behavior, and that it should be that way... well, who am I to argue. It seems I never did patch it, so give me until tonight (can't do it from work), and I'll add the patch in. -- Tomas Restrepo [EMAIL PROTECTED] --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] .NET Framework 1.1 version of nant
Actually, what I'd like to see is for us to have a way to use NAnt to build applications for whatever version of the framework you want without having to explicitly recompile NAnt itself for said framework. [1] I think that, In the long run, this is an strategy that could me much more useful... [1] Actually, this is one of the reasons I prefer nant invoking the .NET tools themselves, instead of using the internal .NET framework classes to do the work. Then again, this is just my opinion :) -- Tomas Restrepo [EMAIL PROTECTED] - Original Message - From: "Ian MacLean" <[EMAIL PROTECTED]> To: "Gert Driesen" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Sunday, February 23, 2003 10:01 PM Subject: Re: [nant-dev] .NET Framework 1.1 version of nant > Gert, > > Do you mean "built on 1.1" ? If so then I would say no - at least untill > 1.1 becomes the platform most users are running on. If its really needed > you ca always grab the dource and build it yourself on 1.1 > > Ian > > Hi, > > > > Are there plans to release a separate .NET Framework 1.1 version of NAnt > > (possibly in the same distribution) ? > > > > Does anyone knwo if there be .NET Framework 1.1 versions off NDoc, > > SharpZipLib and NUnit ? > > > > Thansk, > > > > Gert > > > > > --- > This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. > The most comprehensive and flexible code editor you can use. > Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. > www.slickedit.com/sourceforge > ___ > Nant-developers mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/nant-developers --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] Next release
> Two points in particular that I had, or am having a hard time with: Slingshot > and the process flow to use it, and Web projects. We have a fairly complicated > set up here, with a half dozen or so core objects shared by different > applications, and then separate solution files that are kept outside of the > normal source tree, so that each SLN only references what it needs, so the > normal HelloWorld samples dont apply very far. I haven't gotten into VSS > integration yet, but thats probably going to be at the top of my mind soon too. Try starting asking your questions here. Many of us have gone through that process ourselves, so we might be able to offer some advice :) > Have you considered hosting a Wiki for keeping and maintaining documentation? That sounds like a great idea. Scott, what do you think? If there's any problem with getting it on the sourceforge servers, I'd be willing to share some space on my hosting (provided we find a wiki we can run there). -- Tomas Restrepo [EMAIL PROTECTED] --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] Next release
Scott, > > I'm really leaning towards tossing a build out in the next day or so with > the cvs changelog and not many more docs. > I'm cool with that. Let's get something rolling and, then we can put out a .1 release with better docs, whatever. -- Tomas Restrepo [EMAIL PROTECTED] --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] Next release
<< >What can we do as a community to ensure that this >doesn't happen again? I would say the best solution is for people to jump on board and volunteer one of the tasks Scott outlined... >> I think part of the problem is that it seems Scott is the only one of the project admins that has been around for the past few weeks (months?) devoting any real time to nant, and he's the one in the best position to do anything (and probably the only one with permisions to actually do the final release). Personally, I'm a little busy now, so that's why I've only contributed marginally lately, but if I can do anything to speed up the process, let me know. Also, consider that last time the topic came up, I said the NUnit2 support stuff was a showstopper, and I've since fixed it (what could be fixed without changing NUnit itself). -- Tomas Restrepo [EMAIL PROTECTED] --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] nant.location?
Hi Scott, > Yep, I did this. It happened when I added shadowcopyfile support. I will do > a Path.GetFullPath to resolve the problem. We should also add a test for > this. :) Ahh, gotcha! :) -- Tomas Restrepo [EMAIL PROTECTED] --- This SF.net email is sponsored by: Scholarships for Techies! Can't afford IT training? All 2003 ictp students receive scholarships. Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. www.ictp.com/training/sourceforge.asp ___ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
[nant-dev] nant.location?
Hi guys,
Has anyone recently changed what value ${nant.location} gets initialized to?
Or has the processing of filesets changed recently?
I've been having to modify some buildfiles I have because of one of these
things, because I was doing things in a fileset like:
Now, it fails because ${nant.location} apparently gets initialized with a
terminating "\", so the resulting path ends up something like
E:\Projects\sf\nant\build\nant-0.8.0-debug\bin\/NUnitCore.dll, which the
fileset seems to be discarding.
Any ideas?
--
Tomas Restrepo
[EMAIL PROTECTED]
---
This SF.net email is sponsored by: Scholarships for Techies!
Can't afford IT training? All 2003 ictp students receive scholarships.
Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more.
www.ictp.com/training/sourceforge.asp
___
Nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] NUnit Error With NAnt...
Hi Scott, > True. It took me a little while to see this. But now I understand things > much better. And I think I better understand where some of the issues are > coming from. > > In addition to the changes you made, I think we need to set the environment > working/current directory to the basedir. This will allow tests to > open files and work with IO related operations as they might expect. Then > after the task finishes, we can set the current directory back. This is a > process level change, so we kinda have to be careful. Actually, I struggled with this while making my changes... the original NUnit2.0 code does this, I think, but I believe this is fundamentally wrong, and will actually end up "hiding" latent bugs. Let me put it this way: Any code that relies on the CurrentDir to be set to a specific value at application startup is fundamentally broken, and likely reveals the developer's not familiar with the real usage of the CurrentDir setting. If tests need to ensure the code has a known current directory before invoking the tested methods, they should explicitly set it themselves or on the tests StartUp() routine. -- Tomas Restrepo [EMAIL PROTECTED] --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] NUnit Error With NAnt...
Scott, > Yes, the fork option was removed and made the default(sort of). Now (as of > oct I think) nunit2 tests create a new appdomain to execute in. Indeed, this should be how it always works, now (assuming nobody undid the changes I made last time to it ). It's worthwhile to notice that this is essentially what NUnit 2.0 own console and GUI drivers do, too. -- Tomas Restrepo [EMAIL PROTECTED] --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] SQL queries and mantis bug tracker
Jason, << In our NAnt project I was thinking it would be hot to query our Mantis Bug Tracker (http://sourceforge.net/projects/mantisbt) to get a list of all bugs which have been resolved and thus are ready for testing in the current build. We have a mail task which notifies a group of the new build, and I'd like to post the list in the message body with hyperlinks to each bug. The feedback I'm looking for is this: In general, is anyone doing database queries in a NAnt task? Would you mind sharing your strategy for this? The simple solution I imagine is a exec or script task, but I don't know how to get the results back into NAnt. A more robust solution would be to build a new NAnt task. >> I would suggest writing a small NAnt task that queries the database and stores the result as XML into a user-defined file,then grabing that and transforming it with an XSLT template into HTML or text you can include in your message. Doing so should be, overall, a fairly trivial exercise. -- Tomas Restrepo [EMAIL PROTECTED] --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: NUnit 2 support (was: RE: [nant-dev] FAQ: The next NAnt version)
Bernard, > Since you probably know best how the NUnit2 integration works, would you > be willing to make these changes? > Unless there is a better and easier solution. Sure, I can do that, no prob I'll take a stab at it tonight. -- Tomas Restrepo [EMAIL PROTECTED] --- This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power & Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en ___ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: NUnit 2 support (was: RE: [nant-dev] FAQ: The next NAnt version)
Hi Bernard, << If the fork attributes would be removed and set to true internally, and (only) the NAntContrib tests would be run using the command line runner, would there be other problems that need to be solved to make the NUnit2 task work for real-world usage? >> I think that would work out, yes. But since we are on a related topic: Does anyone think there's still a place for the NantContrib project? I've been thinking about this for a while, and my POV is that with the large NAnt refactoring that was done last time, most of NantContrib's tasks could be rolled into the appropriate NAnt assemblies most are fairly mature now, and some tasks in nantcontrib really belong there... I'm not sure if it's worh it to keep them separated anymore. Any thoughts? -- Tomas Restrepo [EMAIL PROTECTED] --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: NUnit 2 support (was: RE: [nant-dev] FAQ: The next NAnt version)
John, > I noticed that NUnit2Task was executing very different code based on the > fork attribute; code that looks suspiciously like the current code in > nunit-console. I'd like to refactor that code slightly, but that's a different thing altogether :) > Maybe this is a simpler workaround than using exec? It is a good workaround for many apps. However, I'd like to point out two things: - With the current NUnit2 architecture, the fork="false" (the default) option makes no sense, as it really, really, only serves to test nant itself. In fact, fork="true" should be the default, as that was how NUnit2 was concieved: a new appdomain is created, and assemblies to test are loaded into that appdomain from inside itself (hence all the problems we have). -Even with fork="true", nantcontrib tests still cannot run. The problem is that nantcontrib requires both access to nantcontrib's and nants dlls, and with the current architecture this is hard to do without some rather ugly hacks (at least as I see it). -- Tomas Restrepo [EMAIL PROTECTED] --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] FAQ: The next NAnt version
Bernard, > In short, bringing out a new release (0.8.0) is needed. > Note: A combined NAnt + NAntContrib package Would Be Nice as well, but > first things first. > > I suggest a no-new-features-are-needed approach for this version. > The question is: What really *needs* to be done before the new version > can be released? > > I am aware of the NUnit to NUnit 2 migration, and have been able to use > the latest NAnt and NUnit 2 using the exec task/console runner workaround. I fully agree with all of this. Note, however, that NUnit2 support in NAnt is already there, unfortunately, as I see it, it's pretty much useless except for testing nant itself... heck, can't even build the nantcontrib tests as is. I've been looking at this from all possible angles, and at least to make it work as *I* think it should, I see no other option short of modifying part of NUnit2 itself (yuck) or rewriting a large part of what it already does inside nant to support it (double yuck). This, at least, makes building nantcontrib in full impossible at the moment unless we eliminate one of the task tests in it :( If anyone has any better options, I'm all ears :) -- Tomas Restrepo [EMAIL PROTECTED] --- This sf.net email is sponsored by: Battle your brains against the best in the Thawte Crypto Challenge. Be the first to crack the code - register now: http://www.gothawte.com/rd521.html ___ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] Error on relative path in AssemblyKeyFile
Matthew, > Who would I ask for CVS commit access to the NAnt core? I won't commit > anything without posting a patch for review on the list first. Gerry, Scott or Ian would be the ones to ask... It's nice to see so much interesting activity on our NAnt community :) -- Tomas Restrepo [EMAIL PROTECTED] --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] NUnit2 task assemblyname attribute problem
Hi Gerry, > Yes, this seems like either: > 1. We are missing something, or > 2. A mistake. > > Tomas can you post (maybe just send the post you sent here) to them? > You seem to have the most experience with the issue. Done. I'm waiting to hear on more information. From what I can gather now, it seems now you must always set up a new properly configured appdomain for the tests. I've digged into NUnit's implementation more, and it seems that a ton of it expects to be able to load the test dlls using standard assembly loading rules that apply to loads using unqualified assembly names. This is exactly the crux of the problem right now. It also seems that the current code in nunit would inhibit the use of certain features we took for granted in nant with nunit 1.0, like having the nant/nunit dlls load automatically from nant's directory (which doesn't seem to work now with 2.0... at least in the cases I'm trying), and some other functionality that had been added to nant, such as the ability to specify which config file to load. So, right now, with what little I know about the nunit implementation, I can't see any other way to regain all this without reimplemeting pretty much everything from TestSuiteBuilder upwards (basically that, plus RemoteTestRunner and TestDomain). It's not really that hard, but it is very annoying... I'm still holding out for a better way to do this, but as thing stands, nantcontrib is right now stuck, testwise, and at least I won't be able to use nunit 2.0 for my largest project :( -- Tomas Restrepo [EMAIL PROTECTED] --- This sf.net email is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en ___ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] NUnit2 task assemblyname attribute problem
I forgot to add that, right now, can't find a way to get the tests in nantcontrib to compile... TblTaskTest derives from Nant's BaseTest class, which was modified to fit into NUnit2, and if I modify everything in nantcontrib to suite NUnit2, I can't run the tests anymore from the buildfile... talk about a catch 22. - Original Message ----- From: "Tomas Restrepo" <[EMAIL PROTECTED]> To: "'Nant-Developers (E-mail)'" <[EMAIL PROTECTED]> Sent: Tuesday, October 29, 2002 8:34 PM Subject: [nant-dev] NUnit2 task assemblyname attribute problem > Hi guys... > > I've been updating tonight the NAntContrib code to use the new NUnit2 tests, > and quite quickly ran into a gotcha with the new assemblyname attibute: It > is exactly that, an assembly name, and cannot take an assembly _file_ name. > > In fact, the build files for nant itself pass in an assembly file name > instead of just an assembly name, which is wrong, and happens to work just > because of sheer luck. > > The reason for this problem is that, deep inside, the nunit2 task ends up > calling the Load() method of NUnit's TestSuiteBuilder code, which has, imho, > a horrible problem: It indeed takes an assembly name instead of an assembly > file name... a terrible design mistake in my opinion, though. > > Of course, the problem is that TestSuiteBuilder::Load() calls > AppDomain::Load() inside, instead of doing the more sensible thing, which > would be an Assembly::LoadFrom(). Of course, without this, the nunit2 > assemblyname attribute is useless unless the DLL containing the test classes > is also located _in the same directory as nant's binaries_. > > > Then again, this is just my opinion. > > I don't know anything about NUnit's internals, nor do I know what they > pretended to do, but right now, this doesn't look good and puts a bit of a > showstopper in nant :( > -- > Tomas Restrepo > [EMAIL PROTECTED] > > > > --- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > ___ > Nant-developers mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/nant-developers --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
[nant-dev] NUnit2 task assemblyname attribute problem
Hi guys... I've been updating tonight the NAntContrib code to use the new NUnit2 tests, and quite quickly ran into a gotcha with the new assemblyname attibute: It is exactly that, an assembly name, and cannot take an assembly _file_ name. In fact, the build files for nant itself pass in an assembly file name instead of just an assembly name, which is wrong, and happens to work just because of sheer luck. The reason for this problem is that, deep inside, the nunit2 task ends up calling the Load() method of NUnit's TestSuiteBuilder code, which has, imho, a horrible problem: It indeed takes an assembly name instead of an assembly file name... a terrible design mistake in my opinion, though. Of course, the problem is that TestSuiteBuilder::Load() calls AppDomain::Load() inside, instead of doing the more sensible thing, which would be an Assembly::LoadFrom(). Of course, without this, the nunit2 assemblyname attribute is useless unless the DLL containing the test classes is also located _in the same directory as nant's binaries_. Then again, this is just my opinion. I don't know anything about NUnit's internals, nor do I know what they pretended to do, but right now, this doesn't look good and puts a bit of a showstopper in nant :( -- Tomas Restrepo [EMAIL PROTECTED] --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] Two new global task attributes
Hi Gerry, > Well tasks would have the final say as to what to do (since they'll have > to be implemented). Think of it as additional information as to what > should be displayed if everything goes according to plan. > > In a -verbose setting or error condtion I'd the message would still be > displayed along with any additional information. OK, that sounds fairly good. Personally, I'd prefer we'd set some sort of "expected behavior", so that all tasks worked in a consistent manner, but it would be hard to enforce, though... > I'll implement it just on the task for now and see how that goes. > If we like it for more tasks we can move the code. Sounds good! I'll look forward to it :-) -- Tomas Restrepo [EMAIL PROTECTED] --- This sf.net email is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0003en ___ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers --- This sf.net email is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0003en ___ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] Two new global task attributes
Hi Gerry, First of all, force I like. As for the second: << 2. message If this attribute was defined and the task executed normally only the text in the message would be displayed on the console. Using this would allow you to document each step of the build file AND display nicely formatted results to the user. So instead of seeing: [mkdir] Creating directory D:\eagdf\project\NAnt\master/build/nant-0.8.0-deb ug/bin [copy] Copying 4 files to D:\eagdf\project\NAnt\master/build/nant-0.8.0-deb ug/bin You could see: [mkdir] Creating build directory [copy] Copying required assemblies to build directory The message attribute would be very useful on the task. >> I'm not quite so convinced about this one. Are there any especific tasks you'd like to see that supported this? (besides exe)? I'm also worried about the possible complexity it would bring to tasks just to get them to print a simple message. For example, how would it relate to Verbose? WHich one of them would get priority? -- Tomas Restrepo [EMAIL PROTECTED] --- This sf.net email is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0003en ___ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] Two new global task attributes
Gerry, << I think the usage you want is somehting like: nant -D:force=true build This would need to set something (a property called nant.force?) that tasks should look at? Ugg... I see you what you mean. It's getting a bit ugly. Lets put that on the back burner until a good solution comes along. >> This is a little different than other approaches we've had before, but here's one approach I think could work: Don't make it an actual property! Instead, make it an actual command line switch, like: nant.Console.exe -force build Then, have that set a real Property of the Project class with that value. That way, tasks could just go ahead and use: if ( Project.ForceBuild ) // do x For all we care, this could be stored as an actual property in the project's PropertyDictionary (say, nant.force as you suggest, or perhaps, nant.project.force), so that it could be included in conditions in the buildfile, but that would merely be an implementation detail as far as the actual tasks is concerned. How about that? -- Tomas Restrepo [EMAIL PROTECTED] --- This sf.net email is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0003en ___ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] bug - Calling SysInfo Twice
Hi Ian,
> So I'm happy to go with Tomas's solution - leaving the sys properties
> non read only.
OK, I'm game. I've done the fix and added a couple of new unit tests to the
SysInfo task to ensure both conditions hold true :)
While looking through the code, though, I noticed that the code in
PropertyDictionary's indexer is:
set {
if (!_readOnlyProperties.Contains(name)) {
Dictionary[name] = value;
}
}
Now, this will silently be ignored if the property is readonly. Somehow, I
don't think this is good behavior; it's confusing at best. Even more
cumbersome is the fact that some of the code is relying on this wicked
behavior. For example, unit tests for NAnt.Console actually _check_ for this
silent change attempts to be ignored.
Any comments?
--
Tomas Restrepo
[EMAIL PROTECTED]
---
This sf.net email is sponsored by:
Access Your PC Securely with GoToMyPC. Try Free Now
https://www.gotomypc.com/s/OSND/DD
___
Nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] bug - Calling SysInfo Twice
Hi Kevin, > I traced it to PropertyDictionary.cs not checking to see if a property was > already present before adding it. > > Here is my fix sorry about the lack of diff. Basically added a check to not > allow duplicates to the PropertyDictionary. The fix seems to already have been commited by someone else. However, may I argue _against_ this fix? There are two reasons I don't like it: a- It changes semantics. PropertyDictionary inherits from DictionatyBase. Common semantics in all of .NET standard dictionary collections dictate that you can't add the same item twice. This change breaks that. b- Common sence would dictate that the results from the sysinfo task should be added as readonly properties. Currently, they are not, since it uses PropertyDictionary::Add(), not AddReadOnly(). My proposal for a fix would actually be to leave PropertyDictionary alone, and instead modify SysInfo so that it uses indexer access to add it's properties. That simple change would satisfy both elements I outline above. What does anybody else think? -- Tomas Restrepo [EMAIL PROTECTED] --- This sf.net email is sponsored by: Access Your PC Securely with GoToMyPC. Try Free Now https://www.gotomypc.com/s/OSND/DD ___ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] Fileset change
Hi Gerry, > > I'm wary of using whitespace as a delimiter. > > Right now target names are delimited by white space. OK, I should've seen that one coming :) I should've been more specific: I don't like line separators (whatever you defined them as) as delimiters for this kind of thing. > If you need to have a string with spaces you need to use a different method > (ie, the style). See, that's one of the things I don't like, precisly. If the whole intention is to make it easier for people to read and write buildfiles, having to do things in two different ways depending on such a simple thing doesn't make it easier at all... only more confusing, in my mind. But it does bring two questions I haven't seen addressed in your posts: - Would you consider keeping supporting the ? As long as that's there, I'd be happy, as I probably wouldn't use the other one :) - If people had the "strings with spaces" issue, what would be the supported way to address it? There are a few options I see: - Make every entry in the fileset use the syntax - Allow mixed content in the fileset element (yuck!) - Allow you to split the fileset in two elements (yuck, too) -- Tomas Restrepo [EMAIL PROTECTED] --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] Fileset change
Hi Gerry, > What do people think of this addition to the format of filesets? Humm... I must admit I'm not crazy about it either, and I don't feel it is all that much intuitive compared to what we have now. Ian's reasons sound pretty important to me, too. -- Tomas Restrepo [EMAIL PROTECTED] --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
RE: [nant-dev] StackTrace and rethrowing exceptions
Owen, >While attempting to trace a bug in one of the tasks, I came across a >'feature' of .NET exception handling: rethrowing a caught exception >overwrites the stack trace of the original exception. Actually, this has nothing to do with the .NET exception model, it is just a lesser-known C# semantic. The problem is that the code is explicitly thrown a new exception (the fact that it is an existent exception object is irrelevant here), instead of actually rethrowing the exception. The correct way would be to use the 'real' rethrow operator, namely a throw with no arguments. IOW, just replace throw e; with throw; in the catch clause. For those with interest in the actual C# spec, this is discussed in section 15.9.5 of the ECMA C# spec, which says: "A throw statement with no expression can be used only in a catch block, in which case, that statement re-throws the exception that is currently being handled by that catch block." -- Tomas Restrepo [EMAIL PROTECTED] --- In remembrance www.osdn.com/911/ ___ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] Moving Project::ExpandProperties
> > Would anyone object to moving the ExpandProperties() method currently > defined in the Project class off to PropertyDictionary itself? I think it is > more appropriate there, > > Sounds like a good plan. Done now. -- Tomas Restrepo [EMAIL PROTECTED] --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
[nant-dev] Moving Project::ExpandProperties
Hi Guys, Quick question here: Would anyone object to moving the ExpandProperties() method currently defined in the Project class off to PropertyDictionary itself? I think it is more appropriate there, as, for one thing, expanding the strings doesn't actually require the full project object, just the property list. Of course, I'd leave the ExpandProperties() method in Project as a simple forwarder to PropertyDictionary. The reason I want to do this is because I'm looking into adding property expansion to one of NAntContrib's tasks (the SqlTask, in particular), but the code that deals with the actual strings being expanded is not in the task class itself, but rather one of its helper classes. In this case, passing a reference off to the utility classes seems overkill to me, and would make testing much harder, as opposed to simply passing a reference to the PropertyDictionary. What do you guys think? -- Tomas Restrepo [EMAIL PROTECTED] --- This sf.net email is sponsored by: Jabber - The world's fastest growing real-time communications platform! Don't just IM. Build it in! http://www.jabber.com/osdn/xim ___ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] XmlLogging mods
Hi Gerry, > I've taken a look at it and it seems like what we want. I'd say wait > until Tuesday and if nobody votes against it commit it. Thanks Tomas. OK, will do :) > Oh, and re: the SqlTask. If that is going to be Sql Server specific I > think we should move it to the NAntContrib project. I'd like to keep > the nant project compilable by the mono project. Well, two things: 1) SqlTask has always been in NAntContrib :) 2) It currently uses the OleDb provider, since I figured it should be able to work on any number of databases. (the basic task works in the way of Ant's Sql task, which allows you to specify the statement delimiter, etc). However, that probably won't help in compiling it with Mono, I'm afraid... I'm hoping that abstract ado.net [1] gets to a more advanced stage so that I can switch to using it... (or at least till I get some free time and perhaps help Justin along with it... if he wants) [1] http://abstractadonet.sf.net/ -- Tomas Restrepo [EMAIL PROTECTED] --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] XmlLogging mods
> I have implemented Xml Logging for use on an upcoming project, and so I > wanted to submit a patch and the files in the in the event that the nant > maintainers find it goes in the direction they have envisioned for logging. > My hope is that it provides a good foundation for that effort. This sounds like a wonderful patch, and I think it would be a great foundation. I had a very basic text-based logging on NAntContrib, but it really wasn't much. I'd love to have this capability in order to enhance my reporting capabilities (I could really add this to my daily builds to complement the NUnitReport's I'm generating). What does everyone else thing? I'd be happy to commit this if someone hasn't already, but It's Gerry's/Ian's/Scott's decision in the end... -- Tomas Restrepo [EMAIL PROTECTED] --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] SQL Task GO support addition?
Hi Kevin, > If you have ever tried to process sql scripts that a dba created for running > under ISQL. You may have run into the problem with multiple GO statements in > a long SQL query. > > Attached is support for GO statements in SQL queries. Not sure if anyone > would find this useful other that myself and people in SQL Server shops. I > have run into this difficulty multiple times in my days of nerdism. > > Basically it splits the sql to be executed on GO statements and executes the > resulting statements one at a time. > > I have not commited this change as I am not sure it is such a good idea. We > may want to subclass the sqltask rather than bolt on this functionality. Actually, this was exactly what the first version of my Sql task did... Problem is, it's terribly inneficient for long batches of sql statements (as is commonly the case with entire DB scripts generated by SQL EE). Unfortunately, there seems to be no other way if you want to run those kinds of scripts (for example, CREATE PROCEDURE statements won't work otherwise). So, what I had in mind was to keep both the statement-by-statement and batched executions models for SqlTask, and add a boolean "batch" attribute to the task to switch between the two. This would be a fairly easy to do change, since I already have the code to do both things in the project's CVS. What do you guys thing? -- Tomas Restrepo [EMAIL PROTECTED] --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
[nant-dev] NUnit Refactoring
Hi Guys, OK, so I went ahead with what I mentioned earlier, and all the initial refactoring is now done. As of now, running NUnit Tests in a separate appdomain works! What's even cooler, I was able to add what I actually needed: If you specify fork="true" for a element, you can now also specify an "appconfig" attribute to the test element that points to an Application Configuration File (otherwise known as app.config). When you do this, NAnt will ensure that the AppDomain that gets created loads that configuration file, which allows your test code to use ConfigurationSettings.AppSettings[] and get the values out of the .config file you specified! I still want to do some refactoring to clean up the NUnit code, as parts of it are no longer making much sense... I particularly want to clean up how the formatters are getting created and put up. enjoy! -- Tomas Restrepo [EMAIL PROTECTED] --- This sf.net email is sponsored by: Jabber - The world's fastest growing real-time communications platform! Don't just IM. Build it in! http://www.jabber.com/osdn/xim ___ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] NUnitTest.Fork
Hi Ian, > Awesome. Go for it. Thanks... working on it as I write this... > > btw do you think we should still call it fork ? The Ant version actually > launches a new VM to run the tests. However fork is shorter than > runInNewAppdomain. Any better ideas ? Honestly, I don't have a better one... I'm open to suggestions, though... -- Tomas Restrepo [EMAIL PROTECTED] --- This sf.net email is sponsored by: Jabber - The world's fastest growing real-time communications platform! Don't just IM. Build it in! http://www.jabber.com/osdn/xim ___ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] NUnitTest.Fork
Hi all, > Unfortunately for us, not, it's not inherited. Basically, for a type to be > actually serializable, the type itself, and all of its base classes need to > be serializable. OK, I've been looking at this some more, and I've come to the conclusion that perhaps all this won't be necessary. However, some hefty refactoring of the NUnit code in NAnt will need to be done. The basic idea would be to completely brake off the dependency in the NUnit classes to the NAnt Element-derived classes, possibly through the use of a couple of data objects. The problem right now is that instances of NUnitTest (which is Element-derived) is passed all around the code, all the way through the ResultFormatters, just to carry some data. Instead, I'd like to contain all that data into a separate class, and make that one serializable, which would avoid us having to touch all the other NAnt classes. Once that is done, we should be able to completely instantiate an NUnitTestRunner _inside_ the other appdomain, without giving it any more info (right now, you need to manipulate lots of properties in a cross-appdomain way, such as the formatters collection). The only downside I can see to this is that there's a chance you wouldn't be able to use the default LogFormatter in this scenario, but I haven't checked that throughly... If no one has any problems with this, I'l start working on this tomorrow. -- Tomas Restrepo [EMAIL PROTECTED] --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] NUnitTest.Fork
Hi Bernard, > > I would keep in mind that NUnit 2.0 [1] is currently in beta and that NAnt > integration is on their todo list. Humm I'll keep that in mind, thanks for the pointer. Unfortunately, I kind of need this _right now_ and would rather take on something I could get working this week. -- Tomas Restrepo [EMAIL PROTECTED] --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] NUnitTest.Fork
Hi Ian, > I wrote the NUnitTask stuff originally. I got it to where it is now, > decided I didn't know enough about app-domains at the time and kinda > backed away from it. I agree we should do the right thing. How many > classes would need the serializable attribute ? Do derived classes > automatically inhereit it ? Unfortunately for us, not, it's not inherited. Basically, for a type to be actually serializable, the type itself, and all of its base classes need to be serializable. In our case, that means that the NUnitTest class needs to be serializable. Since NUnitTest derives from Element, that means Element (and a few classes in between), needs to be serializable. And here's the rub: The Element class holds a reference to the Project it's defined in, so to get automatic serialization, Project itself would need to be serializable. And Since the Project class holds the Task and Element lists, all of those would need to be serializable, too. I'm not sure that's very acceptable right now. Now, One could possibily consider minimizing the list of serializable types, and implement some kind of custom serialization (via ISerializable) in the Element class, but, quite frankly, I'm not sure what we could do on deserialization to get the Project back unless project itself was MBR... It's either that, or perhaps doing a full revamp of the NUnit helper classes so that they don't deal with the build elements/tasks directly but with an alternative class hierarchy that would need to be maintained. So, what do you guys think? -- Tomas Restrepo [EMAIL PROTECTED] --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
[nant-dev] NUnitTest.Fork
Hi Guys, I've been looking around for a solution to a problem I've had for the Unit Tests in our current application, and noticed that running our tests in a separate appdomain might just be what we need to fix the issue. I looked around, and notice, however, that the fork attribute in the current nant NUnit support does not work as is, so I decided to give it a try at fixing it. I've already done some work in this area, and I think it's really not hard to fix. However, I've run into a conundrum, so I thought I'd solicit your input to see what you guys think it's the best alternative: The problem right now is that when the new AppDomain is created, an instance of NUnitTestRunner is created in it. However, this class requires an instance of NUnitTest as an argument to it's one an only constructor. Now, passing it would be no problem, except that it would require the NUnitTest class to be Serializable, or MarshalByRefObject-derived. Personally, I think the first option is the right choice: However, that would impose changes that would rip throughout the entire NAnt library, since all the base classes, attribute classes, etc, would need to become serializable. That means that pretty much everything from Project and Element all the way down would need to be changed to include the Serializable attribute. OTOH, making them MarshalByRefObject would be somewhat simpler, since basically only a few base classes would need to be modified to derive from MarshalByRefObject. Either way, performance could suffer somewhat when running the NUNit tests in a new appdomain, though I think the first option might be a little worse in this. So, what do you guys think? I'd be happy to fix it today or tomorrow, but I want to ensure we do the right thing. -- Tomas Restrepo [EMAIL PROTECTED] --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] Logging and Events
Scott, > Everything textual. Right now this would include anything that is > written to the console via the Util.Log class. I would also assume, > since log4net support modes, we could control the level of logging down > to debugging. I see. That's what I was thinking about. I do have one suggestion, though: We should modify the ExternalProgramBase class to ensure that when the external tool is run, we capture the output and error streams and log that, too. Otherwise things will get really annoying, and not all we (or at least I) would like would be registered in the logs. Does that make sense? -- Tomas Restrepo [EMAIL PROTECTED] --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] Logging and Events
Hi Scott, > I've been giving some thought to logging and an event system for nant. I > don't think these two systems should be the same. They serve two > different purposes and don't need to overlap. > In my mind logging should be done via a mature logger, and it would be > great if we didn't have to write it. I'd like to suggest that we use > Log4Net. Here's one thing I'm not exactly sure of: Just what exactly are we talking about when we say "logging"? -- Tomas Restrepo [EMAIL PROTECTED] --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] 0.8.0.0 Release
Hi Scott, > I've done a release build for testing purposes. Please try this out > tonight if you have any time, > http://nant.sourceforge.net/nant-src-0.8.zip Looks good to me. Seems to work just fine here I just used it to recompile several of my projects with no problems at all (including the one that has about 10 different buildfiles) > After this release goes out we will do a NAntContrib release too. Unless > anyone has any objections NAntContrib releases will include, and depend > on a specific, NAnt release. I'm all for that. The only question is: shouldn't it be the other way around? That is, shouldn't a NAnt release include a corresponding NAntContrib release? -- Tomas Restrepo [EMAIL PROTECTED] --- This sf.net email is sponsored by:ThinkGeek Two, two, TWO treats in one. http://thinkgeek.com/sf ___ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] Interim Release (0.8.0)
> Doesn't anyone have any objections to a new release early next week? Sounds good to me. -- Tomas Restrepo [EMAIL PROTECTED] --- This sf.net email is sponsored by:ThinkGeek Bringing you mounds of caffeinated joy. http://thinkgeek.com/sf ___ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [NAntC-Dev] RE: [nant-dev] Loop Task
Scott, > What about TaskContainer? Either would work for me... -- Tomas Restrepo [EMAIL PROTECTED] --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [NAntC-Dev] RE: [nant-dev] Loop Task
Hi Kevin, > I actually kinda like foreach. Me too. I was referring, however, to TaskWithEmbeddedTasks, not foreach ;) -- Tomas Restrepo [EMAIL PROTECTED] --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [NAntC-Dev] RE: [nant-dev] Loop Task
Scott, > I'm open for suggestions on a better name. :) How about "CompositeTask"? -- Tomas Restrepo [EMAIL PROTECTED] --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] FileSet includes question
Ian,
> I think so. Right now property expansion doesn't happen until just
> before task execution so that would kinda mandate define before
> reference semantics. The other issue is property expansion itself. If
> you're using a referenced Fileset that has a number of ${property} 's -
> do you use the value of ${property} as it was when the Fileset was
> defined or what it is now - where its referenced. I'm thinking you'd
> probably want to re-evaluate the properties.
Good point! That one hadn't occurred to me before. From all of this, I think
Scott might be in the right track, in the sense that doing the double Xml
initialization seems like the easiest way to get the right semantics
going...
--
Tomas Restrepo
[EMAIL PROTECTED]
---
Sponsored by:
ThinkGeek at http://www.ThinkGeek.com/
___
Nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [NAntC-Dev] RE: [nant-dev] Loop Task
Hi Scott, > BTW. I've now got the embedded version working. > > > > > It works; after the first compile and everything. That's great! In the general sense, I think this is much useful, particularly as we could use it as a base for an Ant-like Conditions framework. > Does anyone have an argument as to whether this should go into the NAnt > core or NAntContrib? I'm leaning towards core. I think this should be core functionality. That said, I gotta admit I'm not crazy about the name of the class... ;) -- Tomas Restrepo [EMAIL PROTECTED] --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] FileSet includes question
Hi Gerry, > > humm... For tasks with simple attributes, this makes quite a bit of sense, and it's semantically simple. However, what would be the semantics for more complex elements, say, a FileSet? For example, consider this: What would the semantics be? Should the second FileSet excludes/includes element be "merged" with the original FileSet's filelist? Or should the list be replaced? I think the correct solution would be to Merge them (iow, in the example above, you'd end up with a fileset with two includes and one exclude. However, I'm not sure this would be the best solution in all cases. A second thing I have been considering is that during reinitialization what you really want is to copy the original element instance. IOW, elements should be clonable. Why? Well, if you always made changes on the same object that was initialized when the element with the id attribute was found. Otherwise when you refid'd a single element more than once later in the buildfile, there's no way you could predict exactly what that element would contain. For example, if I created yet another fileset referencing Fileset1 above, what would it be referencing? A FileSet with two includes, or a FileSet with two-includes and one excludes? I think the first behavior is what the user would expect, and it's the easier to deal with in complex buildfiles... What do you guys think? Finally, am I right in assuming that given NAnt's current behavior when loading the buildfiles, this would require that an element can only be refid'd _after_ the original element with such _id_ appears? IOW, in a sortta-programming-language-like way, elements can only be referenced after they have been defined? -- Tomas Restrepo [EMAIL PROTECTED] --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] FileSet includes question
> I was thinking about the id'ed FileSet's. Here is what would need > changing: > > * Add an Id property to the FileSet class I'm kind of curious about why implement it this way it seems to me, that everything in the buildfile should be able to be referenced by an ID, so I'd think a more interesting idea would be to add the Id property to the Element base class, and instead get the Project class to keep a collection of Elements... of course, for larger buildfiles this would imply a fairly heavy runtime memory cost, but perhaps that could be avoided as well (particularly if we don't mind parsing an element twice and "executing" it in different instances... What do you guys think? I admit I have no clue as to what Ant does in this context, though -- Tomas Restrepo [EMAIL PROTECTED] --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
[nant-dev] PropertySet
Hi all! While talking to John Lam earlier tonight, it occurred to me that something like a FileSet, but that deals with properties would be very useful. Something like a "PropertySet", if you will. Basically, the idea would be to have nested elements, like filesets, that defined properties/arguments for a given task. A natural example of it would be the Preprocessor Definitions used by many compiler-related tasks. For example, one could do: ... And so on ( the element names are just ideas.. something better than "include" would be much nicer). Another use would be replacing the "arg" element some task use that seems to be hacked each time for each one of them. The idea would be not to have to reimplement it each time something like this is needed, but instead to have something the NAnt runtime handles for you, just like FileSets are. What do you guys think? -- Tomas Restrepo [EMAIL PROTECTED] Bringing you mounds of caffeinated joy >>> http://thinkgeek.com/sf<<< ___ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
[nant-dev] TaskDef gone?
Hi Guys, I've notice that the TaskDef task source file is no longer on the nant sourcetree. From the comments, it seems it was removed alongside of the tasks that went to nantcontrib, but, naturally, TaskDef is not there either. What's up with that? If it was meant to be fully deprecated, and now you're supposed to copy the extra task assemblies into nant's bin dir, then I'd strongly argue against it, as it really makes it much more annoying to work on separate task libraries (such as nantcontrib), particularly when you need/want to keep mulitple versions of it around... -- Tomas Restrepo Bringing you mounds of caffeinated joy >>> http://thinkgeek.com/sf<<< ___ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: Re: RE: Re: [nant-dev] FileSets and multiple directories
Kevin,
> Oh, I see what you're saying. I guess that would work
> as long as we only have one lib directory for our lib
> files.
Ahh, why? You could just as well use:
where ${netlib} and ${locallib} would be properties pointing to your network and local
library directories, which you'd specify as full paths (or perhaps use environment
variables to hold them).
--
Tomas Restrepo
[EMAIL PROTECTED]
___
Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -
http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink
___
Nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: RE: Re: [nant-dev] FileSets and multiple directories
Hi Eric, > > That's not too bad, I sort of like it. The only drawback is that the > dependency libraries are specified twice, of course. Not necessarily. What I was thinking about was sort of like this: Or something like that. The idea is that anything you specify in the dependencies FileSet is checked as a dependency using last-change-time, and automatically added as a file to link against. IOW, once you've determined that you need to relink, you'd just merge both linkto and dependencies lists. -- Tomas Restrepo [EMAIL PROTECTED] ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas - http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink ___ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: Re: [nant-dev] FileSets and multiple directories
Kevin, > The problem is not the linker command line - that > already works. The problem is using Nant to check > dependencies, so that the task knows if a rebuild (or > re-link) is necessary. Well, the easy way out would be to distinguish between those libs that usually don't change (such as those provided by MS in VS or PSDK), and those you create in your projects which might change often. So you could have, perhaps, a "dependencies" fileset, besides the usual list of libraries to link to. (Of course, you'd add the libs in "dependencies" to the linker command line so that they are linked in, too). This would be similar to how VS does it, I think... -- Tomas Restrepo [EMAIL PROTECTED] ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas - http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink ___ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] FileSets and multiple directories
Hi Kevin, > Has anybody else had a requirement like this? Is there > some other way to accomplish my goal? Can the fileset > be extended to support this? I think FileSets would be the wrong structure to use for this. What I'd like to have for something like this is an implementation of Ant's FileLists, which seem appropriate for these kind of things. Once I had a FileList, I'd add an attribute to the link task that specified the library include paths. Then, generating the command line for the task would be fairly easy. (after all, the linker already has the code necessary to search for the library once it has the include paths... no use reimplementing it on nant, I think.) -- Tomas Restrepo [EMAIL PROTECTED] ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas - http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink ___ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: RE: [nant-dev] Property Inheritance & nant.onsuccess
Hi Scott, > We really need to separate the project/system props from the user props > so that certain properties don't get inherited. Or at least have a block > list that doesn't get inherited. Agreed. I once thought of a way to do so, but can't remember it now :( > Another way to do this is to establish an event model so that you can > add an eventTask which will be called for certain things. I think this would be a sweet idea, and could be built on top of the existing project and task runner classes (i don't have the source code handy, so I can't check right now). Once you had that, it would be a snap to change onsuccess/onfailure so that all they do is attach event handlers that simply fire off a task, and it would completely eliminate the issue Robert is seeing (In fact, I'd say that onsuccess/onfailure should've never been implemented as properties... too much baggage associated) -- Tomas Restrepo ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas - http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink ___ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] nant task and property inheritance
Hi Scott, > Okay, with the recent changes to the NAntTask we now have something > closer to what Ant does. But there are still some differences. To be honest, I had no clue about how ant does it, so I sorta implemented it as I thought would be most useful... > 1.) By default in Ant the child project has read-only access (which > means they are treated as user properties which cannot be assigned to) > to all the properties of the calling project. NAnt by default does not > give access to the parent properties by default (like using inheritAll='false'/>. I did that on purpose as I did not know what it could break. It might need a few more tests (and I have a unit test in the works), but if you think it's OK, I'd see no problem in enabling it by default. > 2.) If then properties are copied to new > project (but not made read-only). > My take on this is that we should inherit by default and not make them > read-only (as we currently do). This differs from Ant, but I never > understood why inherited properties were made read-only in the first > place. That sounds very reasonable and I'd certainly support it... anyone else has any comments? -- Tomas Restrepo [EMAIL PROTECTED] ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] New NUnitReport look?
Phillip, > Perhaps it would be a good idea to split it in two files. One that contains the > "executive summary", i.e. something you'd give to a program manager. The other > would be something like you have, it contains everything you need to know in a > readable format so that as a dev, it's easy to get to the fun part, fix stuff and shit. That sounds like an interesting idea... who else would be interested in such a report? What information would you think such an executive summary should have? Another idea I'm thinking about is adding a "onlyerrors" attribute to the nunitreport task that would cause it only to include failed tests in the report, such that no detail on sucessful test methods was included. That by itself could significantly reduce the report size while still being very useful, imho... -- Tomas Restrepo [EMAIL PROTECTED] ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
[nant-dev] Rebuilding on Resources changes
Hi guys, Here's another patch, this time for CompilerBase.cs, which forces it to rebuild if files specified in the resources fileset have changed since the last rebuild... this one was annoying me to no end ;) Can anyone commit it, please? -- Tomas Restrepo [EMAIL PROTECTED] CompilerBase.patch Description: Binary data
[nant-dev] XmlResultFormatter minor patch
It seems I still don't have commit access to the CVS repository (or likely I'm doing something wrong ;)). Can anyone commit the attached patch fot XmlResultFormatter.cs? It adds the classname attribute to the testcase element we've talked about (at least with Gerry, Ian and Scott). Thanks! -- Tomas Restrepo [EMAIL PROTECTED] XmlResultFormatter.patch Description: Binary data
[nant-dev] New NUnitReport look?
Hi Guys! Thanks to all of you I've been able to keep on moving on my tasks. One of the things I've done is revamp the look of the generated NUnit report, working out with Scott a way to summarize a testsuite's results by testclass. However, I'm not exactly sure what "look" to give to the report so that it doesn't become too annoying, or too large. To see what I came up with, browse to http://www.winterdom.com/temp/testsummary.html. Please tell me what you think, as I believe it can be greatly improved (although I'm sort of out of ideas at the moment...;) ). Besides these changes, the next drop will feature the following enhancements: - The default XSL files don't have to be deployed, as they are now included as managed resources inside the DLL. Thanks to Ian for the idea an initial implementation. - A few bugs are fixed. Thanks to Scott and Bernard for pointing them out! So, any comments? Better? Worse? -- Tomas Restrepo [EMAIL PROTECTED] ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] New Nant Property
Scott, > It seems like an environment variable is a good way to do this. That is > how ant works, and it seems to work well. > > Maybe we should adopt a NANT_HOME environment variable for others to > find us. This env. var. could also be used for what you want, no? Yeah, I guess, now that I think about it ;) -- Tomas Restrepo [EMAIL PROTECTED] ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] New Nant Property
Hi Brad, > and it will be properly referenced. I added this to NAnt a little while ago > to make building my unit tests easier. I don't think it's unreasonable to > expect that NAnt be on the PATH. :) I know, but in my case, at least, that's hardly so, since I keep around three different NAnt versions at any time (the latest snapshot, the one I'm modifying, and the fully modified version I use for work), so depending on things being on the path is kind of problematic :) I admit this is hardly useful for the general public, but it could ease the lives of those actively hacking on nant ;) -- Tomas Restrepo [EMAIL PROTECTED] ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
[nant-dev] New Nant Property
Hi guys, Here's a quick proposal: I'd like to add a new default property to projects, in the like of nant.version, etc. What I'd like to have is a property (let's call it nant.location for now), the value of which would contain the complete path to the directoy nant is being loaded from. I know it doesn't sound like much, but it's really a two line change in Project.cs and would allow us to create more portable buildfiles that referenced dlls included with NAnt. For example, it would make it easier to build new assemblies containing additional NAnt tasks (such as the upcoming NAntContrib project), since you wouldn't need to know where nant.core.dll is located, so one could just put in the buildfile: -- Tomas Restrepo [EMAIL PROTECTED] ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] ANN: New Nant Tasks
> Cool. I'll submit a request for a new project from SourceForge. If > anyone else is interested, please send me email and I'll get back to as > soon the project exists. Great. Be shure to add me ;) (my sourceforge alias is tomasr, btw). > > > Understood. I think this support should be in NAnt. Ant has this > support. It has an inheritAll attribute and support for Property child > Elements for . The default for inheritAll is true; it is not > required. > > Would this format work for you? It would work out great. In fact, that last thing was the change I was going to work on tonight ;) -- Tomas Restrepo [EMAIL PROTECTED] ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] ANN: New Nant Tasks
Hi Scott, > I vote for a new NAntContrib Project. This project can take code > donations, will allow cvs access for anyone who has tasks they want to > add, and will allow some interesting experimentation without affecting > the core stability, release schedules, or development of NAnt. > That sounds good to me. In many ways that's what my BuildTasks lib does: provide my own playground for NAnt extensions. If such a project where to surface, I'd be happy to contribute my code to it. > What modification have you made to NAnt? (You mentioned fixes before in > another email.) The largest one is one I mentioned here quite a while ago, which allows project's properties to flow through nant invocations when the nant task is used inside a project. I have since done a few changes to it, but it's still essentially the same. However, since some changes where introduced to nant in the specific files I modified, I have to keep them synchronized and reapply my patches when a new version of Nant comes along... -- Tomas Restrepo [EMAIL PROTECTED] ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] ANN: New Nant Tasks
> > Do you have your tasks in cvs somewhere ? Not really. I do have them in SourceControl but in a personal db in another system... > Do you want to add them to the > nant repository or create another 'contrib' sourceforge project ? As I've mentioned to Scott recently, my main concern is being able to maintain my tasks. I don't know if people are actually interested in what I've put together, so I'm not sure if they actually belong in the actual NAnt source tree. I have to add that I've actually added these tasks because I need them for my own projects, and thought other people might find them useful, so I'll keep on working on them regardless of where they are located. I already use at work a modified version of NAnt for my builds, which means I have to keep it synchronized with the actual NAnt builds, so actually keeping my tasks outside of NAnt is simpler for me ;) -- Tomas Restrepo [EMAIL PROTECTED] ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] ANN: New Nant Tasks
Hi Joe! > That report looks sweet. Once it's a little farther along > towards a release version I'll incorporate that into our builds to > generate unit test reports. Well, NUnitReport itself is fairly stable... It's the one I've spent most time on :) I'd certainly like to know what else people want in the report, or if they want it in another format. One thing I wanted was to do a two-way split: TestSuites -> TestClasses -> TestMethods. (Right now it's just TestSuites->TestMethods). Unfortunately, the current format generated by the NUnit formatters is just very hard to process from XSLT... or at least I failed miserably trying to do it, so if anyone has any advanced XSLT tricks they want to share, I'd be happy! ;) -- Tomas Restrepo [EMAIL PROTECTED] ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
[nant-dev] ANN: New Nant Tasks
As I've mentioned before on this list, I've been working on a set of NAnt extension tasks, including the NUnitReport task I've talked about. I've finally put together an initial version of them on my website at http://www.winterdom.com/dev/dotnet/NAnt/BuildTasks.html I guess this could serve as an initial try of the NantContrib we've talked about ;) Anyway, I'd appreciate some feedback on'em ;) -- Tomas Restrepo [EMAIL PROTECTED] ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] Looping
Mark, > Suggestion: > Rather than fill the "next stable" with new tasks. Why not build Nant > as a stable build, then as developers create new tasks (such as Brad's) it > can be added once the wrinkles have been worked out. > > With the ease of plugging in Nant tasks, it would be trivial to build > a separate .dll with these new "unstable" tasks. I would end up with > something like: > > nant.exe > dev-Tasks.dll > > Just an idea! ;) Sounds good to me. It would be sort of a NAnt version of Ant's AntContrib project. As for Brad's suggestion, it sounds good, too. In that same spirit, perhaps we could consider implementing it in a similar fashion to Ant's Condition framework (something possibly worth porting to NAnt, too) -- Tomas Restrepo [EMAIL PROTECTED] ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] NUnit tests names
Hi Scott, > What are the other tasks? I've got three, for now: NUnitReport (my port of JUnitReport), another one wrapping mgmtclassgen.exe and my modified MailEx task, for now I'll probably keep on working on several other tasks, as I need them. > > I guess the question comes down to who will maintain them, and how you > want to make them available. Indeed. I'd certainly want to maintain them, which is why I've thought about building my own library of NAntTasks and making them available on my website... it would certainly be easier for me to maintain it this way. The problem with adding them to the NAnt distribuition is that I'd have no way to maintain them -- Tomas Restrepo [EMAIL PROTECTED] ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] NUnit tests names
Here's the update necessary to fix this issue. What this allows is the
result formatters to access the underlying ITest instance being run by the
test runner. As you'll see, the changes necessary to do this are fairly
basic:
1- Add a Suite property to NUnitTest that access the ITest used
2- Add a single line to NUnitTestRunner to set the NUnitTest.Suite property
once the suite to run has been instantiated.
3- Change a couple of lines in XmlResultFormatter to if the TestSuite
underneath has a name and use that, or use the default "test".
What do you guys think?
I've attached the three modified files.
--
Tomas Restrepo
[EMAIL PROTECTED]
// NAnt - A .NET build tool
// Copyright (C) 2001-2002 Gerry Shaw
//
// This program is free software; you can redistribute it and/or modify
// it under the terms of the GNU General Public License as published by
// the Free Software Foundation; either version 2 of the License, or
// (at your option) any later version.
//
// This program is distributed in the hope that it will be useful,
// but WITHOUT ANY WARRANTY; without even the implied warranty of
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
// GNU General Public License for more details.
//
// You should have received a copy of the GNU General Public License
// along with this program; if not, write to the Free Software
// Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
// Ian MacLean ([EMAIL PROTECTED])
// Gerry Shaw ([EMAIL PROTECTED])
using System;
using System.IO;
using System.Text;
using NUnit.Framework;
using System.Xml;
namespace SourceForge.NAnt.Tasks.NUnit {
/// Prints detailed information in XML format about running
tests.
public class XmlResultFormatter : IResultFormatter {
const string ElementTestSuites = "testsuites";
const string ElementTestSuite = "testsuite";
const string ElementTestCase = "testcase";
const string ElementError = "error";
const string ElementFailure = "failure";
const string AttributePackage = "package";
const string AttributeName = "name";
const string AttributeTime = "time";
const string AttributeErrors = "errors";
const string AttributeFailures = "failures";
const string AttributeTests = "tests";
const string AttributeType = "type";
const string AttributeMessage = "message";
TextWriter _writer;
// Document builder members
XmlDocument _document;
XmlElement _suiteElement;
XmlElement _currentTest;
DateTime _testStartTime;
public XmlResultFormatter() {
_document = new XmlDocument();
}
public TextWriter Writer {
get { return _writer; }
set { _writer = value; }
}
//-
// IResultFormatter interface methods
//-
/// Sets the Writer the formatter is supposed to write its results
to.
public void SetOutput(TextWriter writer) {
Writer = writer;
}
/// Called when the whole test suite has started.
public void StartTestSuite(NUnitTest suite) {
XmlDeclaration decl = _document.CreateXmlDeclaration("1.0", null, null);
_document.AppendChild(decl);
_suiteElement = _document.CreateElement(ElementTestSuite);
//
// if this is a testsuite, use it's name
//
string suiteName = suite.Suite.ToString();
if ( suiteName == null || suiteName == string.Empty )
suiteName = "test";
_suiteElement.SetAttribute(AttributeName, suiteName );
}
/// Called when the whole test suite has ended.
public void EndTestSuite(TestResultExtra result) {
_suiteElement.SetAttribute(AttributeTests , result.RunCount.ToString());
double time = result.RunTime;
time /= 1000D;
_suiteElement.SetAttribute(AttributeTime, time.ToString("#0.000"));
_document.AppendChild(_suiteElement);
_suiteElement.SetAttribute(AttributeErrors ,
result.ErrorCount.ToString());
_suiteElement.SetAttribute(AttributeFailures ,
result.FailureCount.ToString());
// Send all output to here
_document.Save(Writer);
Re: [nant-dev] An improved MailTask
Hi Scott, > These changes seem straight forward enough to me. I've checked them in. Great. I;ve since done some changes to it, but those are fairly breaking so I had planned to keep those in a separate task. Basically what I changed was: - Eliminated the files attribute. I'm not sure how many people actually build emails out of several files and I think there are better ways to do so without all the trouble taken inside MailTask to deal with them. I replaced it with a "file" attribute whioch takes a single file name. - Eliminated the attachments attribute and replaced it by a fileset, which seems more useful and more inline with the rest of the NAnt tasks. If anyone is interested in it, feel free to mail me about it... -- Tomas Restrepo [EMAIL PROTECTED] ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] NUnit tests names
Hi Scott, > If you are going to make these changes yourself anyway, I would like to > see them. If your changes improve the functionality of the NUnit tasks > without adding any more complexity to the simple case, I'm all for it. I think it can be done without too much trouble. I'll do it later today and post the updated version to the list so you can take a look at it. > http://www-106.ibm.com/developerworks/java/library/j-junitmail/index.htm > l > > Cool. I'd be interesting in seeing this done. I've got it mostly ready... I'm also working on a few other tasks, but I'm not sure whether to actually add them to the standard NAnt distribution or keep em separate... I'd appreciate any comments -- Tomas Restrepo [EMAIL PROTECTED] ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
[nant-dev] Bug in SysInfoTask
the sysinfo task has a small bug, at least if you follow it's documentation. Documentation for SysInfoTask says it will construct two different items: sys.os.platform and sys.os.version. However, the code never actually adds the sys.os.platform property, and only fills in sys.os.version,. alas with the incorrect value. To fix this, you need to change line 66 of SysInfo.cs for these two lines: Project.Properties.Add(Prefix + "os.platform", Environment.OSVersion.Platform.ToString()); Project.Properties.Add(Prefix + "os.version", Environment.OSVersion.Version.ToString()); Also, I think it's valuable to add a "sys.os" property that contains the result of Environment.OSVersion.ToString(), which is what sys.os.version was getting initialized to, and which actually doesn't contain the platform ID, but a more readable code (i.e. "Microsoft Windows NT" instead "Win32NT"). To do so, add this line too: Project.Properties.Add(Prefix + "os", Environment.OSVersion.ToString()); At least if anyone's interested.. -- Tomas Restrepo [EMAIL PROTECTED] ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
[nant-dev] NUnit tests names
Hi again, So I keep going throgh the NUnitTask in NAnt, and I have run into another gotcha: TestSuite names. For example, the XmlResultFormatter puts a name attribute on the tag, except, it always prints the same: "test", since it incorrectly (imho) puts the value of NUnitTest.Name, which of course will be "test", since it is a constant value. Utterly useless, essentially. So I can see one of two ways out: - Add a name attribute to "test" task, and use that, or... - Modify the system so that the formatters, at that point, get access to the ITest or ITestSuite instance used to perform the actual test. After all, TestSuite in NUnit already defines a Name property which could be used quite nicely. The latter would require, so far as I can see, some somewhat heavy changes to several of the NUnit task classes, so it would be less desirable if a "quick fix" is wanted. So, what do you guys think? Do any of you find it worthwhile? If not, I'll just go ahead and create my own NUnit task replacements and use those instead. P.S. FWIW, if anyone's wondering what I'm doing fooling around with the NUnit task classes, I'm trying, for the fun of it, to build a task for nant similar to JUnitReport [1] for my own use... [1] http://www-106.ibm.com/developerworks/java/library/j-junitmail/index.html -- Tomas Restrepo [EMAIL PROTECTED] ___ Hundreds of nodes, one monster rendering program. Now that's a super model! Visit http://clustering.foundries.sf.net/ ___ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
[nant-dev] Error and Failure counts in NUnitTask's XmlResultFormatter
Unlike the PlainTextResultFormatter, the XmlResultFormatter in NUnitTask doesn't list the total number of errors and failures in a test suite. It seems whoever wrote it did think about it, as the definition for the error and failure attributes to testsuite are there, but are never created. Fixing it, though, is easy: Just add the following lines: _suiteElement.SetAttribute(AttributeErrors , result.ErrorCount.ToString()); _suiteElement.SetAttribute(AttributeFailures , result.FailureCount.ToString()); At line 85 of XmlResultFormatter.cs (the second line in EndTestSuite). Could someone commit this? That'd be great -- Tomas Restrepo [EMAIL PROTECTED] ___ Hundreds of nodes, one monster rendering program. Now that's a super model! Visit http://clustering.foundries.sf.net/ ___ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] Bug in NUnit task
Hi Scott, > I've made these changes, and checked them in, but I have a sneaking > suspicion that this is not the correct place to close the writer. > > The writer is created in the this block from IResultFormatter > NUnitTask.CreateFormatter(...) > > TextWriter tw = new StreamWriter( outfile.Create()); > retFormatter.SetOutput(tw); > return retFormatter; > > Then the formatter is used. It seems like IResultFormatter should be > disposable, and that is when the writer should be closed. Or the creator > should take care of it. > > It seems like your solution, although it works, will close the writer > that it doesn't necessary own. And could be a pre-mature closure. I thought about this, too, but wasn't so sure about this. For one thing, as you yourself pointed out, the writer is created at the same time as the formatter, and handed to it. That, at least imho, gives the formatter pretty clear ownership of the writer. However, you have a valid point. However, I'd consider instead some refactoring here: To me, the clearest solution is to give the formatter clear ownership of the writer, and in fact, let it create the writer itself. It makes no sense, afaics, what benefit comes from creating it independently. -- Tomas Restrepo [EMAIL PROTECTED] ___ Hundreds of nodes, one monster rendering program. Now that's a super model! Visit http://clustering.foundries.sf.net/ ___ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
[nant-dev] An improved MailTask
Hi guys,
I did a few modifications to the standard MailTask in NAnt. At first, I
thought about building my own alternative version, but it was not really
worth it for my very simple needs: Send HTML email based on an HTML file on
disk.
With that in mind, I did two modifications to the MailTask:
1) Added a format attribute which can take the value "Html" or "Text", which
map directly to the BodyFormat member of the MailMessage class.
2) Modified the code that interprets the files property in such a way that
when you only reference a single file to add to the message body, no
filename gets prepended on the body. This makes it very nice to use for
dynamically generated message content. (as an aside, I don't think adding
the file's name to the message body is that useful, particularly since it
will add a relative filename probably meaningless to the receptor). I'm not
sure however if this suites other people, but it would be extremely easy to
add a simple attribute to control this (or add an alternative property).
Anyone has any problem with this?
Anyway, I've attached the modified file in case anyone is interested in
it...
--
Tomas Restrepo
[EMAIL PROTECTED]
// NAnt - A .NET build tool
// Copyright (C) 2001 Gerry Shaw
//
// This program is free software; you can redistribute it and/or modify
// it under the terms of the GNU General Public License as published by
// the Free Software Foundation; either version 2 of the License, or
// (at your option) any later version.
//
// This program is distributed in the hope that it will be useful,
// but WITHOUT ANY WARRANTY; without even the implied warranty of
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
// GNU General Public License for more details.
//
// You should have received a copy of the GNU General Public License
// along with this program; if not, write to the Free Software
// Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
// Jay Turpin ([EMAIL PROTECTED])
// Gerry Shaw ([EMAIL PROTECTED])
using System;
using System.Text;
using System.Web.Mail;
using System.IO;
using SourceForge.NAnt.Attributes;
using SourceForge.NAnt;
namespace SourceForge.NAnt.Tasks {
/// A task to send SMTP email.
///
/// Text and text files to include in the message body may be specified as well as
binary attachments.
///
///
/// Sends an email from [EMAIL PROTECTED] to three recipients with a
subject about the attachments. The body of the message will be the combined contents
of body1.txt through body4.txt. The body1.txt through body3.txt files will also be
included as attachments. The message will be sent using the smtpserver.anywhere.com
SMTP server.
///
///
[TaskName("mail")]
public class MailTask : Task
{
string _from = "";
string _toList = "";
string _ccList = "";
string _bccList = "";
string _mailHost = "localhost";
string _subject = "";
string _message = "";
string _files = "";
string _attachments = "";
MailFormat _format = MailFormat.Text;
/// Email address of sender
[TaskAttribute("from", Required=true)]
public string From { get { return _from; } set { _from = value; } }
/// Comma- or semicolon-separated list of recipient email
addresses
[TaskAttribute("tolist", Required=true)]
public string ToList {
// convert to semicolon delimited
get { return _toList.Replace("," , ";"); }
set { _toList = value.Replace("," , ";"); }
}
/// Comma- or semicolon-separated list of CC: recipient email
addresses
[TaskAttribute("cclist")]
public string CcList {
// convert to semicolon delimited
get { return _ccList.Replace("," , ";"); }
set { _ccList = value.Replace("," , ";"); }
}
/// Comma- or semicolon-separated list of BCC: recipient email
addresses
[TaskAttribute("bcclist")]
public string BccList {
// convert to semicolon delimited
get { return _bccList.Replace("," , ";"); }
set { _bccList = value.Replace("," , ";"); }
}
/// Host name of mail server. Defaults to "localhost"
[TaskAttribute("mailhost")]
public string Mailhost { get { return _mailHost; } set { _mailHost = value; } }
/// Text to send in body of email message.
[TaskAttribute("message")]
public string Message { get { return _message; } set { _m
[nant-dev] Bug in NUnit task
Hi guys, I was doing some work trying to set up the simples of things: add a mail task to one of my buildfiles that would add the NUnit result files of my build as attachments, and figure my surprise when it didn't work! After fiddling around with it for a while, I found the problem: The TextWriter used in the NUnit formatters are never closed, so the output files remain open untilk garbage collection in such a way that you can't even access them for read-only!~ Fortunately, this is very easy to fix. I did so by adding a Writer.Close() line to XmlResultFormatter.cs and PlainTextResultFormatter.cs right at the end of the EndTestSuite() Method in each class. Could anyone with commit access make the change and commit it? It would be great to have that fixed in the standard distribution... -- Tomas Restrepo [EMAIL PROTECTED] ___ Hundreds of nodes, one monster rendering program. Now that's a super model! Visit http://clustering.foundries.sf.net/ ___ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] Version task
Eric, > Jeff Richter in "Applied Microsoft .Net Framework Programming" argues > against using the asterisk. I'm not sure I buy his argument, but I > respect his opinion. In addition, I like having a deterministic nightly > build number, or more often if I build releases multiple times per day. > Accordingly, I like having more control over the entire version number. Can I ask one thing? Why bother modifying AssemblyInfo.cs anyway? What I'd do is just nuke that file from my builds. Instead, just have some other file (say, a .txt) containing the latest build number used, then, from the buildfile, generate a .cs with just the version attribute into a known location from the txt file, and then include _that_ file as part of my csc tasks. Seems like much easier to me, and less problematic, anyway... -- Tomas Restrepo [EMAIL PROTECTED] ___ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
[nant-dev] Property Inherintance in NantTask
Hi all,
One think I'd like to see implemented in Nant would be to have the Nant task
"inherit" properties defined by the invocation buildfile, in order to be
able to set properties in a master buildfile and have them be used when
building submodules through the NantTask.
Being a newbie in the Nant source, I "hacked" support for it by simply
modifying the code in NantTask to copy all properties from the current
task's Project into the new project's Property list. This seems to work just
fine in my tests, but I'm not quite sure what this might break down the
road. Basically, the problem is that since at that time the new project
hasn't initialized it's property list, you need to modify
PropertyDictionary.Add() so that it doesn't throw an exception a property
with the same name is added (which _will_ happen, since the new project now
has to "replace" some of the inherited properties, such as
nant.project.name).
So, imho, some refactoring would be needed in order to implement it in a
more appropriate manner. Perhaps separating the properties in those added by
nant itself (such as the nant.* and sys.* ones) and those added by the user
using -D: or the task? I'm not sure.
Anyway, if anyone still cares for my hack, all that's needed it's three
things:
1- In PropertyDictionary.cs, modify Add() like this:
public void Add(string name, string value) {
if (!_readOnlyProperties.Contains(name)) {
if ( Dictionary.Contains(name) )
Dictionary[name] = value;
else
Dictionary.Add(name, value);
}
}
2- Add the following method to PropertyDictionary:
public void CopyProperties(PropertyDictionary source) {
Dictionary.Clear();
foreach ( DictionaryEntry entry in source.Dictionary ) {
if ( !Dictionary.Contains(entry.Key) ) {
Dictionary[entry.Key] = entry.Value;
}
}
}
3- In NantTask.cs, linie 81, add the following call:
project.Properties.CopyProperties(this.Project.Properties);
Just before
// handle multiple targets
if (DefaultTarget != null) {
P.S. Since I'm pretty much a newbie when it comes to CVS, I couldn't find my
way around making a diff file...
--
Tomas Restrepo
[EMAIL PROTECTED]
___
Nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
