Ian
Gert Driesen wrote:
I would advise you to have a look at the patch that was submitted as part of bug report #805307 (http://sourceforge.net/tracker/index.php?func=detail&aid=805307&group_id=31 650&atid=402868) and at the remarks I made to the author (included in the log of the bug report) ...
I really think we can use large parts of the patch ...
Gert
----- Original Message ----- From: "Ian MacLean" <[EMAIL PROTECTED]>
To: "James C. Papp" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Tuesday, October 07, 2003 6:51 AM
Subject: [nant-dev] Re: [Fwd: Ready to tackle next release] (Patches)
(I'mJames, zip them up and post to me or the list. Big zips will get bounced by the list software so better if you can post it on a site somewhere.
If you want to make patches the easiest way is to use tortoisecvs. http://www.tortoisecvs.org/. WIth it you can just select a file or group of files and select the 'make patch' option. Funnily enough someone else submitted a fix for the resx issue that I am currently reviewing - it required the addition of about 6 new files so it may not be the most efficent design. I'd like to compare your implementation and take the best from both of them. The other impl includes a bunch of unit tests which will also be useful.
Ian
James C. Papp wrote:
Great! I will need to refresh the source with the latest code under CVS
therecurrently using code released under v0.83), though I do not think that
havewill be many changes. Do you want me to zip up the source files that
extensively, I'mchanged and post them to the list, or do you want me to use some tool to
create differences. Does CVS do that? I've used CVS but not
checkeda Perforce fan.
Also, to clear some confusion:
Matthew, I am referring to Compilerbase.cs as Ian has suggested. I've
doesthe latest version under CVS and it has the same problems (actually, it
type thenot look like the RESX stuff was touched since the v.083 release).
Here's what in CVS now (Compilerbase.cs):
protected virtual string GetFormNamespace(string resxPath) { string retnamespace = ""; StreamReader sr = null;
// open matching source file if it exists string sourceFile = resxPath.Replace("resx", Extension);
try { sr = File.OpenText(sourceFile);
while (sr.Peek() > -1) { string str = sr.ReadLine(); string matchnamespace = @"namespace ((\w+.)*)"; string matchnamespaceCaps = @"Namespace ((\w+.)*)"; Regex matchNamespaceRE = new Regex(matchnamespace); Regex matchNamespaceCapsRE = new Regex(matchnamespaceCaps);
if (matchNamespaceRE.Match(str).Success){ Match namematch = matchNamespaceRE.Match(str); retnamespace = namematch.Groups[1].Value; retnamespace = retnamespace.Replace("{", ""); retnamespace = retnamespace.Trim(); break; } else if (matchNamespaceCapsRE.Match(str).Success) { Match namematch = matchNamespaceCapsRE.Match(str); retnamespace = namematch.Groups[1].Value; retnamespace = retnamespace.Trim(); break; } } return retnamespace; } catch (FileNotFoundException) { // if no matching file, dump out return null; } finally { if (sr != null) { sr.Close(); } } }
Ellaborting on #2, from this code you can see that regardless of file
atmatchNamespaceCapsRE can still be executed. We were hit by this because
assocatedthe top of each of our sorucefiles we have a standard header as well as documention, and it just so happened to include the word "Namespace".
With #3, NAnt does nothing to look for the class name, and just uses the
filename which is not always correct; the path to a RESX file is
what Iwith the class name, not the filename.
Matt, you seem to indicate that this type of work is being done somewhere
else. Where is this located, I should take a look at it, to make sure
onesummit is compatible, especially if we want to standardize this stuff in
go.place.
Thanks, James.
Quoting Ian MacLean <[EMAIL PROTECTED]>:
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
Quoting Matthew MastracciPost patches here and they will be reviewed. Ian
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 <solution> 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.
------------------------------------------------------- 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
