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
