Re[2]: [nant-dev] Criteria for next release
Hello Jason, MJ> My vote would be for one distribution package with the binaries for each MJ> .NET framework in separate directories. I don't think that we should MJ> include the documentation or source in the distribution package. We MJ> should instead, direct users to the website for documentation. I would MJ> include a readme doc that explains the basics of getting things setup MJ> (for the newbie), but again, refer to a task reference on the web. MJ> From my perspective, if I want the source, I will just get it from SF MJ> CVS. IMO it is a really bad idea not to include the source in the distribution. It is not always possible to get the sources from SF CVS, because of having internet access through the firewall. Moreover, it is a bit harder to get the sources of stable release than the current sources (because you have to know the CVS tag of the last stable release) (probably, I'm wrong, but my experience of using CVS tells me that this is a possible problem). Do you think that documentation should be available for download as a single file (zip?) (in case, someone needs to read it offline)? -- Best regards, Ivanmailto:[EMAIL PROTECTED] --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re[2]: [nant-dev] Expression Support
Hello Ian, >>If anything, I would think that the xpath expression language would be a >>good start. I'm not sure if I would want an expression language included >>with nant though. This could however be an addin, or extension. Adding >>expressions (as we have discussed before) seems to me to be just one more >>complicating feature for NAnt. >> IM> Actually condition support would be considerably simpler ( from a users IM> point of view ) than a plethora of nested condition tags. AFAIK, it is relatively easy to implement xpath expression language using the System.Xml.XPath.XPathNavigator and System.Xml.XPath.XPathExpression classes, moreover it is possible to implement custom xpath functions by deriving from XsltContext and calling SetContext method with an instance of that derived class on XPathExpression we are executing. I can try to implement all the things I've written above but I'm not sure if I have the same vision of this feature, it would be great if someone explain his vision of the whole thing. -- Best regards, Ivanmailto:[EMAIL PROTECTED] --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] Re: solution task and linked VS.Net files.
Hello Matthew, when you add existing file to the project (in VS.NET), in the open dialog the "Open" button has an arrow on the right side. By clicking on this arrow you activate the popup menu in which you can choose "Link". In that case the file is not copied, in the project the xml attribute Link appears. E.g.: Surely, it is a greate example of non-intuitive UI :-) MM> Viehland, Kirk wrote: >> Nant developers, >> >> I am getting this error when I compile a VS.Net 2003 solution with an >> ProductInfo file that has been linked from a parent directory. MM> Just as a side note - what is a Linked file within a solution? How is MM> one created? -- Best regards, Ivanmailto:[EMAIL PROTECTED] --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re[2]: [nant-dev] Minor NAnt output bug.
Hello Gert, The similar thing happened, as I recall, in nunit2 task, it prints 0x0d after printing the tests results. GD> Nick, GD> This is now fixed in cvs. GD> Thanks for the report, GD> Gert GD> - Original Message - GD> From: "Nick Varacalli" <[EMAIL PROTECTED]> GD> To: <[EMAIL PROTECTED]> GD> Sent: Sunday, November 09, 2003 4:44 PM GD> Subject: [nant-dev] Minor NAnt output bug. >> Using the Oct 31st, 2003 nightly build. >> >> After the total time is displayed (Total time: 203.6 seconds.) there is a >> rectangular box when the log file is viewed in notepad. Looks like a stray >> LF or something that notepad can't handle. >> >> >> Nick >> http://www.varacalli.com -- Best regards, Ivanmailto:[EMAIL PROTECTED] --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
[nant-dev] readonly resources
Hello,
I'm using nant-0.8.3 for our builds and yesterday I have found a
problem. I know that lots of things have changed in since
the release, still I hope this problem to fixed in the 0.8.4.
When building solution which uses embedded resource (doc.bmp in the
example below) and the file with this resource is readonly (in
reality, it is just being taken from the perforce during build) the
build fails because of UnauthorizedAccessException. To workaround this
problem I have to set attributes of all resource files to normal
before calling solution task and reset back to readobly after, which
is not so nice and creates problems with non-readonly files in case of
failing solution task (oh, is still in the end
of my todo).
part of the log:
build.csproj:
[copy] Copying 1 file.
[copy] Copying E:\Root\Transaction\src\VersionInfo.cs to
E:\Root\Transaction\src\SupplyChain\Common\VersionInfo.cs.
[attrib] Setting file attributes for 1 files to Normal.
[attrib] E:\Root\Transaction\src\SupplyChain\Common\VersionInfo.cs
[solution] Starting solution build.
[solution] Included projects:
[solution] - E:\Root\Transaction\src\SupplyChain\Common\Common.csproj
[solution] Reference projects:
[solution] Building Common [Debug]...
[solution] Copying references:
[solution] - System.Drawing
.
some other references
.
[solution] Compiling resources:
[solution] - E:\Root\Transaction\src\SupplyChain\Common\GUI\FoldersGrid.resx
[resgen] Starting 'D:\Program Files\Microsoft Visual Studio .NET
2003\SDK\v1.1\bin\resgen.exe
("E:\Root\Transaction\src\SupplyChain\Common\GUI\FoldersGrid.resx"
"D:\DOCUME~1\TARASO~1.000\LOCALS~1\Temp\l-rbiwnk\Transaction.SupplyChain.Common.GUI.FoldersGrid.resources")'
in 'E:\Root\Transaction'
Read in 13 resources from
'E:\Root\Transaction\src\SupplyChain\Common\GUI\FoldersGrid.resx'
Writing resource file... Done.
[solution] - E:\Root\Transaction\src\SupplyChain\Common\GUI\FieldChooser.resx
[resgen] Starting 'D:\Program Files\Microsoft Visual Studio .NET
2003\SDK\v1.1\bin\resgen.exe
("E:\Root\Transaction\src\SupplyChain\Common\GUI\FieldChooser.resx"
"D:\DOCUME~1\TARASO~1.000\LOCALS~1\Temp\l-rbiwnk\Transaction.SupplyChain.Common.GUI.FieldChooser.resources")'
in 'E:\Root\Transaction'
Read in 46 resources from
'E:\Root\Transaction\src\SupplyChain\Common\GUI\FieldChooser.resx'
Writing resource file... Done.
[solution] - E:\Root\Transaction\src\SupplyChain\Common\GUI\InfoTabs.resx
[resgen] Starting 'D:\Program Files\Microsoft Visual Studio .NET
2003\SDK\v1.1\bin\resgen.exe
("E:\Root\Transaction\src\SupplyChain\Common\GUI\InfoTabs.resx"
"D:\DOCUME~1\TARASO~1.000\LOCALS~1\Temp\l-rbiwnk\Transaction.SupplyChain.Common.GUI.Tabs.resources")'
in 'E:\Root\Transaction'
Read in 82 resources from
'E:\Root\Transaction\src\SupplyChain\Common\GUI\InfoTabs.resx'
Writing resource file... Done.
[solution] - E:\Root\Transaction\src\SupplyChain\Common\doc.bmp
[solution] - E:\Root\Transaction\src\SupplyChain\Common\GUI\FoldersTree.resx
[resgen] Starting 'D:\Program Files\Microsoft Visual Studio .NET
2003\SDK\v1.1\bin\resgen.exe
("E:\Root\Transaction\src\SupplyChain\Common\GUI\FoldersTree.resx"
"D:\DOCUME~1\TARASO~1.000\LOCALS~1\Temp\l-rbiwnk\Transaction.SupplyChain.Common.GUI.TreeFolder.resources")'
in 'E:\Root\Transaction'
Read in 68 resources from
'E:\Root\Transaction\src\SupplyChain\Common\GUI\FoldersTree.resx'
Writing resource file... Done.
[solution] Starting compiler...
[solution] Success! (exit code = 0)
Target failed, calling onfail target 'SupplyChain.Common.failed'
SupplyChain.Common.failed:
Target failed, calling onfail target 'build.all.failed'
build.all.failed:
Total time: 6 seconds.
BUILD FAILED
INTERNAL ERROR
System.UnauthorizedAccessException: Access to the path "Common.doc.bmp" is denied.
at NAnt.Core.Target.Execute()
at NAnt.Core.Project.Execute(String targetName)
at NAnt.Core.Project.Execute()
at NAnt.Core.Project.Run()
Please send bug report to [EMAIL PROTECTED]
--
Best regards,
Ivan mailto:[EMAIL PROTECTED]
* The number you have dialed is imaginary. Please rotate your phone 90 degrees and try
again.
---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
[nant-dev] project references problems in task
Hello nant-developers, I have quite a big project which uses task to build certain .csproj projects. There is a build directory, some projects are built into specific subdirectories of this build directory. Consider following dir structure: build | +-ProjectA During the build I have some projects built directly into build directory. ProjectA is built into the respective folder, but it references some dll's in build directory and has CopyLocal set to "true" for these references. Thus, as we can expect, these dll's are copied to ProjectA directory. The problem is that not only these dll's (and the dll's which they reference) are copied to ProjectA, but all dll's in build directory! Thus, I have lots of dll's in ProjectA which shouldn't be there. VS2003 is smart enough to copy only those libraries, which are referenced from the project. I've tracked down where the solution task does it wrong (in the latest nightly build it is Nant\src\NAnt.VSNet\Reference.cs:265-278. I've written little program which finds all the referenced assemblies in the current folder (for the given assembly) (it was just a proof-of-concept). I'm going to add this code to Reference.cs (it will add just two methods and a call to one of them instead of "Directory.GetFiles(fi.DirectoryName, "*.dll")" in line 265, but I need to clean the code up a little bit. If anybody can comment upon that change, please let me know. I will send the patch here after the clean-up. -- Best regards, Ivan mailto:[EMAIL PROTECTED] * To err is human. To really foul up you need a computer. --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re[2]: [nant-dev] project references problems in task
Hello Martin,
MA> you are right - this is problem in current setup. I was also point to that,
MA> but there are some problems how to find references to assembly without lock
MA> them. Current framework sometimes locks assemblies when you load them (even
MA> into another appdomain). VS2003 has also problem with it [cannot copy
MA> because another process use this file error]
MA> If you have some another method how to find those references, send it here!
MA> [possible also as path to reference.cs]
Thanks for the quick response, I didn't know about that problem with
framework. I'm not sure if it is really a problem, since in almost all
cases assemblies should not be written to more than once (I mean their
creation time).
In VS2003 I've had some locking problems when using my GUI component
located in another project and this project was in current solution
and the main project depended on it. In that case, the GUI component
needs to be built first, but when it is being copied to the directory
to which main project references, it fails. After some investigation I
understood that Windows.Forms designer locks the .dll, thus I have to
unload project which uses the component before building it. Probably,
this is the case you are describing (or some variation of it).
So, here is the patch. I'm quite new to .NET (3 months of experience
in it), and I still cannot find needed classes which I want to use.
So, please excuse me for using linear search in ArrayList instead of
using some kind of "set" class (as it could do in C++).
I've tested it on my projects and it worked (and I've still had no
problems with locking), so I'm pretty sure it is better than copying
all the files from the given directory.
--- Patch to Reference.cs, from nightly build (28.11.03) ---
23a24
> using System.Collections;
265c266
< foreach (string referenceFile in Directory.GetFiles(fi.DirectoryName,
"*.dll")) {
---
> foreach (string referenceFile in
> GetAllReferencedModules(_referenceFile)) {
283d283
<
309a310,336
>
> private string[] GetAllReferencedModules(string module) {
> string fullPathToModule = Path.GetFullPath(module);
> string moduleDirectory = Path.GetDirectoryName(fullPathToModule);
>
> ArrayList referenceList = new ArrayList();
> referenceList.Add(fullPathToModule);
>
> for (int currentModule = 0; currentModule < referenceList.Count;
> currentModule++) {
> AppendReferencedModulesLocatedInGivenDirectory(moduleDirectory,
> (string) referenceList[currentModule], referenceList);
> }
>
> return (string[]) referenceList.ToArray(typeof(string));
> }
>
> private void AppendReferencedModulesLocatedInGivenDirectory(string
> moduleDirectory,
> string
> moduleName, ArrayList referenceList) {
> Assembly module = Assembly.LoadFrom(moduleName);
> AssemblyName[] referencedAssemblies = module.GetReferencedAssemblies();
>
> foreach (AssemblyName referencedAssemblyName in referencedAssemblies) {
> string fullPathToReferencedAssembly = string.Format(@"{0}\{1}.dll",
> moduleDirectory, referencedAssemblyName.Name);
> // we only add referenced assemblies which are located in given
> directory
> if (File.Exists(fullPathToReferencedAssembly) &&
> !referenceList.Contains(fullPathToReferencedAssembly))
> referenceList.Add(fullPathToReferencedAssembly);
> }
> }
End of Patch -
--
Best regards,
Ivanmailto:[EMAIL PROTECTED]
---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
Re[4]: [nant-dev] project references problems in task
Hello Martin, MA> locking problems occurs only to assemblies bigger than 64kB. Do you test it MA> with larger assemblies? I do. From VS2003 I have to workaround such problems (by unloading project which references the locked one), but I don't see why we have to take it into account -- as far as I reckon, it is only a problem of VS2003, and not of the framework. -- Best regards, Ivanmailto:[EMAIL PROTECTED] --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
[nant-dev] bug in resources compiling
Hello nant-developers,
I've found a bug in resource compiling (for dependent resources):
(according to nightly build from 28.11.03) in Resource.cs:104 there
is a regex which extracts namespace name and class name. The problem
is that it expects that the class is derived from something (it
extracts the class name till the ':' symbol), which is generally not
true.
So, the right regex should be something like
Regex re = new Regex(@"
(?>namespace(?(.|\s)*?){)
|
> (?>class(?.*?)[:{])
|
}
", RegexOptions.IgnorePatternWhitespace | RegexOptions.Multiline |
RegexOptions.Compiled);
(the changed line is highlighted)
--
Best regards,
Ivan mailto:[EMAIL PROTECTED]
* Beware of the man who knows the answer before he understands the question.
---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
Re[2]: [nant-dev] Re: project references problems in task
Hello Matthew,
I've implemented the proof-of-concept program, which creates AppDomain
and loads assemblies there, but I'm not sure if it works around the
problem you've described. Probably it would be good to set up some
security policy for the newly-created AppDomain, so that the loaded
assembly couldn't do any harm (AFAIR, static constructors are called
when assembly is being loaded). Also, in MSDN there is a clause that
it may take quite a time to Unload the AppDomain. An alternative way
is to call Abort on all threads of this domain which is a bit harsh.
I'm not sure which way to go, please tell your opinion if you find
some way to be the preferable one.
Program source is attached, it just prints the names of referenced
assemblies.
I'm also going to do some speedup by using Hashtable, so don't take
the current ArrayList implementation into account.
It would be great if somebody commented upon that code (style/bad
practices/etc.), so that I could change it now.
MM> AppDomains allow you load/unload assemblies at will. The .NET runtime
MM> tends to exhibit some odd/unpredictable behaviour as you load assemblies
MM> with the same name, especially if they don't have strong names. You can
MM> end up with types no longer resolving as expected. By loading
MM> assemblies in the separate AppDomain, you side-step all of these issues.
--
Best regards,
Ivanmailto:[EMAIL PROTECTED]using System;
using System.IO;
using System.Collections;
using System.Reflection;
using System.Runtime.Remoting;
public class GetRefs {
public static void Main(string[] p_args) {
if (p_args.Length != 1) {
Console.WriteLine("usage: refs ");
return;
}
string[] referenced = GetAllReferencedModules(p_args[0]);
Console.WriteLine("Referenced:");
Console.WriteLine(string.Join("\n", referenced));
}
private static string[] GetAllReferencedModules(string module) {
string fullPathToModule = Path.GetFullPath(module);
string moduleDirectory = Path.GetDirectoryName(fullPathToModule);
AppDomain temporaryDomain = AppDomain.CreateDomain("temporaryDomain");
ArrayList referenceList = new ArrayList();
try {
ReferencesResolver referencesResolver =
((ReferencesResolver) temporaryDomain.CreateInstanceFrom("refs.exe",
typeof(ReferencesResolver).FullName).Unwrap());
referenceList.Add(fullPathToModule);
for (int currentModule = 0; currentModule < referenceList.Count;
currentModule++) {
referencesResolver.AppendReferencedModulesLocatedInGivenDirectory(moduleDirectory,
(string) referenceList[currentModule], ref referenceList);
}
} finally {
AppDomain.Unload(temporaryDomain);
}
return (string[]) referenceList.ToArray(typeof(string));
}
}
public class ReferencesResolver : MarshalByRefObject {
public void AppendReferencedModulesLocatedInGivenDirectory(string moduleDirectory,
string moduleName,
ref ArrayList
referenceList) {
Assembly module = Assembly.LoadFrom(moduleName);
AssemblyName[] referencedAssemblies = module.GetReferencedAssemblies();
foreach (AssemblyName referencedAssemblyName in referencedAssemblies) {
string fullPathToReferencedAssembly = string.Format(@"{0}\{1}.dll",
moduleDirectory, referencedAssemblyName.Name);
// we only add referenced assemblies which are located in given directory
if (File.Exists(fullPathToReferencedAssembly) &&
!referenceList.Contains(fullPathToReferencedAssembly))
referenceList.Add(fullPathToReferencedAssembly);
}
}
}
Re[2]: [nant-dev] Re: project references problems in task
Hello Matthew, I've fixed the current implementation of Reference.cs in VSNet-tasks project. Now it creates new AppDomain in which it tries to resolve all assemblies which are referenced from the given assembly, which are located in the same directory. Recently, all assemblies in that directory were copied. I've tested it on our project (I was patching nightly build sources from 03.12.03) and it worked pretty well. Hope this part of code will be suitable for putting it before the 0.8.4 release (we are waiting impatiently for this release). Patch is attached (it was "diff -C 3"). MM> (re-cc'ing the list) MM> AppDomains allow you load/unload assemblies at will. The .NET runtime MM> tends to exhibit some odd/unpredictable behaviour as you load assemblies MM> with the same name, especially if they don't have strong names. You can MM> end up with types no longer resolving as expected. By loading MM> assemblies in the separate AppDomain, you side-step all of these issues. -- Best regards, Ivanmailto:[EMAIL PROTECTED] Reference.cs.patch Description: Binary data
Re[2]: [nant-dev] Re: project references problems in task
Hello Matthew, MM> Looks pretty good to me. Do you notice an impact on compile speed? I don't. I'm building from remote login session to two-processor Pentium 4 :-) But if all of the dll's are copied my build fails because it tries to run tests on dll's in some subfolders which need config files (and they are not copied). I just don't care a lot since build speed is not a major concern for me. Still, there is a possibility for slow-down -- AppDomain.Unload can be blocked for arbitrary time by finishing threads in it. MM> I can try patching my local copy of NAnt and running it through our MM> build torture test - 90+ projects with all sorts of inter-project and MM> 3rd-party references. :) I may not have time to do this until next MM> week, however. That would be great if you try to do it! I could provide necessary feedback in case of any problems. -- Best regards, Ivanmailto:[EMAIL PROTECTED] --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re[2]: [nant-dev] NAnt task "passbyref" extension
Hello Martin, MA> Yes, the echo would show: "Prop: 2". Our primary use is to report MA> unit tests that fail at the end of a lengthy build process. We MA> have nearly 100 C# projects, plus several non-managed C++. Our MA> build system compiles the code for a particular project and then MA> compiles and runs its unit tests. Rather than have the build stop MA> if a test fails, we check the modified property, and create a MA> report about the failure. All such failures are then reported at MA> the end of the build. Hmm. I sometimes feel very simmilar. NAnt is MA> missing some mechanism how to control output states from tasks. MA> on-failure is good but sufficient only in basic scenarios. Maybe MA> every task should create some output something (xml dom would be MA> great) with detailed report what has been done and what failed (in MA> case of failonerror="false"). Detailed error reporting (e.g. in the case of unit-tests) is quite a tough problem to challenge in 0.8.3 if you have a rapidly growing project and you need your build script to automatically adapt to the changes and additions to the projects. I'd already proposed onfail mechanism for tasks and targets (in the beginning of October, as I recall), but I was advised to try to implement try/catch/finally task which is a bit more flexible. I asked if anyone really had a need for it, and got no replies, and as the "onfail" patch satisfied my needs, I gave up implementing try/catch. Probably, it is the time to think over once again how this bit of functionality should be done. Also, the task needs some improvements to enable logs with different "granularity" to be written. -- Best regards, Ivanmailto:[EMAIL PROTECTED] --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re[2]: [nant-dev] Change to "call" task makes upgrade difficult
Hello Scott, SH> The reason, please correct me in my memory is off, for the deprecation of SH> the "force" attribute was because of the change to the task to do SH> this by default. The idea was that if you want the behavior of dependencies, SH> you will use that mechanism (via the depends attribute of the target), but SH> if you want a target (and its dependencies) executed, you will use the SH> task. The idea works as far as you know the target name when you write build script. If it is generated somehow (unfortunately, we have and need it in our build), you cannot really use "depends". SH> Now, the example of is a little SH> ambiguous. Do you mean, don't force "foo" (meaning only execute if it hasn't SH> yet), or don't force all the dependencies, or both? Would your > not force any executions? Surely, I mean don't force "foo", and I don't want to think at all about what it depends on, it is some stuff which is _internal_ to the "foo" target and it claims that it needs that all these targets in depends had already been called before executing "foo". If "call" calls the depends again, disregarding the fact that they had been already executed, it smells more like a mistake/thinko. SH> Not to put Gert on the spot, but I think he may remember all this stuff a SH> little more vividly than I. I think he was the once to deprecate >. SH> Now that I'm thinking about this, maybe the depends stuff should work so SH> that if anything you depend on executes again, your previous executions SH> should be ignored. We are arguing about the meaning of the word "depends", and the vision of it have shifted from what it was considered to be previously (which is a bit sad for me). -- Best regards, Ivanmailto:[EMAIL PROTECTED] --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] new xml type
Hello Martin,
It's a good idea, still it is a bit complicated to deal with xmlpeek,
if you need a single value. Surely, function will help a lot.
MA> What I want to do is something James and Ivan also proposed: add some way to
MA> return information from task back to script. I dont think that add
MA> resultproperty/outputproperty to exec task and other whateverproperties to
MA> other tasks is good way. What I want to do is add one general attribute
MA> (e.g. result) to all tasks. Result itself will be xml dom with potentionaly
MA> many values. exec task could for example have in it full commandline
MA> executed, result code, stdout, stderr and maybe even more things! So it
MA> could be written something like this:
MA> commandline="${foldername}\${folder}.csproj ${version}" result="res1" />
MA>
MA>
MA>
MA>
MA> or even shorter when function for xmlpeek exists!
--
Best regards,
Ivanmailto:[EMAIL PROTECTED]
---
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] [ nant-Bugs-890721 ] copying all assemblies for framework
Hello SourceForge.net, I have already sent a report here and also sent a patch which searched through the dependency list recursively and only the referenced assemblies from given directory were copied. For more info you may take a look at my letter dated 4 Dec 2003 20:21:50 +0300, or I can resend it again. I'm not sure that this is the intended behaviour because it differs from the behaviour of VS.NET solution compiling. ps: sorry for possible dup Sn> Initial Comment: Sn> the tag is copying all assemblies from the Sn> Framework v1.1 to the bin directory of the solution that Sn> I am compiling. Sn> -- Sn> Comment By: Brant Carter (brantcarter) Sn> Date: 2004-02-05 01:49 Sn> Message: Sn> Logged In: YES Sn> user_id=687388 Sn> This is the intended behaviour. You can change the IsPrivate Sn> attribute of your project files to change this behaviour. Sn> IsPrivate=False Sn> -- Sn> Comment By: Gert Driesen (drieseng) Sn> Date: 2004-02-04 13:42 Sn> Message: Sn> Logged In: YES Sn> user_id=707851 Sn> Nick, Sn> Can you package up a zip file containing the minimum set of Sn> files necessary to reproduce this issue ? -- Best regards, Ivanmailto:[EMAIL PROTECTED] --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] [ nant-Bugs-890721 ] copying all assemblies for framework
Hello SourceForge.net, I have already sent a report here and also sent a patch which searched through the dependency list recursively and only the referenced assemblies from given directory were copied. For more info you may take a look at my letter dated 4 Dec 2003 20:21:50 +0300, or I can resend it again. I'm not sure that this is the intended behaviour because it differs from the behaviour of VS.NET solution compiling. Sn> Initial Comment: Sn> the tag is copying all assemblies from the Sn> Framework v1.1 to the bin directory of the solution that Sn> I am compiling. Sn> -- Sn> Comment By: Brant Carter (brantcarter) Sn> Date: 2004-02-05 01:49 Sn> Message: Sn> Logged In: YES Sn> user_id=687388 Sn> This is the intended behaviour. You can change the IsPrivate Sn> attribute of your project files to change this behaviour. Sn> IsPrivate=False Sn> -- Sn> Comment By: Gert Driesen (drieseng) Sn> Date: 2004-02-04 13:42 Sn> Message: Sn> Logged In: YES Sn> user_id=707851 Sn> Nick, Sn> Can you package up a zip file containing the minimum set of Sn> files necessary to reproduce this issue ? -- Best regards, Ivanmailto:[EMAIL PROTECTED] --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
[nant-dev] problem with task: copying referenced files and taking into account their attributes
Hello nant-developers, I've searched through the mail-list but could not find the following issue: VS.NET 2003 copies referenced assemblies to the output directory. If there exists file which it tries to copy with read-only attribute set, compilation fails. If copying succeedes and the file which has been copied had read-only attribute set, it is reset (so, file attributes become Normal). On the other hand, task always copies referenced assemblies "as-is", preserving their attributes. If there already existed that assembly, even with read-only attributes, it is rewritten. Such a difference causes problems when we try to mix building using nant and building some modules using Visual Studio. I've investigated these differences and found that the first one (read-only files get overwritten) is the result of using the task in Project.cs, which just resets the attributes to Normal, if they are not (probably, there is some sense in adding one more parameter to task, something like "clobberreadonly"), the second problem may be fixed by invoking the AttribTask task just after copying, to reset the attributes. -- Best regards, Ivan mailto:[EMAIL PROTECTED] * Life is complex. It has real and imaginary components. --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re[2]: [nant-dev] 2 small changes to consider
Hello Nicklas, probably, the best way to fill the gap would be to implement task as it is done in Ant. I considered starting to implement this functionality, but at the time I learnt about the way it is done in Ant, I'd already made the "onfail" patch which we use now in our build-scripts. It allows to call arbitrary task on some task or target failure (you just have to add "onfail='taskToCall'" attribute to the corresponding task/target element). I've sent here this patch, but surely it was not so nice as a solution of the problem, should be a better way. I have all my projects building with "onfail" patch, and it works, so I gave up trying to do some new thing which no one needs except me. Now probably, the time has come to do such a thing, still, it should be thoroughly though over, how to do it in a right way. ps: see http://ant-contrib.sourceforge.net/tasks/trycatch.html for ant task description. >> -Original Message- >> From: Gert Driesen [mailto:[EMAIL PROTECTED] >> Sent: den 27 februari 2004 08:37 >> To: Hemry, Jeff; [EMAIL PROTECTED] >> Subject: Re: [nant-dev] 2 small changes to consider >> >> >> >> > - Original Message - >> > From: "Hemry, Jeff" <[EMAIL PROTECTED]> >> > To: <[EMAIL PROTECTED]> >> > Sent: Thursday, February 26, 2004 8:48 PM >> > Subject: [nant-dev] 2 small changes to consider >> > >> >> > Hi all, >> > >> > >> > >> > Here are 2 small changes put in place for our specific >> needs that may be >> > beneficial to the whole group. >> > >> > >> > >> > 1) Multiple files: Added a project level variable called >> > nant.project.failure, such that a you can allow a task or >> group of tasks >> > to complete regardless of failure using failonerror=false, and then >> > afterwards check the value of nant.project.failure to determine if a >> > failure occurred. Very useful for batch nunit tests, and gathering a >> > report of the tests before checking if a failure occurred >> and throwing a >> > fail. >> >> Not sure if we should something like this, but we'll give it >> some thought >> ... NN> This points out a gap in nant as I see it. What Jeff has made a patch NN> for is actually a pretty large gap in functionality in nant. NN> Controlling the flow using failure detection and also log that neatly NN> for other tools to pick up (CCNet comes to mind) is challenging to say NN> the least. NN> I for one would love to see some of the big brains storm some on this NN> issue. I've got a pretty good knowledge about what I need, but no matter NN> how much I think about it I can't figure out a good suggestion to come NN> up with. NN> What do the rest of you guys and girls out on the list think about it? NN> Would be interesting to hear your opinions. NN> (Gosh... did I hijack this thread?) NN> /Nicke NN> --- NN> SF.Net is sponsored by: Speed Start Your Linux Apps Now. NN> Build and deploy apps & Web services for Linux with NN> a free DVD software kit from IBM. Click Now! NN> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click NN> ___ NN> nant-developers mailing list NN> [EMAIL PROTECTED] NN> https://lists.sourceforge.net/lists/listinfo/nant-developers -- Best regards, Ivanmailto:[EMAIL PROTECTED] --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
[nant-dev] onFail patch
Hello nant-developers,
I want to discuss some ideas I have on failures which occur during the
build process. I've been desperately trying to solve the problems
which I'm going to address in this letter using the standard features
of NAnt and I've found that the ways by which I can solve these
problems are very far from being nice and reasonable.
Consider such a problem (it is a simplified version of a problem I
had):
I have a build file for quite a big project, which consists of several
subprojects. For simplicity, lets consider that these subprojects are
independent and built in some fixed order. To be more general, I have
a bunch of targets, which i call using the task:
...
...
The problem is, that I only get mail on successful build. And the
bigger problem is, that when some of the A,B,C targets fails and I
don't get any mail, I don't know, which target has the problem (of
course, unless I do take a look at the log). To be more specific, I
also want that different mail messages were sent to the different mail
addresses in case of different targets failures (sorry for a bit
awkward explanation).
Of course, in I can add failonerror="false", and then after
each call check some property which is set in the end of the
previously called target, but it is a really ugly hack!
I'm still not sure, if it was the only way of doing failure
notification, but it was the only one I could guess.
I've had some time thinking this over, and came to a conclusion that
some kind of "exception handling" similar to the C# kind is needed.
I've inspected the .Core source code (thanks for the great code, it's
very easy to read it!), and decided to make a small patch.
My idea of solution of the problem was the following:
we add the onfail attribute to (I mean the base class here) and
, and, in case of failure, the target which has the name of the
value of the onfail attribute is called. Surely enough, I don't want
only to send the mail in case of unsuccessful build, I had some other
things to do :-)
There are some tricky parts in such a solution:
- how do we handle the failure of the task, which was called "onfail"
- getting the failure info in the "onfail" task (for example, to send
part of the build log to the "subscribed" developers)
- probably, some other I don't remember now...
The first one is "solved", but I don't like the way I did it: I've
created host for multiple exceptions, so the data of all can be
retrived. I wanted to bind the exceptions by adding the exception from
failed task/target as a constructor parameter for the second
exception, but it is impossible, because target (in the meaning of
class) does not know, that it was called "by reason of the exception".
I have some thoughts on the second one (it is not solved in any way),
but it can demand quite a serious design ideas/changes. Again, I don't
have the stories, which describe how I want to see such a feature.
Still I'm sure it can be very useful and needs lots of opinions to
base on.
I've implemented the tests first, the do pass and are included into
the patch. The patch is in the attach, but it is in quite a strange
format (I've ripped the parts of the changes history from Perforce).
Sorry for this inconvinience. Also the new file (with the strange
exception implementation) is in the attach.
I'm ready to discuss any ideas of what was done wrong and how it
should be done. I'm ready to take part in the development of this
feature if it will be redesigned.
--
Best regards,
Ivan mailto:[EMAIL PROTECTED]
onFail.diff
Description: Binary data
// 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
//
// Gerry Shaw ([EMAIL PROTECTED])
// Mike Krueger ([EMAIL PROTECTED])
// Ian MacLean ([EMAIL PROTECTED])
// William E. Caputo ([EMAIL PROTECTED] | [EMAIL PROTECTED])
// Gert Driesen ([EMAIL PROTECTED])
//
// Ivan Y. Tarasov ([EMAIL PROTECTED])
using System;
using System.Globalization;
using System.Runtime.Serialization;
using System.Security.Permissions;
namespace NAnt.Core {
[Serializable]
public class MultipleException : ApplicationException {
private Exception[] _exceptions = null;
public Exception[] Exceptions {
get { return _exceptions; }
}
Re[4]: [nant-dev] onFail patch
Hello Gert, such a task does really makes sense, still, I feel we have two (a bit) different approaches to solve the problem. There is one "pro" for my approach -- it is possible to add "onfail" attribute to a target element, thus, if target B depends on A, the B gets executed and A fails during dependant targets execution, we can do something on A failure: ... ... ... Probably, there is some sense in combining both of the approaches: implementing task and leaving "onfail" attribute for target only (I'd added it for task first and the next day found out, that I need to handle the case similar to the one I've described above, so I added it for target also). Anyway, whatever the final idea of the solution will be, I'm ready to participate in its development. GD> - Original Message - GD> From: "Ivan Tarasov" <[EMAIL PROTECTED]> GD> To: "Gert Driesen" <[EMAIL PROTECTED]> GD> Sent: Wednesday, October 08, 2003 7:24 PM GD> Subject: Re[2]: [nant-dev] onFail patch >> Hello Gert, >> >> the problem is, that I don't want to get all the log (I want to track >> the subproject, which failed), and also, I want more than just sending >> e-mail. Here is one of the scenarios (again, the simplified one): >> >> just before the build, on the build script I check out build version >> file, then I increment the version and try to compile. In case of >> compilation failure I need to undo the checkout of the build version >> file. >> >> I consider, there is need for some kind of "destructor" or "catch/finally" >> construct, the patch covers some part of these functionality. GD> Ant actually solved this by adding a trycatch task (in AntContrib, GD> http://ant-contrib.sourceforge.net/tasks/trycatch.html) GD> Gert -- Best regards, Ivanmailto:[EMAIL PROTECTED] --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re[6]: [nant-dev] onFail patch
So, the question is: should I start developing the task and also leave the onFail part for targets? Have anybody really analyzed the way in which I've done onfail -- do you have some claims on its implementation? Also, how should I address the problem of getting log only for the part really included in the block? (I'm still hadn't enough time to dive that deep into nant design, probably it's easy, I'm just not sure in that) MA> I like onFail attribute slightly better then current nant.onfailure. Setting MA> some special property looks little weird for me. But it is enough for most MA> projects, I think. MA> Martin >> Hello Gert, >> >> such a task does really makes sense, still, I feel we have two >> (a bit) different approaches to solve the problem. >> >> There is one "pro" for my approach -- it is possible to add "onfail" >> attribute to a target element, thus, if target B depends on A, the B >> gets executed and A fails during dependant targets execution, we can >> do something on A failure: >> >> >> >> ... >> >> >> ... >> >> ... >> >> >> Probably, there is some sense in combining both of the approaches: >> implementing task and leaving "onfail" attribute for target >> only (I'd added it for task first and the next day found out, that I >> need to handle the case similar to the one I've described above, so I >> added it for target also). >> >> Anyway, whatever the final idea of the solution will be, I'm ready to >> participate in its development. >> -- Best regards, Ivanmailto:[EMAIL PROTECTED] --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
[nant-dev] links to the files in solution
Hello, unfortunately, I've lost the track of the current development of nant and now I just can't catch up (I haven't had the e-mail in september, thus I've missed lots of things which were going on since the 0.8.3). I'm using nant-0.8.3 and waiting for the next stable version to join the development. I'm not sure if the bug I'm describing is present in "current" version of nant, but in 0.8.3 I have it. The problem is in the task, which doesn't analyse the "link" attribute in the .csproj file. I have an example: I have a project which needs to compile with the .cs file which is placed outside of the project folder. It's was a real challenge to find out, what I have to do in vs2003 to avoid copying of that file to the project folder. But when I did, the nant build failed. This is an extract of what vs2003 writes into .csproj to refer to the files from outside: The problem is that task analises only RelPath, thus it cannot find VersionInfo.cs (as you can see, it is really located one folder "above"). PS: I would really appreciate if somebody told me about the plans of the development (approx release date and development tasks for the release), and how to help the development in its current stage. -- Best regards, Ivan mailto:[EMAIL PROTECTED] * Everything put together falls apart sooner or later. --- This SF.net email is sponsored by: The SF.net Donation Program. Do you like what SourceForge.net is doing for the Open Source Community? Make a contribution, and help us add new features and functionality. Click here: http://sourceforge.net/donate/ ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re[2]: [nant-dev] MSBuild
Hello Clayton, >>#1 difference - the source availability! :) CH> Very, very good point! :-) Or more precisely, its unavailability :-) It's probably better to restate this one: source should be Open (in the meaning of OSD). If it is an MS Shared Source initiative, it is evil, IMO. -- Best regards, Ivanmailto:[EMAIL PROTECTED] --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
