RE: [Draconet-users] Question about NAnt integration and compiling C# code
> -Original Message- [snip] > Anyone have any ideas on how to get around this. When I build I need to > register and unregister on my development machine but it is not absolutely > necessary on the continious integration machine although . It doesn't > have > a problem with the 'ProjectDir', 'OutDir' or 'TargetPath' macros. I'm not > for sure how to approach this. I can delete the pre and post build event > and just run the bat files manually but I really don't want to do that > because I'm lazy. :) [snip] The SolutionTask is one of my hobby horses. It's been broken since the day before they invented it. I don't use it; I won't use it. In the unlikely event that me doing Monty Python doesn't cause you to "Run away! Run away!" from the SolutionTask, I'll tell you that I use CscTask to compile all of our assemblies and maintain a very simple inclusion list of source as part of each build script, etc. Here's why: In a spurt of optimism about six months ago, I briefly experimented with using xsl and simple string operations to manipulate the sln and csproj files so that the wacky SolutionTask would work on them as Local projects instead of Web projects, because SolutionTask was horribly broken with respect to Web projects. I then decided that it was easier to just convert them all to Local projects instead of Web projects 100% of the time instead... Which is how we develop our web apps now; much nicer than before, so some good did come of it. But then something else in SolutionTask broke for me which is too painful to recall, and I gave up again on the SolutionTask... [Don't even think about trying to use ExecTask to call devenv.exe directly. That's even worse than trying to use SolutionTask, if you can believe it.] The SolutionTask is the one reason that I'm looking forward to MSBuild. Because SolutionTask offends me. ;) NAnt with CscTask does me just fine right now, but I find the whole exercise of trying to reinvent devenv.exe to be wasteful, counterproductive and well, nevermind - I'll keep it professional. :) Of course, I'm emotionally preparing myself to be woefully disappointed by MSBuild (as with any version 1 M$ product). Here are some options. You could: 1. Dive into the NAnt code and implement the unimplemented macro. 2. Strip the offending line(s) out at run time (what effect this will have on build success, I don't know). 3. Switch to using csc to build your assemblies. 4. Ask the NAnt developers to hurry up already. :P In the event that this post wasn't helpful, at least you have my sympathies. And I feel better. I may not even need that extra therapy session this week. Heh. --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ Draconet-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/draconet-users
RE: [Draconet-users] Question about NAnt integration and compiling C# code
David, Thanks for the feedback. I have settled on doing a sandbox build. My confusion below came when I was trying to set nant.exe to debug mode (ie. when I supplied a path to it with the -debug+ on the end) At first I was inserting the ':' symbol between the debug keyword and its value '-debug:+' which the path core runtime was puking on. Then I realized the error of my ways and removed the ':' symbol. Draco promptly told me that it couldn't find the path to nant. Dang can't set nant to debug. Download the source change the argument builder to pass in a debug argument and compile it. Unregister the release version of the service, register the debug version of the service, set log in user on the service and start it. Attached VS.NET to it's process and set a break point. Manually run the project through the website controller and it promptly jumps to the set break point and I can debug. Found out I was being really stupid and had the 'aha' slap my forehead method, fixed my problem (notice I am skirting around it here because I don't want to embarass myself. :) ). Stop and unregister debug version of the service, reregister and start release version. All is hunky dory now, it's starts building. Find out I have somethings in the solution that nant is puking on, go back to debug version to get more verbose info about them in the log file. It seems that I had a resx file that was making it puke. Deleted the resx, view the control in VS again, which recreated it, checked everything back in. All is fine. The problem I am having now is for running pre and post event builds that are defined in on the project level. I used the DevEnvDir macro and some relative paths tacked to it that point to the .NET framework tools directory so that I can run installutil to unregister and register a remoting service that nant is not liking. It tells me the following: NAnt.Core.BuildException: Unexpected error while compiling project 'Service' ---> System.NotImplementedException: "DevEnvDir" macro is not yet implemented. Anyone have any ideas on how to get around this. When I build I need to register and unregister on my development machine but it is not absolutely necessary on the continious integration machine although . It doesn't have a problem with the 'ProjectDir', 'OutDir' or 'TargetPath' macros. I'm not for sure how to approach this. I can delete the pre and post build event and just run the bat files manually but I really don't want to do that because I'm lazy. :) Any (more) help would be appreciated, John From: "David Reed" <[EMAIL PROTECTED]> Reply-To: [EMAIL PROTECTED] To: <[EMAIL PROTECTED]> Subject: RE: [Draconet-users] Question about NAnt integration and compiling C# code Date: Thu, 9 Dec 2004 10:37:50 -0600 John, You're bumping into the same confusion I did when I first got started. As I've grokked the subject, you've got two options (which you've already figured out): 1. Store the build files with the source and use relative paths in your build file to reference resources; this allows you to use the "clean room" checkout method that Draco already does for you to a virgin location for every build. + This is good because it is what Draco expects you to do. + This is good if you like to have a 100% fresh build every time. + This is good for smoke tests. - This is bad if you care about your debug symbols and the paths to source contained therein. 2. Store the build file somewhere else and manage the checkout of source yourself using NAnt tasks to a location that you know and love (duplicative effort, because Draco's already checked it out for you to an imaginary location with a really scary file path) and use fully qualified paths for all your resources in the build file so that it doesn't matter where the build file is run from. + This is good if you're a masochist. + This is good if you're paranoid and don't trust "developers" to maintain the build script. + This is good if you care about your debug symbols and the paths to source contained therein. - This is bad if you have high concurrency, because many simultaneous runs of the same builds will step on each other and ugly things happen. (I don't know if Draco prevents simultaneous runs of the same build yet or not.) [The biggest concurrency problems that I had were the previous version of NDoc -- which they fixed -- and database changes (such as new sprocs) -- which is a logical flaw in the SQL scripts and has to be re-fixed every time a "developer" writes an unrepeatable transaction or doesn't pre-test changes carefully.] ** Having fought with both methods in the past 18 months, I feel your pain. :) I'm using #1 for CI builds to the sandbox servers. To solve the debug symbols problem on the integration servers, there are scheduled builds using well-known file locations where we check out source to and issue the same build logic with different target servers. What we've long been missing is a sn
RE: [Draconet-users] problems svn and Visual Studio
[EMAIL PROTECTED] wrote: > Hi, > I might miss something but I didn't get Draco to run svn together > with Visual Studio 2003. > In the first place svn (is in the path and I can it execute from the > command prompt) didn't get executed. > The only error message I got in the log output that a file was not > found. svn.exe may be in the PATH for the interactive user(you), but that doesn't necessarily mean it's in the path for Draco. The Draco service runs under the LOCALSYSTEM account, which may or may not have the same environment as you. Ensure that svn.exe is in the System path, not just that of the current user. -- Arild AnkhSVN, Subverting Visual Studio .NET: http://ankhsvn.tigris.org Blog: http://ankhsvn.com/blog IRC: irc://irc.freenode.net/ankhsvn "Gentlemen, you can't fight in here! This is the war room!" --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ Draconet-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/draconet-users
RE: [Draconet-users] Question about NAnt integration and compiling C# code
John, You're bumping into the same confusion I did when I first got started. As I've grokked the subject, you've got two options (which you've already figured out): 1. Store the build files with the source and use relative paths in your build file to reference resources; this allows you to use the "clean room" checkout method that Draco already does for you to a virgin location for every build. + This is good because it is what Draco expects you to do. + This is good if you like to have a 100% fresh build every time. + This is good for smoke tests. - This is bad if you care about your debug symbols and the paths to source contained therein. 2. Store the build file somewhere else and manage the checkout of source yourself using NAnt tasks to a location that you know and love (duplicative effort, because Draco's already checked it out for you to an imaginary location with a really scary file path) and use fully qualified paths for all your resources in the build file so that it doesn't matter where the build file is run from. + This is good if you're a masochist. + This is good if you're paranoid and don't trust "developers" to maintain the build script. + This is good if you care about your debug symbols and the paths to source contained therein. - This is bad if you have high concurrency, because many simultaneous runs of the same builds will step on each other and ugly things happen. (I don't know if Draco prevents simultaneous runs of the same build yet or not.) [The biggest concurrency problems that I had were the previous version of NDoc -- which they fixed -- and database changes (such as new sprocs) -- which is a logical flaw in the SQL scripts and has to be re-fixed every time a "developer" writes an unrepeatable transaction or doesn't pre-test changes carefully.] ** Having fought with both methods in the past 18 months, I feel your pain. :) I'm using #1 for CI builds to the sandbox servers. To solve the debug symbols problem on the integration servers, there are scheduled builds using well-known file locations where we check out source to and issue the same build logic with different target servers. What we've long been missing is a snifty HOWTO document with some CI theory and examples to expand on what's in default build config file... It's on my wish list to contribute, but I won't have time until mid-1Q05 to even breathe, let alone actually do something fun. :) > -Original Message- > From: [EMAIL PROTECTED] [mailto:draconet-users- > [EMAIL PROTECTED] On Behalf Of John Sheppard > Sent: Thursday, December 09, 2004 10:13 AM > To: [EMAIL PROTECTED] > Subject: [Draconet-users] Question about NAnt integration and compiling C# > code > > Hi all, >I am having a problem getting Draco to run my NAnt build file. The > polling and checkout of source works as expected with one caveat. I have > to > designate an '$' character in front of my VSS path for it to poll and > check > my solution. I thought I could do a '\x\y\z' type of path but instead I > have to do a '$\x\y\z' style path in order for it to work. > > Here are the details (specifics changed to protect the innocent). > > I have set NAnt to debug to try to get a better handle on the failure. > Here > are the details of my project config: > > Source > 600 > 3600 > 60 > mail.yourdomain.com > [EMAIL PROTECTED] > > > true > Tropicos2 > 600 > 600 > 600 > > > d:\BuildTools\AutomatedBuilds\Tropicos > true > > > > master.build > > > $/MOBOT/Tropicos2/Tropicos > username > password > \\UNCEncoded path\VSS > > > > > Notice the path to the build file. When I set this to an absolute path > where I was storing my master.build file Draco would do a cd /d into that > directory then run the nant.exe with the correct parameters passed. NAnt > would fail because it couldn't find my solution file in the directory that > draco had cd'd into. So I changed my build file to be included in my > solution files and when my project is checked out the build file is > checked > out into the base directory of my solution. My solution is three levels > deep in my source safe structure so my project is checked out as follows: > > D:\BuildTools\Draco.NET Service\Source\ProjectName-TempID\Path to my > source > safe project (in this case '$\MOBOT\Tropicos2\Tropicos'. This is where > the > directory structure for the project is created with both the solution file > and build file at this level. I am thinking all is as it should be. VSS > checks all the files out, builds the directory structure then NAnt is > called > and here is where it is throwing an error. The error is: 'The given > path's > format is not supported.'. I assumed that it would 'cd /d' into the root > directory for my solution and try to find the build file there and run it. > This evedently is not the
[Draconet-users] Question about NAnt integration and compiling C# code
Hi all, I am having a problem getting Draco to run my NAnt build file. The polling and checkout of source works as expected with one caveat. I have to designate an '$' character in front of my VSS path for it to poll and check my solution. I thought I could do a '\x\y\z' type of path but instead I have to do a '$\x\y\z' style path in order for it to work. Here are the details (specifics changed to protect the innocent). I have set NAnt to debug to try to get a better handle on the failure. Here are the details of my project config: Source 600 3600 60 mail.yourdomain.com [EMAIL PROTECTED] true Tropicos2 600 600 600 d:\BuildTools\AutomatedBuilds\Tropicos true master.build $/MOBOT/Tropicos2/Tropicos username password \\UNCEncoded path\VSS Notice the path to the build file. When I set this to an absolute path where I was storing my master.build file Draco would do a cd /d into that directory then run the nant.exe with the correct parameters passed. NAnt would fail because it couldn't find my solution file in the directory that draco had cd'd into. So I changed my build file to be included in my solution files and when my project is checked out the build file is checked out into the base directory of my solution. My solution is three levels deep in my source safe structure so my project is checked out as follows: D:\BuildTools\Draco.NET Service\Source\ProjectName-TempID\Path to my source safe project (in this case '$\MOBOT\Tropicos2\Tropicos'. This is where the directory structure for the project is created with both the solution file and build file at this level. I am thinking all is as it should be. VSS checks all the files out, builds the directory structure then NAnt is called and here is where it is throwing an error. The error is: 'The given path's format is not supported.'. I assumed that it would 'cd /d' into the root directory for my solution and try to find the build file there and run it. This evedently is not the case. Any help that you may be able to give would be greatly appreciated. Thanks, John Sheppard The specific error I get is: ERROR Draco.Core.Runtime.BuildRunner - Failed to process build 'Tropicos2'. The following exception occurred: System.NotSupportedException: The given path's format is not supported. at System.Security.Util.StringExpressionSet.CanonicalizePath(String path, Boolean needFullPath) at System.Security.Util.StringExpressionSet.AddExpressions(String[] str, Boolean checkForDuplicates, Boolean needFullPath) at System.Security.Permissions.FileIOPermission.AddPathList(FileIOPermissionAccess access, String[] pathListOrig, Boolean checkForDuplicates, Boolean needFullPath, Boolean copyPathList) at System.Security.Permissions.FileIOPermission..ctor(FileIOPermissionAccess access, String[] pathList, Boolean checkForDuplicates, Boolean needFullPath) at System.IO.Path.GetFullPath(String path) at Draco.Core.Tool.NAntBuildTool.Execute(String baseDirectory) at Draco.Core.Runtime.BuildRunner.BuildModule(BuildResult results) at Draco.Core.Runtime.BuildRunner.Start(BuildType buildType) Exception: System.NotSupportedException Message: The given path's format is not supported. Source: mscorlib at System.Security.Util.StringExpressionSet.CanonicalizePath(String path, Boolean needFullPath) at System.Security.Util.StringExpressionSet.AddExpressions(String[] str, Boolean checkForDuplicates, Boolean needFullPath) at System.Security.Permissions.FileIOPermission.AddPathList(FileIOPermissionAccess access, String[] pathListOrig, Boolean checkForDuplicates, Boolean needFullPath, Boolean copyPathList) at System.Security.Permissions.FileIOPermission..ctor(FileIOPermissionAccess access, String[] pathList, Boolean checkForDuplicates, Boolean needFullPath) at System.IO.Path.GetFullPath(String path) at Draco.Core.Tool.NAntBuildTool.Execute(String baseDirectory) at Draco.Core.Runtime.BuildRunner.BuildModule(BuildResult results) at Draco.Core.Runtime.BuildRunner.Start(BuildType buildType) --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ Draconet-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/draconet-users
