Re: [nant-dev] RE: RE: [Fwd: Ready to tackle next release]
I totally agree. Less code duplication the better. Dmitry has used this approach in the work he has done for VisualC++ projects ie it defers to the Cl, Midl, rc and link tasks where necessary. Ian Erv Walter wrote: In my opinion, it would be a "good thing" if at some point the task did very little work itself. Instead it should dynamically determine which of the existing tasks should be called and then call them (instead of calling csc.exe directly, for example). This would allow the solution task to leverage all of the nice features of the existing tasks including handling multiple frameworks, etc. -Original Message- From: Matthew Mastracci [mailto:[EMAIL PROTECTED] Sent: Saturday, October 04, 2003 12:22 AM To: Ian MacLean Cc: James C. Papp; [EMAIL PROTECTED] Subject: Re: [nant-dev] RE: RE: [Fwd: Ready to tackle next release] Oh - I hadn't realized that the CompilerBase was doing the same sort of hackery. In that case, I guess we should probably be sharing the delicate code between the two places. It might be better to move all of the code into the CompilerBase class and use it from there in the Solution task. Thanks for the clarification, Matt. Ian MacLean wrote: Matthew Mastracci wrote: Please let me know if I'm totally out to lunch on this one- I'm guessing that this resx issue you are describing is a problem with the task. I think he's talking about Compilerbase.cs. The regular compiler tasks do the same thing as solution task wrt determining correct namespace prefix. Its the same problem just in a different place. Ian I haven't really been in the code there lately, but checking in CVS, it looks as if the resource-compiling functionality is operating correctly (with the exception of the not-so-smart regex's you mentioned in your note). I can't see how more than one regex could be run on a single file. Are you running with an older version, or does CVS exhibit the problems you are seeing? Also with regards to "The biggest problem is that NAnt assumes the filename (of the source file) is the name of the class that the RESX should be associated too"- we should (according to the latest code) be parsing the files to determine the correct namespace/filename of the final .resource file. Resources should never be named to match their dependent files. Are you perhaps referring to .resx files that are not associated with any .cs or .vb files? I could see that there could be a problem there, but it seems to match VS.NET's behaviour in all of my tests. Can you please elaborate on #2 and #3 more? Again, if you're not talking about what I think you are, let me know, and I apologize in advance. :) Thanks, Matt. On Fri, 2003-10-03 at 21:21, Ian MacLean wrote: James, We'd love to see your patches. The resx issues was a known one - if your solution is cleaner and more accurate then obviously thats the way to go. Post patches here and they will be reviewed. Ian RE: [Fwd: Ready to tackle next release] If you are getting ready for a new release, I have a bunch of patches I would love to see added to NAnt. I would be willing to work with everyone as much as needed, to see that the changes make it into the release; or some variation of them - that is, if they are accepted. Here is a run down of our current changes to NAnt: I have mentioned this one previously; and it involves adding an "options" property to CompilerBase.cs. The original post had no subject and came out garbled (sorry about that), though I have filed it under RFE "[811931] - Adding an "options" property to CompilerBase.cs", where you can read about the change in more detail. Another change we made was to allow passing of "parameters" as properties to other NAnt scripts via the "nant" task. This works really well and avoids having to using the "inheritall" attribute (which can be overkill - particularly if you have scripts that call themselves externally...). You can think of this feature as adding support for the "-D:" options of nant.exe The syntax looks like this: The "defines" are created as properties and accessible only from the invoked NAnt script as if they were passed with "-D:". Their values are evaluated at the time just before the new script is invoked. Note: You can still use the "inheritall" attribute as well, though anything defined will override anything inherited if there is a name collision. The patch for this change is straightforward and simple. The only part left to do is handling all the NAnt location stuff with properties, which I am not too sure about (currently, I set this to unknown), though I'm sure someone on the list can enlighten me.
RE: [nant-dev] RE: RE: [Fwd: Ready to tackle next release]
In my opinion, it would be a "good thing" if at some point the task did very little work itself. Instead it should dynamically determine which of the existing tasks should be called and then call them (instead of calling csc.exe directly, for example). This would allow the solution task to leverage all of the nice features of the existing tasks including handling multiple frameworks, etc. -Original Message- From: Matthew Mastracci [mailto:[EMAIL PROTECTED] Sent: Saturday, October 04, 2003 12:22 AM To: Ian MacLean Cc: James C. Papp; [EMAIL PROTECTED] Subject: Re: [nant-dev] RE: RE: [Fwd: Ready to tackle next release] Oh - I hadn't realized that the CompilerBase was doing the same sort of hackery. In that case, I guess we should probably be sharing the delicate code between the two places. It might be better to move all of the code into the CompilerBase class and use it from there in the Solution task. Thanks for the clarification, Matt. Ian MacLean wrote: > Matthew Mastracci wrote: > >> Please let me know if I'm totally out to lunch on this one- I'm >> guessing that this resx issue you are describing is a problem with >> the task. >> >> > I think he's talking about Compilerbase.cs. The regular compiler tasks > do the same thing as solution task wrt determining correct namespace > prefix. Its the same problem just in a different place. > Ian > >> I haven't really been in the code there lately, but checking in CVS, >> it looks as if the resource-compiling functionality is operating >> correctly (with the exception of the not-so-smart regex's you >> mentioned in your note). I can't see how more than one regex could >> be run on a single file. Are you running with an older version, or >> does CVS exhibit the problems you are seeing? >> >> Also with regards to "The biggest problem is that NAnt assumes the >> filename (of the source file) is the name of the class that the RESX >> should be associated too"- we should (according to the latest code) >> be parsing the files to determine the correct namespace/filename of >> the final .resource file. Resources should never be named to match >> their dependent files. Are you perhaps referring to .resx files that >> are not associated with any .cs or .vb files? I could see that there >> could be a problem there, but it seems to match VS.NET's behaviour in >> all of my tests. >> >> Can you please elaborate on #2 and #3 more? Again, if you're not >> talking about what I think you are, let me know, and I apologize in >> advance. :) >> >> Thanks, >> Matt. >> >> On Fri, 2003-10-03 at 21:21, Ian MacLean wrote: >> >> >>> James, >>> We'd love to see your patches. The resx issues was a known one - if >>> your solution is cleaner and more accurate then obviously thats the >>> way to go. >>> Post patches here and they will be reviewed. >>> Ian >>> >>> >>> >>>> RE: [Fwd: Ready to tackle next release] If you are getting ready >>>> for a new release, I have a bunch of patches I would love to see >>>> added to NAnt. I would be willing to work with everyone as much as >>>> needed, to see that the changes make it into the release; or some >>>> variation of them - that is, if they are accepted. >>>> >>>> Here is a run down of our current changes to NAnt: >>>> I have mentioned this one previously; and it involves adding an >>>> "options" property to CompilerBase.cs. The original post had no >>>> subject and came out garbled (sorry about that), though I have >>>> filed it under RFE "[811931] - Adding an "options" property to >>>> CompilerBase.cs", where you can read about the change in more detail. >>>> >>>> >>>> >>>> >>>> Another change we made was to allow passing of "parameters" as >>>> properties to other NAnt scripts via the "nant" task. This works >>>> really well and avoids having to using the "inheritall" attribute >>>> (which can be overkill - particularly if you have scripts that call >>>> themselves externally...). You can think of this feature as adding >>>> support for the "-D:" options of nant.exe >>>> >>>> The syntax looks like this: >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> The &q
RE: [nant-dev] RE: RE: [Fwd: Ready to tackle next release]
> This works extremely well, mainly because Visual Studio forces > the Form/Control classes to always be the first class in the > file (now you know why they do this, it seems that VS needs > to do all this work as well...). > You can read more about the issue here (from Eric Gunnerson's blog)... http://blogs.gotdotnet.com/EricGu/permalink.aspx/f431b64b-5a90-4588-bde3 -3b79fa6b4af5 He talks about the issue in relation to MSBuild (which apparently was once xmake). I was wondering how NAnt and the solution task coped with it. Now I know. Thanks, Jamie. --- 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] RE: RE: [Fwd: Ready to tackle next release]
Hi Ian, True, right now its not a real issue provided NUnit 2.1 will happily compile onto version 1.1 of the framework. - Mitch Denny - [EMAIL PROTECTED] - http://www.monash.net - +61 (414) 610141 - > -Original Message- > From: Ian MacLean [mailto:[EMAIL PROTECTED] > Sent: Sunday, October 05, 2003 1:41 AM > To: Mitch Denny > Cc: James C. Papp; [EMAIL PROTECTED] > Subject: Re: [nant-dev] RE: RE: [Fwd: Ready to tackle next release] > > Totally. I'm really looking forward to using generics when > whitbey ships for example. However right now the codebase > isn't usihng any 1.1 specific features. So I see no reason to > exclude 1.0 users until we need specific features in a > higher version. > I can recall reading the same types of dicussions on the > mailing lists for Java projects ( Ant and JEdit to be > specific ). It was even worse with java as there was a large > amoutn of change between early versions. > Wheras 1.1 of the framework could almost be considerd a bug > fix release in terms of breaking changes. > > I don't think we'll need to fork the codebase - I just think > that when we do force a newer framework version people on an > older platform will just use an older NAnt until they upgrade. > > Ian > > Mitch Denny wrote: > > >Which version of the framework to run on is going to be a perennial > >problem. There are going to be features in the upcoming > version of the > >.NET runtime which, if you guys choose to take advantage of > them might > >force a fork in the code bases - I'm not sure what the Mono > guys have > >plannned as far as supporting generics goes. > > > >I know of a number of organisations that are planning on > being on 1.0 > >for atleast the next 12 months - in twelve months its likely > that NAnt > >will need to be starting to build in support for upcoming > versions of > >the framework, it might just been too hard to manage in one > code base. > >Unfortunately I know. > > > > > >- Mitch Denny > >- [EMAIL PROTECTED] > >- http://www.monash.net > >- +61 (414) 610141 > >- > > > > > > > >>-Original Message- > >>From: Ian MacLean [mailto:[EMAIL PROTECTED] > >>Sent: Saturday, October 04, 2003 3:19 PM > >>To: James C. Papp > >>Cc: [EMAIL PROTECTED] > >>Subject: Re: [nant-dev] RE: RE: [Fwd: Ready to tackle next release] > >> > >>I've been testing Nunit 2.1 and it seems ok - except for needing to > >>re-compile all 2.0 version tests. We're waitning on the > NUnit team for > >>a response to a number of queries about shipping 2.1. With luck we > >>should have it in 0.9. > >> > >>The problem with building against 1.1 is that a 1.1 build will not > >>work on 1.0 whereas a 1.0 one will work fine on both. If > everyone has > >>moved to 1.1 then thats not a problem but I'm not sure > thats the case. > >>The other option is to ship two builds - one for each platform. > >> > >>Ian > >> > >> > >> > >>>>It would be great to see NUnit 2.1 plugged in. I'd also > like to see > >>>>1.1 as the default. Ian - do you think it would be possible > >>>> > >>>> > >>to get the > >> > >> > >>>>ReplaceTask into the core if I can make it more robust? > >>>> > >>>> > >>>>- Mitch Denny > >>>>- [EMAIL PROTECTED] > >>>>- http://www.monash.net > >>>>- +61 (414) 610141 > >>>>- > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>>-Original Message- > >>>>>From: Ian MacLean [mailto:[EMAIL PROTECTED] > >>>>>Sent: Friday, October 03, 2003 2:31 PM > >>>>>To: [EMAIL PROTECTED] > >>>>>Subject: [nant-dev] [Fwd: Ready to tackle next release] > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>--- > >>>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 > >> > >> > >> > > > > --- 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] RE: RE: [Fwd: Ready to tackle next release]
Totally. I'm really looking forward to using generics when whitbey ships for example. However right now the codebase isn't usihng any 1.1 specific features. So I see no reason to exclude 1.0 users until we need specific features in a higher version. I can recall reading the same types of dicussions on the mailing lists for Java projects ( Ant and JEdit to be specific ). It was even worse with java as there was a large amoutn of change between early versions. Wheras 1.1 of the framework could almost be considerd a bug fix release in terms of breaking changes. I don't think we'll need to fork the codebase - I just think that when we do force a newer framework version people on an older platform will just use an older NAnt until they upgrade. Ian Mitch Denny wrote: Which version of the framework to run on is going to be a perennial problem. There are going to be features in the upcoming version of the .NET runtime which, if you guys choose to take advantage of them might force a fork in the code bases - I'm not sure what the Mono guys have plannned as far as supporting generics goes. I know of a number of organisations that are planning on being on 1.0 for atleast the next 12 months - in twelve months its likely that NAnt will need to be starting to build in support for upcoming versions of the framework, it might just been too hard to manage in one code base. Unfortunately I know. - Mitch Denny - [EMAIL PROTECTED] - http://www.monash.net - +61 (414) 610141 - -Original Message- From: Ian MacLean [mailto:[EMAIL PROTECTED] Sent: Saturday, October 04, 2003 3:19 PM To: James C. Papp Cc: [EMAIL PROTECTED] Subject: Re: [nant-dev] RE: RE: [Fwd: Ready to tackle next release] I've been testing Nunit 2.1 and it seems ok - except for needing to re-compile all 2.0 version tests. We're waitning on the NUnit team for a response to a number of queries about shipping 2.1. With luck we should have it in 0.9. The problem with building against 1.1 is that a 1.1 build will not work on 1.0 whereas a 1.0 one will work fine on both. If everyone has moved to 1.1 then thats not a problem but I'm not sure thats the case. The other option is to ship two builds - one for each platform. Ian It would be great to see NUnit 2.1 plugged in. I'd also like to see 1.1 as the default. Ian - do you think it would be possible to get the ReplaceTask into the core if I can make it more robust? - Mitch Denny - [EMAIL PROTECTED] - http://www.monash.net - +61 (414) 610141 - -Original Message- From: Ian MacLean [mailto:[EMAIL PROTECTED] Sent: Friday, October 03, 2003 2:31 PM To: [EMAIL PROTECTED] Subject: [nant-dev] [Fwd: Ready to tackle next release] --- 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 --- 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] RE: RE: [Fwd: Ready to tackle next release]
Which version of the framework to run on is going to be a perennial problem. There are going to be features in the upcoming version of the .NET runtime which, if you guys choose to take advantage of them might force a fork in the code bases - I'm not sure what the Mono guys have plannned as far as supporting generics goes. I know of a number of organisations that are planning on being on 1.0 for atleast the next 12 months - in twelve months its likely that NAnt will need to be starting to build in support for upcoming versions of the framework, it might just been too hard to manage in one code base. Unfortunately I know. - Mitch Denny - [EMAIL PROTECTED] - http://www.monash.net - +61 (414) 610141 - > -Original Message- > From: Ian MacLean [mailto:[EMAIL PROTECTED] > Sent: Saturday, October 04, 2003 3:19 PM > To: James C. Papp > Cc: [EMAIL PROTECTED] > Subject: Re: [nant-dev] RE: RE: [Fwd: Ready to tackle next release] > > I've been testing Nunit 2.1 and it seems ok - except for > needing to re-compile all 2.0 version tests. We're waitning > on the NUnit team for a response to a number of queries about > shipping 2.1. With luck we should have it in 0.9. > > The problem with building against 1.1 is that a 1.1 build > will not work on 1.0 whereas a 1.0 one will work fine on > both. If everyone has moved to 1.1 then thats not a problem > but I'm not sure thats the case. > The other option is to ship two builds - one for each platform. > > Ian > > >>It would be great to see NUnit 2.1 plugged in. I'd also like to see > >>1.1 as the default. Ian - do you think it would be possible > to get the > >>ReplaceTask into the core if I can make it more robust? > >> > >> > >>- Mitch Denny > >>- [EMAIL PROTECTED] > >>- http://www.monash.net > >>- +61 (414) 610141 > >>- > >> > >> > >> > >>>-Original Message- > >>>From: Ian MacLean [mailto:[EMAIL PROTECTED] > >>>Sent: Friday, October 03, 2003 2:31 PM > >>>To: [EMAIL PROTECTED] > >>>Subject: [nant-dev] [Fwd: Ready to tackle next release] > >>> > >>> > >>> > >>> > >>> > > > > > >--- > >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 > --- 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] RE: RE: [Fwd: Ready to tackle next release]
Oh - I hadn't realized that the CompilerBase was doing the same sort of hackery. In that case, I guess we should probably be sharing the delicate code between the two places. It might be better to move all of the code into the CompilerBase class and use it from there in the Solution task. Thanks for the clarification, Matt. Ian MacLean wrote: Matthew Mastracci wrote: Please let me know if I'm totally out to lunch on this one- I'm guessing that this resx issue you are describing is a problem with the task. I think he's talking about Compilerbase.cs. The regular compiler tasks do the same thing as solution task wrt determining correct namespace prefix. Its the same problem just in a different place. Ian I haven't really been in the code there lately, but checking in CVS, it looks as if the resource-compiling functionality is operating correctly (with the exception of the not-so-smart regex's you mentioned in your note). I can't see how more than one regex could be run on a single file. Are you running with an older version, or does CVS exhibit the problems you are seeing? Also with regards to "The biggest problem is that NAnt assumes the filename (of the source file) is the name of the class that the RESX should be associated too"- we should (according to the latest code) be parsing the files to determine the correct namespace/filename of the final .resource file. Resources should never be named to match their dependent files. Are you perhaps referring to .resx files that are not associated with any .cs or .vb files? I could see that there could be a problem there, but it seems to match VS.NET's behaviour in all of my tests. Can you please elaborate on #2 and #3 more? Again, if you're not talking about what I think you are, let me know, and I apologize in advance. :) Thanks, Matt. On Fri, 2003-10-03 at 21:21, Ian MacLean wrote: James, We'd love to see your patches. The resx issues was a known one - if your solution is cleaner and more accurate then obviously thats the way to go. Post patches here and they will be reviewed. Ian RE: [Fwd: Ready to tackle next release] If you are getting ready for a new release, I have a bunch of patches I would love to see added to NAnt. I would be willing to work with everyone as much as needed, to see that the changes make it into the release; or some variation of them - that is, if they are accepted. Here is a run down of our current changes to NAnt: I have mentioned this one previously; and it involves adding an "options" property to CompilerBase.cs. The original post had no subject and came out garbled (sorry about that), though I have filed it under RFE "[811931] - Adding an "options" property to CompilerBase.cs", where you can read about the change in more detail. Another change we made was to allow passing of "parameters" as properties to other NAnt scripts via the "nant" task. This works really well and avoids having to using the "inheritall" attribute (which can be overkill - particularly if you have scripts that call themselves externally...). You can think of this feature as adding support for the "-D:" options of nant.exe The syntax looks like this: The "defines" are created as properties and accessible only from the invoked NAnt script as if they were passed with "-D:". Their values are evaluated at the time just before the new script is invoked. Note: You can still use the "inheritall" attribute as well, though anything defined will override anything inherited if there is a name collision. The patch for this change is straightforward and simple. The only part left to do is handling all the NAnt location stuff with properties, which I am not too sure about (currently, I set this to unknown), though I'm sure someone on the list can enlighten me. Our next change is the most extensive but it fixes a long out-standing issue with NAnt. Basically, we did a rewrite on how NAnt handles RESX files. Currently NAnt has the following problems: 1.)The regular expressions for determining the namespace are poor and are easily confused by comments (that have the word namespace in them, for example "// is located in the foo namespace"). 2.)The regular expressions used by different languages are executed on all the source files. For example, when compiling a "*.cs" file the regular expressions for capitalized namespace lookup (I guess for VB) is executed even when it should not; this is bad, as it picks up false positives and increase the chance of error. 3.)The biggest problem is that NAnt assumes the filename (of the source file) is the name of the class that the RESX should be associated too. This issue killed our use of NAnt (until we fixed it), as our filenames do not match the "Form" class within them; Visual Studio does not have a problem with this. It would be great to see NUnit 2.1 plugged in. I'd also like to see 1.1 as the default. Ian - do yo
Re: [nant-dev] RE: RE: [Fwd: Ready to tackle next release]
I've been testing Nunit 2.1 and it seems ok - except for needing to re-compile all 2.0 version tests. We're waitning on the NUnit team for a response to a number of queries about shipping 2.1. With luck we should have it in 0.9. The problem with building against 1.1 is that a 1.1 build will not work on 1.0 whereas a 1.0 one will work fine on both. If everyone has moved to 1.1 then thats not a problem but I'm not sure thats the case. The other option is to ship two builds - one for each platform. Ian It would be great to see NUnit 2.1 plugged in. I'd also like to see 1.1 as the default. Ian - do you think it would be possible to get the ReplaceTask into the core if I can make it more robust? - Mitch Denny - [EMAIL PROTECTED] - http://www.monash.net - +61 (414) 610141 - -Original Message- From: Ian MacLean [mailto:[EMAIL PROTECTED] Sent: Friday, October 03, 2003 2:31 PM To: [EMAIL PROTECTED] Subject: [nant-dev] [Fwd: Ready to tackle next release] --- 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
Re: [nant-dev] RE: RE: [Fwd: Ready to tackle next release]
Matthew Mastracci wrote: Please let me know if I'm totally out to lunch on this one- I'm guessing that this resx issue you are describing is a problem with the task. I think he's talking about Compilerbase.cs. The regular compiler tasks do the same thing as solution task wrt determining correct namespace prefix. Its the same problem just in a different place. Ian I haven't really been in the code there lately, but checking in CVS, it looks as if the resource-compiling functionality is operating correctly (with the exception of the not-so-smart regex's you mentioned in your note). I can't see how more than one regex could be run on a single file. Are you running with an older version, or does CVS exhibit the problems you are seeing? Also with regards to "The biggest problem is that NAnt assumes the filename (of the source file) is the name of the class that the RESX should be associated too"- we should (according to the latest code) be parsing the files to determine the correct namespace/filename of the final .resource file. Resources should never be named to match their dependent files. Are you perhaps referring to .resx files that are not associated with any .cs or .vb files? I could see that there could be a problem there, but it seems to match VS.NET's behaviour in all of my tests. Can you please elaborate on #2 and #3 more? Again, if you're not talking about what I think you are, let me know, and I apologize in advance. :) Thanks, Matt. On Fri, 2003-10-03 at 21:21, Ian MacLean wrote: James, We'd love to see your patches. The resx issues was a known one - if your solution is cleaner and more accurate then obviously thats the way to go. Post patches here and they will be reviewed. Ian RE: [Fwd: Ready to tackle next release] If you are getting ready for a new release, I have a bunch of patches I would love to see added to NAnt. I would be willing to work with everyone as much as needed, to see that the changes make it into the release; or some variation of them - that is, if they are accepted. Here is a run down of our current changes to NAnt: I have mentioned this one previously; and it involves adding an "options" property to CompilerBase.cs. The original post had no subject and came out garbled (sorry about that), though I have filed it under RFE "[811931] - Adding an "options" property to CompilerBase.cs", where you can read about the change in more detail. Another change we made was to allow passing of "parameters" as properties to other NAnt scripts via the "nant" task. This works really well and avoids having to using the "inheritall" attribute (which can be overkill - particularly if you have scripts that call themselves externally...). You can think of this feature as adding support for the "-D:" options of nant.exe The syntax looks like this: The "defines" are created as properties and accessible only from the invoked NAnt script as if they were passed with "-D:". Their values are evaluated at the time just before the new script is invoked. Note: You can still use the "inheritall" attribute as well, though anything defined will override anything inherited if there is a name collision. The patch for this change is straightforward and simple. The only part left to do is handling all the NAnt location stuff with properties, which I am not too sure about (currently, I set this to unknown), though I'm sure someone on the list can enlighten me. Our next change is the most extensive but it fixes a long out-standing issue with NAnt. Basically, we did a rewrite on how NAnt handles RESX files. Currently NAnt has the following problems: 1.) The regular expressions for determining the namespace are poor and are easily confused by comments (that have the word namespace in them, for example "// is located in the foo namespace"). 2.) The regular expressions used by different languages are executed on all the source files. For example, when compiling a "*.cs" file the regular expressions for capitalized namespace lookup (I guess for VB) is executed even when it should not; this is bad, as it picks up false positives and increase the chance of error. 3.) The biggest problem is that NAnt assumes the filename (of the source file) is the name of the class that the RESX should be associated too. This issue killed our use of NAnt (until we fixed it), as our filenames do not match the "Form" class within them; Visual Studio does not have a problem with this. It would be great to see NUnit 2.1 plugged in. I'd also like to see 1.1 as the default. Ian - do you think it would be possible to get the ReplaceTask into the core if I can make it more robust? - Mitch Denny - [EMAIL PROTECTED] - http://www.monash.net - +61 (414) 610141 - -Original Message- From: Ian MacLean [mailto:[EMAIL PROTECTED] Sent: Friday, October 03, 2003 2:31 PM To: [EMAIL PROTEC
Re: [nant-dev] RE: RE: [Fwd: Ready to tackle next release]
Please let me know if I'm totally out to lunch on this one- I'm guessing that this resx issue you are describing is a problem with the task. I haven't really been in the code there lately, but checking in CVS, it looks as if the resource-compiling functionality is operating correctly (with the exception of the not-so-smart regex's you mentioned in your note). I can't see how more than one regex could be run on a single file. Are you running with an older version, or does CVS exhibit the problems you are seeing? Also with regards to "The biggest problem is that NAnt assumes the filename (of the source file) is the name of the class that the RESX should be associated too"- we should (according to the latest code) be parsing the files to determine the correct namespace/filename of the final .resource file. Resources should never be named to match their dependent files. Are you perhaps referring to .resx files that are not associated with any .cs or .vb files? I could see that there could be a problem there, but it seems to match VS.NET's behaviour in all of my tests. Can you please elaborate on #2 and #3 more? Again, if you're not talking about what I think you are, let me know, and I apologize in advance. :) Thanks, Matt. On Fri, 2003-10-03 at 21:21, Ian MacLean wrote: > James, > We'd love to see your patches. The resx issues was a known one - if your > solution is cleaner and more accurate then obviously thats the way to go. > Post patches here and they will be reviewed. > Ian > > >RE: [Fwd: Ready to tackle next release] > > > >If you are getting ready for a new release, I have a bunch of patches I would > >love to see added to NAnt. I would be willing to work with everyone as much > >as needed, to see that the changes make it into the release; or some variation > >of them - that is, if they are accepted. > > > >Here is a run down of our current changes to NAnt: > > > >I have mentioned this one previously; and it involves adding an "options" > >property to CompilerBase.cs. The original post had no subject and came out > >garbled (sorry about that), though I have filed it under RFE "[811931] - > >Adding an "options" property to CompilerBase.cs", where you can read about the > >change in more detail. > > > > > > > > >Another change we made was to allow passing of "parameters" as properties to > >other NAnt scripts via the "nant" task. This works really well and avoids > >having to using the "inheritall" attribute (which can be overkill - > >particularly if you have scripts that call themselves externally...). You can > >think of this feature as adding support for the "-D:" options of nant.exe > > > >The syntax looks like this: > > > > > > > > > > > > > > > > > >The "defines" are created as properties and accessible only from the invoked > >NAnt script as if they were passed with "-D:". Their values are evaluated at > >the time just before the new script is invoked. Note: You can still use > >the "inheritall" attribute as well, though anything defined will override > >anything inherited if there is a name collision. The patch for this change > >is straightforward and simple. The only part left to do is handling all the > >NAnt location stuff with properties, which I am not too sure about (currently, > >I set this to unknown), though I'm sure someone on the list can enlighten me. > > > >Our next change is the most extensive but it fixes a long out-standing issue > >with NAnt. Basically, we did a rewrite on how NAnt handles RESX files. > >Currently NAnt has the following problems: > > > >1.) The regular expressions for determining the namespace are poor and > >are easily confused by comments (that have the word namespace in them, for > >example "// is located in the foo namespace"). > >2.) The regular expressions used by different languages are executed on > >all the source files. For example, when compiling a "*.cs" file the regular > >expressions for capitalized namespace lookup (I guess for VB) is executed even > >when it should not; this is bad, as it picks up false positives and increase > >the chance of error. > >3.) The biggest problem is that NAnt assumes the filename (of the source > >file) is the name of the class that the RESX should be associated too. This > >issue killed our use of NAnt (until we fixed it), as our filenames do not > >match the "Form" class within them; Visual Studio does not have a problem with > >this. > > > > > > > > > >>It would be great to see NUnit 2.1 plugged in. I'd also like to see 1.1 > >>as the default. Ian - do you think it would be possible to get the > >>ReplaceTask into the core if I can make it more robust? > >> > >> > >>- Mitch Denny > >>- [EMAIL PROTECTED] > >>- http://www.monash.net > >>- +61 (414) 610141 > >>- > >> > >> > >> > >>>-Original Message- > >>>From: Ian MacLean [mailto:[EMAIL PROTECTED] > >>>Sent: Friday, October 03, 200
Re: [nant-dev] RE: RE: [Fwd: Ready to tackle next release]
James, We'd love to see your patches. The resx issues was a known one - if your solution is cleaner and more accurate then obviously thats the way to go. Post patches here and they will be reviewed. Ian RE: [Fwd: Ready to tackle next release] If you are getting ready for a new release, I have a bunch of patches I would love to see added to NAnt. I would be willing to work with everyone as much as needed, to see that the changes make it into the release; or some variation of them - that is, if they are accepted. Here is a run down of our current changes to NAnt: I have mentioned this one previously; and it involves adding an "options" property to CompilerBase.cs. The original post had no subject and came out garbled (sorry about that), though I have filed it under RFE "[811931] - Adding an "options" property to CompilerBase.cs", where you can read about the change in more detail. Another change we made was to allow passing of "parameters" as properties to other NAnt scripts via the "nant" task. This works really well and avoids having to using the "inheritall" attribute (which can be overkill - particularly if you have scripts that call themselves externally...). You can think of this feature as adding support for the "-D:" options of nant.exe The syntax looks like this: The "defines" are created as properties and accessible only from the invoked NAnt script as if they were passed with "-D:". Their values are evaluated at the time just before the new script is invoked. Note: You can still use the "inheritall" attribute as well, though anything defined will override anything inherited if there is a name collision. The patch for this change is straightforward and simple. The only part left to do is handling all the NAnt location stuff with properties, which I am not too sure about (currently, I set this to unknown), though I'm sure someone on the list can enlighten me. Our next change is the most extensive but it fixes a long out-standing issue with NAnt. Basically, we did a rewrite on how NAnt handles RESX files. Currently NAnt has the following problems: 1.) The regular expressions for determining the namespace are poor and are easily confused by comments (that have the word namespace in them, for example "// is located in the foo namespace"). 2.) The regular expressions used by different languages are executed on all the source files. For example, when compiling a "*.cs" file the regular expressions for capitalized namespace lookup (I guess for VB) is executed even when it should not; this is bad, as it picks up false positives and increase the chance of error. 3.) The biggest problem is that NAnt assumes the filename (of the source file) is the name of the class that the RESX should be associated too. This issue killed our use of NAnt (until we fixed it), as our filenames do not match the "Form" class within them; Visual Studio does not have a problem with this. It would be great to see NUnit 2.1 plugged in. I'd also like to see 1.1 as the default. Ian - do you think it would be possible to get the ReplaceTask into the core if I can make it more robust? - Mitch Denny - [EMAIL PROTECTED] - http://www.monash.net - +61 (414) 610141 - -Original Message- From: Ian MacLean [mailto:[EMAIL PROTECTED] Sent: Friday, October 03, 2003 2:31 PM To: [EMAIL PROTECTED] Subject: [nant-dev] [Fwd: Ready to tackle next release] --- 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
