[nant-dev] Another RC soon?
Title: Another RC soon? Any idea when there will be another RC? It's been a while since RC3 and there have been lots of useful/important changes.
[nant-dev] debug=true/full and DEBUG
I am wondering about another issue that I initially thought might be helped bythe change below, but it turned out not quite. I think this has been asked before (a long time ago), but I figured I'd ask again. Currently (in cvs), the csc task sets the DEBUG symbol if debug is true, Full, or PdbOnly. That is fairly limiting in the first two cases and I think conceptually "wrong" in the last case. By setting DEBUG, many conditionally compiled functions are included in the compiled assembly. In the PdbOnly case, that is probably not what is desired. Someone using PdbOnly probably wants a "release" style build but with a pdb file. They will instead get all their DEBUG stuff included (Debug.Writeline, Debug.Assert, etc). Our situation is slightly different. We would like to turn on the debug build (to include debugging symbols), but *not* define DEBUG. In VS.NET project files, I believe it's possible to control debug symbols separately from compilation symbols such as DEBUG. We've wished for a while that this was possible in the csc task. Any thoughts on perhaps another entry in the DebugOutput enum that would allow this sort of situation? Or some other workaround? Thanks!! From: Gert Driesen [mailto:[EMAIL PROTECTED]Sent: Sat 3/5/2005 8:43 AMTo: Walker, Brian; nant-developers@lists.sourceforge.netSubject: RE: [nant-dev] Patch for 1156702 [snip] I've just added support for the different debug types to cvs. Before this change, our compiler tasks only supported either full debug output or no debug output at all. [snip]
RE: [nant-dev] debug=true/full and DEBUG
That would work great! I agree that whatever is done, it should be non breaking to existing true/false settings. From: Gert Driesen [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 08, 2005 2:45 PM To: Erv Walter; nant-developers@lists.sourceforge.net Subject: RE: [nant-dev] debug=true/full and DEBUG Hi, I agree that it would've been better to not implicitly set symbols, but instead leave it up to the build authors to use the define attribute for this purpose. I'm not sure whether its a good idea to introduce such a (breaking) change. We could ofcourse not define any symbols when the debug attribute is set to Full, PdbOnly orNone. What do you think ? Gert From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Erv Walter Sent: dinsdag 8 maart 2005 20:29 To: Gert Driesen; nant-developers@lists.sourceforge.net Subject: [nant-dev] debug=true/full and DEBUG I am wondering about another issue that I initially thought might be helped bythe change below, but it turned out not quite. I think this has been asked before (a long time ago), but I figured I'd ask again. Currently (in cvs), the csc task sets the DEBUG symbol if debug is true, Full, or PdbOnly. That is fairly limiting in the first two cases and I think conceptually wrong in the last case. By setting DEBUG, many conditionally compiled functions are included in the compiled assembly. In the PdbOnly case, that is probably not what is desired. Someone using PdbOnly probably wants a release style build but with a pdb file. They will instead get all their DEBUG stuff included (Debug.Writeline, Debug.Assert, etc). Our situation is slightly different. We would like to turn on the debug build (to include debugging symbols), but *not* define DEBUG. In VS.NET project files, I believe it's possible to control debug symbols separately from compilation symbols such as DEBUG. We've wished for a while that this was possible in the csc task. Any thoughts on perhaps another entry in the DebugOutput enum that would allow this sort of situation? Or some other workaround? Thanks!! From: Gert Driesen [mailto:[EMAIL PROTECTED] Sent: Sat 3/5/2005 8:43 AM To: Walker, Brian; nant-developers@lists.sourceforge.net Subject: RE: [nant-dev] Patch for 1156702 [snip] I've just added support for the different debug types to cvs. Before this change, our compiler tasks only supported either full debug output or no debug output at all. [snip]
RE: [nant-dev] automated builds
Those tasks are better handled by a build coordinator tool. Check out one of these (both support using nant to do the actual build): http://draconet.sourceforge.net/ http://www.continuousintegration.net/ These tools monitor source control systems (or even just a directory on the file system in the case of cruisecontrol.net) and trigger a build (i.e. start nant) when a change is detected. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jamie BriantSent: Wednesday, February 09, 2005 12:50 PMTo: nant-developers@lists.sourceforge.netSubject: [nant-dev] automated builds Im trying to get myself off visual build pro and on to nant, but nant appears to be missing two key features: Waiting for a file to be touched or added. Repeating tasks indefinitely I use it to trigger a build whenever someone commits. Any have such a thing? Jamie
[nant-dev] cl and link tasks
Title: cl and link tasks
Is there any way to get the cl/ and link/ tasks to work without having Visual Studio environment variables setup (i.e. the PATH variable)? The .NET tasks detect the correct location to run from, but the C++ tasks dont. Is there anything I can do in Nant.exe.config to help this along? I tried this (in the .NET 1.1 framwork section), but it doesnt work:
readregistry
property=vsDevInstallDir
key=SOFTWARE\Microsoft\VisualStudio\7.1\InstallDir
hive=LocalMachine /
task name=cl
attribute name=exename${path::combine(vsDevInstallDir, '../../vc7/bin/cl.exe')}/attribute
/task
task name=link
attribute name=exename${path::combine(vsDevInstallDir, '../../vc7/bin/link.exe')}/attribute
/task
[nant-dev] compiling .resx files is slow (patch included)
Title: compiling .resx files is slow (patch included) The automatic compilation of .resx resource files by the csc/ task is quite slow. We have several assemblies with many .resx files (40+ resx files) that get included as resources. It was taking 2-3 seconds per .resx file when compiling the assembly (you could see the output pause for 2-3 seconds as each was compiled into its .resource file). I did a quick experiment with directly compiling the .resx files into .resource files using the resgen/ task and the exact same fileset of 40+ files was compiled almost instantly! When I started looking at how the csc/ task was different, I noticed that it used a separate ResGenTask for each resx file in the resources fileset. We changed the CompilerBase class to use just one ResGetTask object to compile the full list of resources (analogous to how the resgen task itself does it). That change made a huge difference. The attached patch contains the change. With this change, our assembly that was taking 90+ seconds to compile now compiles in about 4 seconds. FasterResourceCompiling.patch Regards, Erv FasterResourceCompiling.patch Description: FasterResourceCompiling.patch
RE: [nant-dev] compiling .resx files is slow (patch included)
Aren't there command line limit conciderations with the resgen task itself? My point is that this is *really* fast: resgen resources include name=**/*.resx / /resources /resgen And this is *really* slow: csc sources include name=**/*.cs / /sources resources include name=**/*.resx / /resources /csc But perhaps what you're saying is that the resgen/ task shouldn't doing things in a single call to resgen anyway due to command line limitations :( Perhaps a middle ground where the resgen task makes multiple calls if the command lines gets large, but not go so far as calling resgen once per file. However, I'm not sure how easy that would be given the nature of the ExternalProgramBase class and how it handles ExecuteTask I understand that the assemblies need to be copied, but do they need to be copied over and over again (the list is the same for all of the files in the fileset, but in the old way the referenced assemblies are copied once for each .resx file instead of once per fileset). Yes, the patch works. We have been using it for 2 weeks in our build environment with multiple projects of different types (ASP.NET, Winforms, class libraries, etc). For whatever reason the object returned by resources.ResxFiles is actually a ResourceFileSet even thought he return type is FileSet. I didn't think it would be wise to change the return type of resources.ResxFiles (don't know who else might be using it) and I also was trying to avoid duplicating the logic of resources.ResxFiles in another function. That could be tweaked either way as needed. -Original Message- From: Gert Driesen [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 05, 2004 4:00 PM To: Erv Walter; Nant-Developers (E-Mail) Subject: Re: [nant-dev] compiling .resx files is slow (patch included) Erv, Resource compilation has indeed slowed down quite a lot, because we now copy the referenced assemblies and resgen.exe to a temp directory to allow resgen to resolve references to types in these assemblies. So the slow down does not (just) come from the fact that resgen is invoked multiple times ... Perhaps we can speed up this process by doing a quick scan of the resx file to see if it references types in third party assemblies, and skip the assembly copying in that case. The reason why we now invoke the resgen task for each resx file is to avoid running into command line limits not sure if we risk running into that limit with large projects (is the limit about 2kb ?). About your patch : are you sure it actually works ? Apparently you're casting a fileset (resources.ResxFiles) to a ResourceFileSet Gert - Original Message - From: Erv Walter [EMAIL PROTECTED] To: Nant-Developers (E-Mail) [EMAIL PROTECTED] Sent: Tuesday, October 05, 2004 8:54 PM Subject: [nant-dev] compiling .resx files is slow (patch included) The automatic compilation of .resx resource files by the csc/ task is quite slow. We have several assemblies with many .resx files (40+ resx files) that get included as resources. It was taking 2-3 seconds per .resx file when compiling the assembly (you could see the output pause for 2-3 seconds as each was compiled into its .resource file). I did a quick experiment with directly compiling the .resx files into .resource files using the resgen/ task and the exact same fileset of 40+ files was compiled almost instantly! When I started looking at how the csc/ task was different, I noticed that it used a separate ResGenTask for each resx file in the resources fileset. We changed the CompilerBase class to use just one ResGetTask object to compile the full list of resources (analogous to how the resgen task itself does it). That change made a huge difference. The attached patch contains the change. With this change, our assembly that was taking 90+ seconds to compile now compiles in about 4 seconds. FasterResourceCompiling.patch Regards, Erv --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
RE: [nant-dev] Console logging output
This actually breaks things also. We run Nant from within Visual Studio to do our builds. With the old way, VS.NET new how understand the errors from CSC and you could double click on them and VS would jump to the right spot for the error. This no longer works with the prefix in place. Can we at least get an option to turn this off? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ian MacLean Sent: Monday, August 09, 2004 9:08 PM To: Nant-Developers (E-Mail) Subject: [nant-dev] Console logging output Recent changes to the console logger mean that there is a task name prefix emitted for every line of output related to that task. So: [csc] Compiling 298 files to 'H:\svn\boo\build\Boo.Lang.Compiler.dll'. Boo.AntlrParser: [csc] Compiling 11 files to 'H:\svn\boo\build\Boo.AntlrParser.dll'. [csc] h:\svn\boo\src\Boo.AntlrParser\BooLexer.cs(299,11): warning CS0219: The variable '_token' is assigned but its value is never used [csc] h:\svn\boo\src\Boo.AntlrParser\BooLexer.cs(1887,4): warning CS0162: Unreachable code detected [csc] h:\svn\boo\src\Boo.AntlrParser\BooExpressionLexer.cs(250,11): warning CS0219: The variable '_token' is assigned but it value is never used [csc] h:\svn\boo\src\Boo.AntlrParser\BooExpressionLexer.cs(1213,4): warning CS0162: Unreachable code detected instead of : [csc] Compiling 298 files to 'H:\svn\boo\build\Boo.Lang.Compiler.dll'. Boo.AntlrParser: [csc] Compiling 11 files to 'H:\svn\boo\build\Boo.AntlrParser.dll'. h:\svn\boo\src\Boo.AntlrParser\BooLexer.cs(299,11): warning CS0219: The variable '_token' is assigned but its value is never used h:\svn\boo\src\Boo.AntlrParser\BooLexer.cs(1887,4): warning CS0162: Unreachable code detected h:\svn\boo\src\Boo.AntlrParser\BooExpressionLexer.cs(250,11): warning CS0219: The variable '_token' is assigned but it value is never used h:\svn\boo\src\Boo.AntlrParser\BooExpressionLexer.cs(1213,4): warning CS0162: Unreachable code detected I personally find the older behaviour clearer as you can see that each [csc] represents a single invocation of the [csc] task whereas now its difficult to determine how many time the task has been used. The fact that the additional lines of output are part of the same [csc] usage is made clear by the indenting. Wrapping of long lines makes this even worse as you get some lines starting with [csc] and some not. Thoughts ? Ian -- Ian MacLean, Developer, ActiveState, a division of Sophos http://www.ActiveState.com --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
RE: [nant-dev] Console logging output
Cool, thanks! -Original Message- From: Gert Driesen [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 25, 2004 3:56 PM To: Erv Walter; Nant-Developers (E-Mail) Subject: Re: [nant-dev] Console logging output Erv, You can use the -emacs command line option to accomplish this. Gert - Original Message - From: Erv Walter [EMAIL PROTECTED] To: Ian MacLean [EMAIL PROTECTED]; Nant-Developers (E-Mail) [EMAIL PROTECTED] Sent: Wednesday, August 25, 2004 10:24 PM Subject: RE: [nant-dev] Console logging output This actually breaks things also. We run Nant from within Visual Studio to do our builds. With the old way, VS.NET new how understand the errors from CSC and you could double click on them and VS would jump to the right spot for the error. This no longer works with the prefix in place. Can we at least get an option to turn this off? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ian MacLean Sent: Monday, August 09, 2004 9:08 PM To: Nant-Developers (E-Mail) Subject: [nant-dev] Console logging output Recent changes to the console logger mean that there is a task name prefix emitted for every line of output related to that task. So: [csc] Compiling 298 files to 'H:\svn\boo\build\Boo.Lang.Compiler.dll'. Boo.AntlrParser: [csc] Compiling 11 files to 'H:\svn\boo\build\Boo.AntlrParser.dll'. [csc] h:\svn\boo\src\Boo.AntlrParser\BooLexer.cs(299,11): warning CS0219: The variable '_token' is assigned but its value is never used [csc] h:\svn\boo\src\Boo.AntlrParser\BooLexer.cs(1887,4): warning CS0162: Unreachable code detected [csc] h:\svn\boo\src\Boo.AntlrParser\BooExpressionLexer.cs(250,11): warning CS0219: The variable '_token' is assigned but it value is never used [csc] h:\svn\boo\src\Boo.AntlrParser\BooExpressionLexer.cs(1213,4): warning CS0162: Unreachable code detected instead of : [csc] Compiling 298 files to 'H:\svn\boo\build\Boo.Lang.Compiler.dll'. Boo.AntlrParser: [csc] Compiling 11 files to 'H:\svn\boo\build\Boo.AntlrParser.dll'. h:\svn\boo\src\Boo.AntlrParser\BooLexer.cs(299,11): warning CS0219: The variable '_token' is assigned but its value is never used h:\svn\boo\src\Boo.AntlrParser\BooLexer.cs(1887,4): warning CS0162: Unreachable code detected h:\svn\boo\src\Boo.AntlrParser\BooExpressionLexer.cs(250,11): warning CS0219: The variable '_token' is assigned but it value is never used h:\svn\boo\src\Boo.AntlrParser\BooExpressionLexer.cs(1213,4): warning CS0162: Unreachable code detected I personally find the older behaviour clearer as you can see that each [csc] represents a single invocation of the [csc] task whereas now its difficult to determine how many time the task has been used. The fact that the additional lines of output are part of the same [csc] usage is made clear by the indenting. Wrapping of long lines makes this even worse as you get some lines starting with [csc] and some not. Thoughts ? Ian -- Ian MacLean, Developer, ActiveState, a division of Sophos http://www.ActiveState.com --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
[nant-dev] Nant Bug?
Title: Nant Bug? One of my team members sent me some details on a possible bug with resource handling. It was working in an old version of Nant and they are seeing the following problem when testing the latest RC. It seems that CompilerBase is trying to clean up compiled resource files when no such file exists: PROBLEM (MAYBE TO E-MAIL): There definitely does seem to be a problem when using the prefix parameter of a resourcefileset: resources prefix=xxx_X.resources. includes name=Handheld\xxx_X\resources\**\*.bmp/ /resources I also tried using the dynamicprefix parameter some too but it didnt work too well either (same issue with an error not being able to clean file it created). BACKGROUND: I take away the prefix=xxx_X.resources. and it compiles just fine but then our embedded images dont have the right namespace(s) anymore. Actually, this thing does compile successfully, but the whole NAnt build doesnt finish successfully, error below, and theres some new files left lying around. For example, if I have a file called Help.bmp in Handheld\xxx_X\resources\ before the build and use the resourcefileset above, it is correctly embeds the image and it is available in the assembly compiled (via GetManifestResourceStream(xxx_X.resources.Help.bmp)), but then there is a new file (xxx_X.resources.Help.bmp) left around in Handheld\xxx_X\resources\. NANT ERROR: NAnt 0.84 (Build 0.84.1435.0; net-1.0.win32; rc 1; 12/6/2003) Copyright (C) 2001-2003 Gerry Shaw http://nant.sourceforge.net BUILD FAILED INTERNAL ERROR System.UnauthorizedAccessException: Access to the path C:\EpicSource\EpicOnHand\src\Handheld\xxx-X\resources\xxx_X.reso urces.Help.bmp is denied. at System.IO.__Error.WinIOError(Int32 errorCode, String str) at System.IO.File.Delete(String path) at NAnt.DotNet.Tasks.CompilerBase.ExecuteTask() at NAnt.Core.Task.Execute() 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] Total time: 0.4 seconds. Press any key to continue . . .
RE: [nant-dev] Nant Bug?
Title: Nant Bug? Oops. Sorry for not following the list carefully enough J From: Gert Driesen [mailto:[EMAIL PROTECTED] Sent: Friday, December 12, 2003 10:29 AM To: Erv Walter; [EMAIL PROTECTED] Subject: Re: [nant-dev] Nant Bug? Erv, This issue has been reported before and will be fixed in the next rc. Gert - Original Message - From: Erv Walter To: [EMAIL PROTECTED] Sent: Friday, December 12, 2003 5:22 PM Subject: [nant-dev] Nant Bug? One of my team members sent me some details on a possible bug with resource handling. It was working in an old version of Nant and they are seeing the following problem when testing the latest RC. It seems that CompilerBase is trying to clean up compiled resource files when no such file exists: PROBLEM (MAYBE TO E-MAIL): There definitely does seem to be a problem when using the prefix parameter of a resourcefileset: resources prefix=xxx_X.resources. includes name=Handheld\xxx_X\resources\**\*.bmp/ /resources I also tried using the dynamicprefix parameter some too but it didnt work too well either (same issue with an error not being able to clean file it created). BACKGROUND: I take away the prefix=xxx_X.resources. and it compiles just fine but then our embedded images dont have the right namespace(s) anymore. Actually, this thing does compile successfully, but the whole NAnt build doesnt finish successfully, error below, and theres some new files left lying around. For example, if I have a file called Help.bmp in Handheld\xxx_X\resources\ before the build and use the resourcefileset above, it is correctly embeds the image and it is available in the assembly compiled (via GetManifestResourceStream(xxx_X.resources.Help.bmp)), but then there is a new file (xxx_X.resources.Help.bmp) left around in Handheld\xxx_X\resources\. NANT ERROR: NAnt 0.84 (Build 0.84.1435.0; net-1.0.win32; rc 1; 12/6/2003) Copyright (C) 2001-2003 Gerry Shaw http://nant.sourceforge.net BUILD FAILED INTERNAL ERROR System.UnauthorizedAccessException: Access to the path C:\EpicSource\EpicOnHand\src\Handheld\xxx-X\resources\xxx_X.reso urces.Help.bmp is denied. at System.IO.__Error.WinIOError(Int32 errorCode, String str) at System.IO.File.Delete(String path) at NAnt.DotNet.Tasks.CompilerBase.ExecuteTask() at NAnt.Core.Task.Execute() 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] Total time: 0.4 seconds. Press any key to continue . . .
RE: [nant-dev] touch task w/non-existant files
+1 for that idea. -Original Message- From: Matthew Mastracci [mailto:[EMAIL PROTECTED] Sent: Thursday, November 06, 2003 5:15 PM To: Nant-Developers (E-mail) Subject: [nant-dev] touch task w/non-existant files Should the touch task create a non-existant file? The documentation says that it corresponds to the unix touch command, but not in this respect. :) --- 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 --- 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] Editing .build files w/syntax hilighting in VS.NET
You can also set this by right-clicking on a .build file in a project
(add one to a project temporarily if you need to) and choosing Open
With... Choose HTML/XML Editor and click Set as Default.
-Original Message-
From: Matthew Mastracci [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 06, 2003 11:05 AM
To: Nant-Developers (E-mail); [EMAIL PROTECTED]
Subject: [nant-dev] Editing .build files w/syntax hilighting in VS.NET
I'm not sure if this was posted to these lists before, but this registry
modification with allow you to edit .build file with nice XML syntax
hiliting in VS.NET 2003.
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\7.1\Editors\{8281C57
2-2171-45AA-A642-7D8BC1662F1C}\Extensions]
build=dword:0027
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\7.1\Editors\{C76D83F
8-A489-11D0-8195-00A0C91BBEE3}\Extensions]
build=dword:0028
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\7.1\Languages\File
Extensions\.build]
@={58E975A0-F8FE-11D2-A6AE-00104BCC7269}
unused=HTML
---
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
---
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] Draco.NET invocation and locating assemblyreferenc es
Non interactive sessions typically don't have access to mapped drives. Since Draco is running as a service, it won't know about the R: drive mapping that you setup when you logged in interactively. Have you tried using a UNC path? (\\servername\sharename\path) Have you tried dynamically doing the drive mapping in your nant script (using the net use command) instead of depending on a permanent mapping? -- Erv Walter 608-271-9000 Different all twisty a of in maze are you, passages little -Original Message- From: Phil Knight [mailto:[EMAIL PROTECTED] Sent: Friday, October 17, 2003 5:16 AM To: 'Clayton Harbour '; 'Ivan Tarasov ' Cc: '[EMAIL PROTECTED] ' Subject: RE: [nant-dev] Draco.NET invocation and locating assemblyreferenc es Yes, putting the files on a local drive works fine. As I say, it actually works OK with a mapped drive so long as I invoke nant from the command line. It only fails if nant is invoked from the Draco service, even though that service is configured to run under my administrator logon id. One of the difficulties I'm having is I can't see where any access permissions are being violated that might give me a clue on how to go about fixing it. Nothing is showing up in the event logs for example. The build environment we're implementing is trying to follow the guidelines in the Microsoft Team development patterns and practices guide as closely as possible. The recommended approach outlined there is to reference outer system assemblies from the build server via a virtual drive letter that works across all development workstations and the build server. As such it's kind of vital for us that we find a solution to this one. Thanks to everyone who's replied so far, but has anyone got any more ideas? Even suggestions on how I might go about troubleshooting and tracking down the exact cause would be welcome. Once again I apologise for taking up space here with something that isn't strictly an issue with nant itself. It is an application of nant though :-) Phil -Original Message- From: Clayton Harbour To: Phil Knight; Ivan Tarasov Cc: [EMAIL PROTECTED] Sent: 15/10/2003 17:39 Subject: RE: [nant-dev] Draco.NET invocation and locating assemblyreferen ces Hi, You might find problems with security even though the drive/share is mapped. For instance at home I have a home drive mapped to my local hard drive. I am unable to execute programs due to security settings if I access programs using the mapped drive letter. I can however access the applications using the unmapped drive letter. Have you tried copying the files to a local drive? Clayton -Original Message- From: Phil Knight Sent: Wed 10/15/2003 7:35 AM To: 'Ivan Tarasov ' Cc: '[EMAIL PROTECTED]' Subject:RE: [nant-dev] Draco.NET invocation and locating assemblyreferen ces Hello Ivan, Thanks for the quick response. Unfortunately though I'd already tried your suggestion without success - in fact I was convinced that was going to be the answer as well. I've currently got the Draco service running under my own logon account (which also belongs to the admins group). I've remapped the R: drive locally using the subst command so everything is self-contained on the one machine, but whatever I seem to try the Draco invocation just won't pick up the referenced assembly. Phil -Original Message- From: Ivan Tarasov To: Phil Knight Sent: 15/10/2003 14:53 Subject: Re: [nant-dev] Draco.NET invocation and locating assembly references Hello Phil, I'm not sure if this is the real problem but it seems to me that it is the case: if you run draco as a service, it is run under LocalSystem account, thus it is not allowed to work with the network folders (even mapped, as I recall). Try to do the same thing on your local system, without mapping net folder, if it helps, then just create appropriate account for draco service PK I apologise in advance that what follows probably isn't 100% relevant to PK nant, but I'm really hopeful that someone here might be able to set me in PK the right direction and end hours of frustration. PK I've set up a basic build system using nant and Draco.NET which appears to PK be working well for simple solutions/projects. I've just started to test it PK out on more complicated projects and have hit a problem compiling projects PK that reference external dlls. I'm using the solution task to do the compile PK and the dlls in question reside on a shared network drive and are referenced PK via a drive mapping (R:) configured on every developer workstation. PK A simple nant build file to compile the project using the solution task PK works fine when executed from the command line, the problem starts when PK Draco launches the exact same build file, with nant reporting that it can't PK find the referenced assembly. PK I've included a copy of the simple build script that demonstrates the PK problem plus the output from the command line invocation
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
solution 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 solution 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:
nant buildfile=somefile inheritall=false target=sometarget
defines
property name=buildtarget value=${script.build.target} /
property name=copytarget value=${script.copy.target} /
/defines /nant
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
RE: [nant-dev] solution task fix
VS.NET uses the full name of the class (namespace.classnam) for the behind the
scenes .resx files (those resource files automatically created to hold WinForm
resources, etc.
If you create a .resx explicitly and add it to your project (for example, to hold
string resources for internationalization purposes), VS.NET will use the filename
prefixed with a namespace. The namespace will be a combination of your project's
default namespace and the filepath to the .resx file. So, if you have a file called
strings.resx in subdirectory 'Other' of a project with namespace 'Stuff', the resource
will be embedded as Stuff.Other.strings.resource.
So, parsing an associated .cs file is only sometimes appropriate (for the cases where
the .resx file was automatically created behind the scenes).
-Original Message-
From: Matthew Mastracci [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 17, 2003 9:50 AM
To: Vincent Labatut
Cc: [EMAIL PROTECTED]
Subject: Re: [nant-dev] solution task fix
Unfortunately, VS.NET uses the name of the class as the generated resources filename.
Changing this would break any designer-created code.
BTW, as a friendly suggestion. :) I can't read your mail from Sept. 9 because it
appears to be encoded in something other than text/plain. I get nant-users in digest
form, which means that I ignore any HTML/RTF mail that gets sent to it (not fun
reading through HTML tags, as you can probably imagine). For archival purposes, it is
highly recommended to send mail to the mailing list in text/plain format only. If
this is not possible, ensure that your mail client is at least sending this as backup
to text/html.
Matt.
Vincent Labatut wrote:
hi,
i think there's a problem in the way compiled resource filenames are computed in the
solution task. I had a collision which was failing my build (cf my mail to the nant
users list solution task - problem with resources on the 9th sept).
The filenames are computed by scanning the corresponding source files (cs or vb) to
each resx file, looking for a namespace and class with a regexp, maybe to find out a
unique name (namespace + classname should be unique). The problem is that the regexp
used aren't robust enough.
There is also in the code an alternative way of doing so : using the path of the file
as a unique name, and this seems to work well.
I can't figure out why this first manner is put forward in the code, it sounds like
making two many assumptions to me, whereas more robust algorithms exist.
may I suggest the following fix, it forces the alternative way. If adopted, 3
functions would need to be deleted as well (GetDependentResourceName and the like),
not included in this fix for clarity.
--- resource.cs Wed Sep 03 11:00:01 2003
+++ resource.cs Wed Sep 17 15:18:35 2003
@@ -225,9 +225,9 @@
string inFile = _resourceSourceFile;
string outFile;
-if (!StringUtils.IsNullOrEmpty(_dependentFile)) {
-outFile = GetDependentResourceName(_dependentFile);
-} else {
+// if (!StringUtils.IsNullOrEmpty(_dependentFile)) {
+//outFile = GetDependentResourceName(_dependentFile);
+// } else {
StringBuilder sb = new StringBuilder();
if
(!StringUtils.IsNullOrEmpty(Project.ProjectSettings.RootNamespace)) {
sb.Append(Project.ProjectSettings.RootNamespace);
@@ -240,7 +240,7 @@
}
sb.Append(.resources);
outFile = sb.ToString();
-}
+//}
outFile =
Project.ProjectSettings.GetTemporaryFilename(outFile);
_solutionTask.Project.Indent();
It does not prevent my project to have localized resource dlls (which BTW need
dedicated tasks).
N???X???'???u???)??Y?\?g??
?????b?H zG(?? ???u??^??X??X??v??zZ)z?%??l???q??
?z?mX???(?? ~??zw??X?b??u??^rs==
---
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
+,~wzf¢+,¦o$áyyézW(ëhæ¯zxm¶ÿ¶§ÊþÇçj{]z«²f¢)à+-©íuë^®Éb²Û,¢êÜyú+ém¦Ïÿ+-²Ê.¢¸ ë+-³ùb²~çj{]z«
RE: [nant-dev] servicecontroller task
Great Idea. I'd love to get a few more exec tasks out of my builds. My only suggestion would be to include a Restart action (which would be equivalent to Stop followed by Start with the appropriate waitforstatuses). -Original Message- From: Gert Driesen [mailto:[EMAIL PROTECTED] Sent: Sunday, September 07, 2003 3:50 AM To: Nant-Developers (E-Mail) Subject: [nant-dev] servicecontroller task Hi, I'm thinking about adding a task for stopping/starting/pausing/continueing a service, and at the same time waiting for it to reach a certain status. It would look something like this : servicecontroller service=iisadmin action=Start | Stop | Continue | Pause waitforstatus=Paused | Running | waittimeout=... / As the name suggests, I would use the servicecontroller task to implement this task, which should make it pretty straightforward. Ofcourse, this task will be win32-specific, and as such would be part of the NAnt.Win32 namespace and assembly. Any remarks, suggestions, ... ? Gert --- 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] Latest build not working?
This is the setup we use that allows Nant to handle all build duties from withing VS.NET and it supports debugging: http://nant.sourceforge.net/wiki/index.php/VSNETIntegrationViaMakefile -Original Message- From: Erick Thompson [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 03, 2003 1:41 PM To: Ian MacLean Cc: NAnt developers (E-mail) Subject: RE: [nant-dev] Latest build not working? Ian, I might be missing something, but I'm not seeing how I can debug from VS.NET while building with NAnt. Actually, I do see a way (attach to process), but it seems like a real hassle. Build, along with some pause code to give me time to time to attach, execute, attach debugger and work from there. Is would work, but it slow. Is there a better way that I'm not seeing? Thanks, Erick -Original Message- From: Ian MacLean [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 02, 2003 7:37 PM To: Erick Thompson Cc: NAnt developers (E-mail) Subject: Re: [nant-dev] Latest build not working? Erick, I'd prefer to change the nant vs projects to not build and just use the nant.build to build everything. You can still edit and debug from vs.net but maintaiing two build processes is a major PITA and doesn't gain you anything. Ian I think I've figured out why it isn't working, but not how to solve it. The projects that have a mix of copylocal=true and copylocal=false for references. If I close VS.NET and clean the output bin folder, the solution builds cleanly. If I don't, I get a file locked problem on the compile of NAnt.Core, which then causes problems everywhere else. I've tried setting all the copy locals to false, but there is still a conflict somewhere. Is there any particular reason why these are set to copy local? I've never had anything but problems using copylocal=true, and haven't found any advantage to it at all. Erick -Original Message- From: Erick Thompson Sent: Tuesday, September 02, 2003 12:08 PM To: NAnt developers (E-mail) Subject: [nant-dev] Latest build not working? I downloaded the August 31th build from nant.sourceforce.net/builds, and opened the sln file in VS.NET 2003. Everything opens correctly, but it doesn't seem to be building correctly. I'm getting a whole slew of missing reference errors, missing file errors, and a locking error. Should I be able to compile NAnt in VS.NET 2003 right out the zip? Thanks, Erick --- 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 --- 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] BUG: incorrect output of resgen
This used to be broken and was fixed. It sounds like a recent checkin
broke things again. The 1.27 revision of resgentask.cs broke things
(Mon Aug 18 11:58:18 2003 UTC (8 days, 6 hours ago) by drieseng).
GetOutputFile() depends on being able to tell if someone didn't pass in
todir. The change committed by Gert (perhaps on behalf of someone else)
makes it so that ToDirectory never returns null and defaults to the
project directory. This breaks resource filesets.
-Original Message-
From: Jaroslaw Kowalski [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 26, 2003 12:46 PM
To: NAnt Developers
Subject: [nant-dev] BUG: incorrect output of resgen
Hi all!
I have a problem with Nant built from CVS an hour ago. My build file
that
used to work with some older versions of Nant, fails when used with new
version.
The problem can be reduced to a simple *.build file
--
project
csc target=library output=aaa.dll
sources basedir=a
includes name=*.cs /
/sources
resources basedir=a prefix=zzz
includes name=*.resx /
/resources
/csc
/project
-
where c# sources are located in ${nant.project.basedir}\a directory.
They
can be as simple as a single file with the contents: public class A {
};.
There's also a *.resx file in the a directory (any resx file will do).
NAnt produces the following error message (full log is attached):
error CS1566: Error reading resource file 'x:\b\a\MainForm.resources'
At the same time a new file called MainForm.resources has appeared in
the
directory where my build file is located (but I think it should go to
a
directory instead).
I think that ResGen task (or its invocation) should be fixed to produce
the
*.resource file in a correct place, but I have no idea how to do it
myself.
Can you help me?
Jarek
---
This SF.net email is sponsored by: VM Ware
With VMware you can run multiple operating systems on a single machine.
WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines
at the same time. Free trial click here:http://www.vmware.com/wl/offer/358/0
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
RE: [nant-dev] FxCop RegSvcs Tasks
The biggest issue is exclusions. In a complex application, I guarentee that you'll have some FxCop violations that are false positives. Even Microsoft reminded us recently that FxCop is not omniscient and developers shouldn't be blindly fixing everything that FxCop complains about. When you use the GUI and do some exclusions (right click on a violation), the fact that you have excluded this violation is stored in the project file so that next time you run FxCop, you don't get harrassed about it. The other issue is just disabled rules. It's pretty common to want to use a rules assembly, but turn off a couple specific rules from that assembly. These are also stored in the project file. -Original Message- From: Arjen Poutsma [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 12, 2003 3:37 AM To: Gert Driesen; [EMAIL PROTECTED] Subject: RE: [nant-dev] FxCop RegSvcs Tasks Goedemorgen Gert ;-), I agree on the target attribute: it will be dropped. I'm not quite sure I understand what you mean regarding the FxCop task, though. Would you like the to use a template FxCop project, and modify it with the contents of the targets and rules filesets? I don't think that's a good solution, because it forces you to create a FxCop project, and I don't want to do that. However, I justed looked at the xml format of a .fxcop file, and it doesn't look that hard to build. In fact, it's so simple that I don't see the advantage of using a template file at all. Creating a (temporary) .fxcop project file does give the advantage of not having to specify the rules, though, since you use the default RuleFiles node, which contains GlobalizationRules.dll, ComRules.dll, UsageRules.dll, DesignRules.dll, PerformanceRules.dll, SecurityRules.dll and NamingRules.dll. The disadvantage of this approach is that you'r much more dependant on the file format. If the folks in Redmond suddenly decide to change the format, we're screwed. We could also add some attributes, which allow you to disable these seven default rules. Using it will then look something like this: fxcop targets basedir=bin includes name=**/*.dll / /targets /fxcop Which will use all seven default rules. fxcop globalization=false com=false targets basedir=bin includes name=**/*.dll / /targets /fxcop Which disables the GlobalizationRules.dll and ComRules.dll. You get the idea. fxcop targets basedir=bin includes name=**/*.dll / /targets rules basedir=c:\MyRulesDir includes name=**/*.dll / /rules /fxcop Which uses the rules found in c:\myrulesdir in addition to the seven defaults. fxcop usedefaultrules=false targets basedir=bin includes name=**/*.dll / /targets rules basedir=c:\MyRulesDir includes name=**/*.dll / /rules /fxcop Which uses the rules found in c:\myrulesdir in addition to the seven defaults. I could also add the feature of providing just a .fxcop project file, like so: fxcop project=myProject.fxcop/ But I don't think we can combine this with any of the attributes described above. Do these changes make it more useful? Best, Arjen -Original Message- From: Gert Driesen [mailto:[EMAIL PROTECTED] Sent: Monday, August 11, 2003 9:42 PM To: Arjen Poutsma; [EMAIL PROTECTED] Subject: Re: [nant-dev] FxCop RegSvcs Tasks Hi Arjen, Good to see someone finally took the time to implement these tasks, great work However, I'm not sure the FxCop task is very useful as you've implemented it, but I could be wrong ofcourse ... I think we could actually start from an existing FxCop project file as it doesn't make sense to apply all rules to an assembly, and consider it a failure when it doesn't pass all those rules. I had thought about implementing the FxCop task as a task that supports a fileset for the targets (like you did) and a fileset for (custom) rule files, and have it just generate the Targets and RuleFiles nodes in a copy of the specified FxCop project file. That way you have the power of the fxcop project without having any hard coded paths in the FxCop project. We could also support the types option, but I don't think its really necessary if we require a FxCop project file anyway. If we support the types option then we could support it using a nested types build element. I think we can also remove the target attribute and only support the fileset. For the regsvcs task I would prefer to always explicitly specify the action, even for the install/create action. Ofcourse these are all just personal suggestions/remarks, and by no means I want to sound ungrateful for the work you've done. Keep up the good work ! Gert --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and
RE: [nant-dev] Solution/Project Parser
I'm not sure I understand your proposed change. Can you clarify? There are 2 camps (and now possibly a third). The difference between the camps is personal preference, really. Onecamp is the group of people who find dually managing build files and project/solution files undesirable (a completely valid point of view). This group of people would want the solution task to be as magic as possible since the idea is that the .sln and it's referenced project files contain all the pieces of information needed to correctly build stuff. Are you suggesting that things should be somehow broken out more from that end user's point of view? Again, I could use some clarification on exactly what you're proposing and what it would make build files look like (sorry for being slow on the uptake). For the record, I'm in the camp that prefers the clean, explicit nature of NAnt build files using csc and related tasks directly. I think that the VS.NET solutions and projects are messy, poorly designed by Microsoft, and unmanageable in large team development situations. I have daily CVS conflicts with the .csproj files I use to the point that we're considering removing them from CVS completely and making them personal tools only. We already have removed the .sln files from CVS. We have since configured VS.NET to use NAnt to build anyway, so the .csproj files have become little more than the holders of file listsand no longer the holder of build settings. From: Yves Reynhout [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 22, 2003 5:02 PMTo: [EMAIL PROTECTED]Subject: [nant-dev] Solution/Project Parser Hi, I've been following (though I should admit not very actively using) NAnt for a while now (about 1200 nant posts in my inbox). Especially, not being able to handle the VS.NET "solution" concept was something that bothered me (well, let me rephrase: not handled elegantly). Ofcourse, it all depends on your focal point, meaning if you don't use VS.NET, you probably couldn't care less about the "solution" concept. And then it was Matthew Mastracci I believe (correct me if I'm wrong) that introduced the solution task into NAnt. Unfortunatly, I'm not quiet happy with its current implementation, because there's no clear separation between the "solution/project" as data (the content of the .sln and .*prj files)and the "solution" task itself. The current implementation provides an object model for its current purpose, namely the"solution" task. Wouldn't it be more usefull to buildupon a common representation (read object model) of the VS.NET solutions andprojectsand re-use that representation in (for now) the solution task. Maybe there are otheruses for the commonrepresentation (read other tasks) of the VS.NET solutions/projects. In an attempt to fill what I feel is a void I started work on a VS.NET Project and Solution Parser/Object model. My question to the NAnt team, and probably Matthew Mastracci in particular, if they are interested in this parser (which is in no way finished). I realize thiscould cause refactoring in the area of the "solution" task and since NAnt will come out with releases on a more regular basis, I'll let you guys be the judge of what I proposed. To Matthew Mastracci I'd like to say: "Thank you for bringing the 'solution' task to the table.".
RE: [nant-dev] Solution/Project Parser
It's probably clear, but did forget to mention that to use this, you add this project to your solution and then configure your solution to turn off building for all projects except this one. The benefit from my perspective (a minor one) over the External Tool approach that some people use is that the existing Build / Rebuild functions continue to work for the solution and that build errors show up in the normal build errors task list instead of only in the Output window. -Original Message- From: Erv Walter [mailto:[EMAIL PROTECTED] Sent: Thursday, July 24, 2003 11:56 AM To: Tomas Restrepo; [EMAIL PROTECTED] Subject: RE: [nant-dev] Solution/Project Parser In the event that this is useful to others, I have attached the project we use to make VS.NET 2003 integrate with NAnt. It's a VS.Net 2003 C++ Makefile project. The way it works is that you can configure a makefile project to call whatever command you want to do the actual build. Interestingly, you will still get good VS.NET integration for any build errors. This is because NAnt uses csc.exe to do the build and VS.NET apparently understands how to parse the csc.exe error output. In order to get debugging to work (for a windows exe or console app), you will need to hand tweak 2 settings in the NantBuilder project properties. On the debugging tab, you need to set these: Command: $(SolutionDir)build\YourOutput.exe Working Directory: $(SolutionDir)\build\ For some stupid reason, these will be stored for you in the .suo file (which is why you have to do them yourself). Obviously, replace YourOutput.exe with whatever the name of your debugable executable is. For all of the above, you may need to make some adjustments based on how you have NAnt configured to build. The above depends on: - Nant.exe being in Tools\NAnt subdirectory of your solution (a convention that we use internally) - default.build being in your solution directory - build, rebuild, and clean targets in your default.build directory - all of your build output going into a build\ subdirectory of your solution If you have a different NAnt setup, you'll need to adjust the project accordingly. You also might be able to set something up similar in VS.NET 2002, but I have never tried. Maybe I'll see if I can figure out how a Wiki works and then add this information there. Enjoy, Erv -Original Message- From: Tomas Restrepo [mailto:[EMAIL PROTECTED] Sent: Thursday, July 24, 2003 11:32 AM To: [EMAIL PROTECTED] Subject: Re: [nant-dev] Solution/Project Parser Matthew, I'm also getting close to wanting to use NAnt completely within the build process. We do this for our project. We actually went a little bit further,and we actually have a single VS.NET solution and project that *never* get built, it's just for intellisense and the vs.net VSS integration ;) Every developer (the main dev team has about 8 people) builds directly with nant everytime (one of my coworkers came up with the idea to add a custom tool to vs.net that fires nant for the project and puts the nant output in the vs.net output window. nifty!). No problems with this setup, really. The project is not too bit, though, consisting of about 20 dlls or so, and 200.000+ lines of code, with a fairly complex build and install process (for gac and COM+ registration). -- Tomas Restrepo [EMAIL PROTECTED] --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01 /01 ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
RE: [nant-dev] Solution/Project Parser
That makes things much more clear for me, and it sounds like a great idea. From: Yves Reynhout [mailto:[EMAIL PROTECTED] Sent: Thursday, July 24, 2003 4:35 PMTo: [EMAIL PROTECTED]Subject: Re: [nant-dev] Solution/Project Parser From reading the response posts I think I didn't make myself quiet clear. First of all what I'm suggesting is only of interest (I think) for the VS.NET solution/project camp. I have not found a library yet that allows me to parse VS.NET solution (.sln) and/or project (.csproj) files, and get an object model back from the parser. What is in that object model?Well, possibly everything you can find out about a solution or project via the related files (.sln/.csproj). How could this affect the solution task? For starters it wouldn't have to do the parsing of the solution/project filesitself. Secondly, as a consequence, the parsing code wouldn't be mingled with what the solutiontask actually does. The object model could also provide for a task that e.g. extracts the files included in a project andupdates a nant build file's csc task, essentially a partial one-way sync of the build file and the VS.NET solution/project.Another use could be to build VS.NET solution/project files via the object model (essentially letting "something" else be the master of files, references, interproject dependencies, etc...), which could maybe resolve your CVS problem - conflicts in .csproj files due to teamdev -you[Erv Walter] mention. Allowing the object model to save, in addition to the parsing, could provide valuable in this case. So to resume, I'm talking about buildinga VS.NET solution/project parser and object model (along the lines of what the VS.NET IDE extensibility object"DTE" offers right now), and integrating that with the solution task.
RE: Project Structure Ideas (Was: RE: [Nant-users] Re: [nant-dev] Building Projects With NAnt)
We do something similar except our master build file explicitly calls
the sub build files in the correct order. There is some elegance to the
idea of adding a subproject without having to modify an existing build
file. That doesn't work for us, and it doesn't work in general when you
have cross-subproject dependencies.
Our directory layout is not quite as hierachical as the example (there
is only one level of directories for subprojects). From the top level
source directory, there are several subdirectories--one for each
assembly. At first we were using the foreach technique shown in your
example except that the subdirectories actually need to be processed in
non-alphabetic order. Say we have subprojects A, B, and C. Because A
and C both reference the class library being built in B, we have to
build B first and then A and C.
The only way we've come up with to do that is for the master build file
to directly nant into B, then A and C.
What would be nice is if there was some way of this being automatically
determined. It is theoretically possible for some algorithm to notice
the fact that the csc task in A's project has a references to the
file created as output in the csc task of B.
Anyway, it's not a huge issue for us right now. For now we have half a
dozen assemblies with simple dependencies. However, we're just one
small development team in the company. Currently the company has 100+
COM DLLs. If someday we migrate our applications to .NET and look at
NAnt, the dependencies of those 100+ assemblies (assuming we don't
combine a lot more than we do now) will be a bit difficult to manage by
hand.
Even if we can't find an elegant solution where NAnt figures it out
itself, I have though about writing an app that traverses all of our
slave build files and building a dependency map that could be used to
generate a correct build order for a master build file to read from a
file.
Anyway, enough of my pipe dreams...
-Original Message-
From: Giuseppe Greco [mailto:[EMAIL PROTECTED]
Sent: Friday, June 27, 2003 5:54 PM
To: Jaroslaw Kowalski; NAnt Developers
Cc: NAnt Users
Jaroslaw,
First of all, thank you for your feedback! I've really appreciated it.
On Fri, 2003-06-27 at 23:55, Jaroslaw Kowalski wrote:
I think it's a good idea to promote good build system design and I
think
that your document is a step in the right direction.
I like the idea of being able to treat all subprojects in a generic
way. You
use gateway build files for that purpose, but I think that this kind
of
functionality should be directly supported with NAnt, so you don't
need to
resort to this kind of hack.
I think, one should be able to invoke nant like this (or with some
other
syntax):
nant target=${target}
buildfiles
includes ... /
/buildfiles
/nant
This would be nice... but it is not implemented yet.
The main advantage of gateway build files, is that you can add
new subprojects without having to modify any build file.
This can be even used with recently added named filesets feature.
You
would define a (single) fileset that would keep all your *.build files
and
invoke various targets on it using simple one-liner without the need
of a
gateway file trick.
I don't remember the exact syntax for named filesets, but the concept
is:
fileset id=childrenBuildFiles
includes file=**/*.build /
/fileset
target name=build
nant target=build fileset=childrenBuildFiles /
/target
Yes, the syntax is correct. I'll introduce an example ASAP -- fileset
references are available since last Tuesday...
This would make your *.build files MUCH more readable, and simplicity
and
readability is (imho) the most iportant part of a build system.
What do you think?
I think we could discuss all together how to continue the development
of this document; as soon as I'll publish the DocBook source files,
anybody will be able to enhance it...
Gius_.
Jarek
- Original Message -
From: Giuseppe Greco [EMAIL PROTECTED]
To: NAnt Developers [EMAIL PROTECTED]; NAnt
Users
[EMAIL PROTECTED]
Sent: Friday, June 27, 2003 10:29 PM
Subject: [nant-dev] Building Projects With NAnt
Hi all,
Since I've decided to adopt NAnt as the standard build
tool here at ::agamura::, I've written a document titled
Building Projects With NAnt...
It is available at http://developer.agamura.com/technotes
either in PDF or HTML format -- DocBook source files will
be available soon.
May be it could be helpful for those who are new to NAnt...
It covers NAnt basics and introduces how projects should
be structured.
Any comment, suggestion, or critic is welcome!
Gius_.
--
Giuseppe Greco
::agamura::
phone: +41 (0)91 604 67 65
mobile: +41 (0)76 390 60 32
email: [EMAIL PROTECTED]
web:www.agamura.com
RE: Upcoming 0.8.4? release (was RE: [nant-dev] FW: Upcoming 0.8.3 release)
One common practice (recommend by Microsoft gurus) is to increment your version number immediately _after_ a release, not right before a release. This means that you have plenty of time to debug any issues related to that version number change. I assume that's why the version is 0.8.3 in CVS right now. It was probably changed shortly after 0.8.2 was released and if we want to follow the same pattern, we should change it to 0.8.4 shortly after the next release. Anyway, I don't think the specific version number matters. What is more important is that we come up with a consistent process that is understandable so that people know what to expect. Heck, until NAnt is 1.0, anything goes, right? :) -Original Message- From: John Barstow [mailto:[EMAIL PROTECTED] Sent: Thursday, June 26, 2003 9:07 PM To: 'Erv Walter'; [EMAIL PROTECTED] Erv Walter wrote: It seems kind of odd to suggest that the next version of NAnt should be 0.8.4, doesn't it? The newest release version is 0.8.2, why are we skipping 0.8.3? It's mainly because the CVS version has been marked as 0.8.3 for quite some time now, and it would be clearer to increment to 0.8.4 for a release. If support is not a concern, we can release it as 0.8.3. and let the chips fall where they may. N.V. wrote: Not everything built with framework 1.1 will work with framework 1.0, because a lot of thing have been added to framework 1.1, it's more like everything built with 1.0 will run with 1.1, and even then, i'm not sure There have been forward and backward breaking changes in 1.1. The fact is that the majority of assemblies are not affected; for those that are, the release notes document workarounds for the breaking changes. But the important thing is that we test any change like this before committing them. --- This SF.Net email is sponsored by: INetU Attention Web Developers Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
RE: [nant-dev] BUG?: includes ... frompath=true /
I guess my point is this: If nant is compile with and running under the 1.0 .NET framework (which it does by default if you have both frameworks installed), and If I specify my project should built with the 1.1 .NET framework, and if the referenced file is not found in the 1.1 .NET framework path, using a file from the 1.0 .NET Framework path is *never* a correct choice. That would mean that some of my reference go to 1.0 assemblies and some to 1.1 assemblies. That is a recipe for a broken application. If I reference System.Xml.dll without a specific path and if I'm compiling with current framework set to 1.1, the only correct place to find System.Xml.dll is the 1.1 framework path. That's what you get when you do asis=true. -Original Message- From: Clayton Harbour [mailto:[EMAIL PROTECTED] Sent: Friday, June 13, 2003 2:21 PM To: Erv Walter; [EMAIL PROTECTED] I might be a bit wrong on this (and if I am please correct me) but the way I understand it the nant framework path is the path being used to run nant. I think this can be seperate from the framework you specify to compile your project with the csc task. Is this correct? Blazing ahead under this assumption, the csc task would then be looking at the closest setting (the project/ build file level). If nothing is found at this level then look at the version of .net that nant is running with, if that falls through (not sure if it ever would...) then check the system path. The reason for the second stop is to give a little more control of which framework is being used (i.e. it is not left up to order in the path variable). I do not think this would ever fall through (unless it is possible to hack the default framework out of the nant.exe.config and still have it work...have not tried that) but if it does the backup would then be to use whatever is in your path variable. Does this make sense? Clayton -Original Message- From: Erv Walter Sent: Fri 6/13/2003 11:28 AM To: [EMAIL PROTECTED] Cc: Subject:RE: [nant-dev] BUG?: includes ... frompath=true / I'm confused on why you would ever want to find a reference in Current nant framework path as listed below? The only time that an assembly would be in the nant framework path and not in the current framework path is when the located assembly is of the wrong version!? -Original Message- From: Clayton Harbour [mailto:[EMAIL PROTECTED] On Behalf Of Clayton Harbour Sent: Friday, June 13, 2003 1:36 PM To: Ian MacLean; Jaroslaw Kowalski Cc: [EMAIL PROTECTED] Hi, I think it would be more intuitive to search in the following manner: - Current project framework path - Current nant framework path - Path system variable - blow up! Is this what you are suggesting Ian? Clayton -Original Message- From: Ian MacLean Sent: Fri 6/13/2003 7:45 AM To: Jaroslaw Kowalski Cc: [EMAIL PROTECTED] Subject:Re: [nant-dev] BUG?: includes ... frompath=true / not really - although a bit confusing. The frompath is working as expected assuming that Framework\v1.0.3705 is the first one in the path. When you specify asis it passes the bare file name to csc and so the 1.1 csc will find System.Data.dll using its own search heuristics. There was talk a little while back of making references framework aware. However the problem is if you specify a bare filename ( eg System.Data.dll ) how does the csc task know whether its a system dll to be resolved by currentframeworkpath or whether you expect to find it on the path. I guess if there is not frompath and no asis we can try it as a framework path and if it exists pass that to the compiler. Just thinking aloud - any ideas welcome. Ian I have two frameworks (net-1.0 and net-1.1) installed. I have a csc task that includes a reference to csc includes name=System.Data.dll frompath=true / When i compile with net-1.1 it passes the following (incorrect) option to the csc.exe compiler. /reference:C:\WINNT\Microsoft.NET\Framework\v1.0.3705\System.Data.dll instead of: /reference:C:\WINNT\Microsoft.NET\Framework\v1.1.4322\System.Data.dll When I do: includes name=System.Data.dll asis=true / it works, because csc finds the correct version of System.Data.dll by itself. Is it a bug? Jarek --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Nant-developers mailing list [EMAIL PROTECTED
