James C. Papp wrote:
Great! I will need to refresh the source with the latest code under CVS (I'm currently using code released under v0.83), though I do not think that there will be many changes. Do you want me to zip up the source files that have changed 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 extensively, I'm a Perforce fan.
Also, to clear some confusion:
Matthew, I am referring to Compilerbase.cs as Ian has suggested. I've checked the latest version under CVS and it has the same problems (actually, it does not 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 type the matchNamespaceCapsRE can still be executed. We were hit by this because at the 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 assocated with 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 what I summit is compatible, especially if we want to standardize this stuff in one 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 go. Post patches here and they will be reviewed. Ian
Quoting Matthew Mastracci
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
