[nant-dev] Linux story
I just wanted to document the experience I had with nant on my linux box. In the end it was a partial success but there were a few things I didn't figure out right away and it may be good to have them documented here. Day one, load linux in a dual boot with Windows 2003. My previous install wouldn't boot after loading Windows and adding a hard drive so I reinstalled. the install added a partition, and then Windows wouldn't boot again. Note to manufacturers, take over this whole boot loader, device map thing. Day two - Tried getting the release version of nant to run. No go of course so I tried to do a build, but alas you can't build unless you can run nant. Bootstrap? Dug up in the lists a reference to the make, and viola, there it is. It didn't work, and saving the trouble of typing the reasons, there was a newer makefile in cvs. It didn't work so on to the nightly build. The nightly failed as well. - cp -R bin/lib/* . Now make started humming along. It made it through the bootstap build, but then failed at different points. mcs couldn't find some of the support dlls. In order they were log4net, nunit.framework and NDoc.Core. In each case, to get further down the compilation path, I copied them to the mono lib directory, /usr/lib in my case. Clearly that was a hack, but perhaps the build will have to reference these differently to succeed. Finally though, I did have build. I tried running the tests. They began to execute, but then got stuck in a 100% CPU loop and had to be killed. I tried letting it run about 25 minutes just in case mono was that slow, but eventually gave up. One part (sorry can't remember the section) passed, the first call in the test target, so that would mean nunit was loaded correctly. Note that this version of nunit was from the nightly download. My goal was to compile the data access helper I am working on, SnapDAL on linux using NAnt. First problem, no solution task. I didn't look into the internals to see how it worked, but somehow I thought that the solution task wouldn't have been dependent on win32 but I see it's excluded from the mono build. Ok, no problem build a normal csc compile task. It worked! I played around for a couple of hours and got MySql setup with a very small part of the Northwind test database I use in the SnapDAL tests. I got as far as one working query, and one dying an a input parameter with spaces in it that caused a sql syntax error. Probably not a big deal to fix and not important here. In the end, I'd say progress! I had run linux as my default desktop for about a year and a half. Last fall, I had a day where I had compiled one library just one too many times, loaded windows 2003, and hadn't looked back. Now I would say mono has really come a long way, and that nant and SnapDAL (which also means .net mock objects), the platform might just be interesting again. My platform was Suse 8.2, mono .31 installed from the Suse 9.0 mono rpm. This is interesting especially after that last round of Microsoft patches cause my cluster to fail and had me down during business hours for the longest time since I joined my current company. 2 1/2 hours down. Cheers and keep up the good work. = Philip - http://blogs.xcskiwinn.org/panmanphil There's a difference between righteous anger and just being crabby - Barbara --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] Expansion of properties in target descriptions
--- Scott Hernandez [EMAIL PROTECTED] wrote: The projecthelp uses xsl templates to transform the source document (build file) without doing any includes (or actually running any tasks; like property/). This makes it pretty useless in many cases. At this point I think we need to re-write the projecthelp stuff to load the document, run (the include/ tasks only?) global tasks, and then provide help about the build file. I've already done this for my command line replacement gui, except for the include target descriptions. What I have observed is that the need for the xslt is removed, as you are generally interested in a list of targets, and then of those, the descriptions of just some of them. Quite often on larger builds with lots of targets, you may be interested in only those targets with descriptions, or targets that don't start with an _, or some other way of filtering the list. In a point and click gui, this is a much easier way to explore the build file than trying to read a full formatted document. The expansion of properties is a good question. In my properties grid, I show the unexpanded value, and I *think* this is what people would want. If a property is in the description, I think the opposite may be true. From the execution point of view you may want to see all expanded values, but if the gui is hosting an editor, you may want to leave the expansion off. I think the best answer is to expose some non instance code that takes a string with property templates, and the property collection and returns the string with the templates expanded. --- 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] FYI
--- Damir Simunic [EMAIL PROTECTED] wrote: Since there is so much interest in this msbuild thing, here's the list of namespaces Microsoft.Build.BuildEngine The book they handed out with the PDC alpha bits, Introducing Longhorn for Developers, Brent Rector, Microsoft Press, has a fairly unflattering description of NAnt in it. Some of the points are probably just wrong, but others are not. In particular, he describes how msbuild tasks can access each other through a formal input and output description and how this is required in Longhorn projects. He also describes projects the include declarations from multiple files. No time to type the whole thing, but it may be difficult to try and support that full syntax, and as a result the whole solution task. More enquiring minds will have to analyze it. --- 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] NAnt and Ant (was: Ready to tackle next release)
Well, to be honest : I don't have a clue ... That's perhaps why we're still stuck with the GPL license :-) I am pretty sure the copyright holder can do whatever they want, so long as they aren't bound to the gpl by other source code or libraries in the application. NAnt may be bound to the gpl because of things like the sharpcvslib. There's also the issue of source code that may have been copied. Does anybody know where all the source comes from? I did have a quick look at the licensing stuff, and to me it seems like a BSD-style license is the most open license ... I would summarize it as do want you want with this code, and you can't sue me with an unwritten correlary of I don't want your crummy enhancements to my code. It is definately my preference to use BSD or Apache licenses. --- 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: [nant-dev] NAnt Designer Support
Reason: One of the most common complaints I hear about NAnt is that its too hard to use, even though it oozes power and flexibility. A lot of people run with Visual Build from Kinook (another fine product), but I think some kind of designer support would give NAnt the edge. Yeah, Alex Lowe wrote a column essentially saying just that, ironically in an argument for why .net needs a new build system. On the other hand, one of the great features of both nant and it's predecesor, ant, was that task writers have an easy time of it writing new tasks. But, building an designer interface, applicable to any sort of task, especially trying to accomplish that across platforms, is not a trivial effort. I've also been studying this. I have seen a few different approaches, NAntPad included. And honestly, none of them excites me at all. Let's say we could accomplish this with the core tasks, itself a challenge. Would any tool that was to expose the designer then have to have a text based interface for those task that didn't support the designer? How would that work? I noticed recently a reference to a previous conclusion that the task properties were probably not enough to build a designer themselves, which leads to your conclusion that each task writer should support a designer. I've come to the conclusion that a text interface makes more sense for editing build files. But, it should be a much better text interface than notepad. I've just started playing with the text editor in SharpDevelop, using example code from a nifty little tool called SqlBuddy. SqlBuddy provides intellisense sytle help for sql editing, and I think nant files could benefit from the same thing with the help of properties, a code snippet with all required fields, and a schema from the task builder. I think we can assume that almost everyone that creates a build file is a developer or system administrator type for whom text interfaces are not unfamiliar. And we all are happy with good editors that provide lots of context sensitive help, searching, designers that generate some of the code and provide intuitive navigation and feedback. For me, this would be preferable. As for those that may *use* a build file, as opposed to edt it, a tool I have been working on makes that part really easy. Hopefully, I'll get my updated version past the vaporware stage in the next couple of weeks. I took a detour to try and really understand windows forms and docking a lot better, but I'm close to something useful. --- 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] Questions about Project class
That's what it looked like but I wanted to make sure that it wasn't just unfinished business. I'll proceed with the idea or working from the xml directly, thanks. --- Ian MacLean [EMAIL PROTECTED] wrote: Philip, the Nant project class and others are not designed to be DOM like. Many elements are only created just before execution and then thrown away. This is to ensure that when a task or build element is initialized it has the correct ( up to date values). I can appreciate that having a DOM like project object would help with your app but that is not the purpose of the current NAnt Project class. Ian --- 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] nant include task
--- Haltunen, Mathew [EMAIL PROTECTED] wrote: Hello all, I've used ant in the past, but now I am using nant to build .NET applications. I am running into a problem handling dependencies. Here's the break down. The dependencies that are handled with the pre.build target are built and placed in the directory where this nant script is executed (the .\bin directory). The problem occurs when the build target includes the dlls that are created by the pre.build target. The name spaces in the pre.build dlls are not recognized in the include task in the build target. Has anyone seen this before? Any help is much appreciated. Are the pre.build dlls there when you're done? This is most likely a path problem because the fact the pre.build task runs first means that the dlls should be there. As a test you could just verify the dlls are there and run the main build separately. --- 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
Re: [nant-dev] COM visibility
I'll offer one counter point of view to using NAnt from COM. I had started, but lost the motivation to complete, a task to have NAnt tasks callable from a DTS package. It's entirely possible that building this functionality would require no COM visibility, ie the implementation just has the name of a build file and a target, but my first stab at it was more than that. I lost motivation because DTS runs on database servers which in my world have to be gaurded against every possible unneeded CPU cycle. --- Gert Driesen [EMAIL PROTECTED] wrote: My post was not about having a solution for a problem, I just think it's best to have a clear message about what we support and what we don't support ... And not explicitly marking an assembly as being COM visible or not just leaves users in the dark as to if using NAnt through COM is supported or not ... I agree that we shouldn't modify our classes to allow usage from COM... I would prefer marking all assemblies as not COM visible ... If (and only if) you agree, I'll send in a patch which sets the COMVisible attribute to false for all NAnt assemblies. Thanks, Gert - Original Message - From: Ian MacLean [EMAIL PROTECTED] To: Gert Driesen [EMAIL PROTECTED] Cc: Nant-Developers (E-mail) [EMAIL PROTECTED] Sent: Thursday, April 03, 2003 1:32 AM Subject: Re: [nant-dev] COM visibility It works both ways. If you feel that there is no demand for using NAnt from COM then there is no need to specifically allow or dissallow access. We don't mark them COM visible right now - we just don't mark them invisible. This seems like a non issue to me. My view of the com visible attribute is that its used for when you are explicitly designing your library to be used from COM and want to provide a clean interface by hiding those types that you don't want to pass across the COM boundary. You say we should make a decision - well I don't think that we should modify our classes specifically to allow usage from COM ( ie ensure that there are default constructors ) unless there is demand for that and I don't think there is. So you feel its necessary to explicitly mark everything invisible feel free to send a patch. It seems like a solution without a problem to me but thats just me. Ian Hi, Should all NAnt assembly (and all clasess within these assemblies) continue to be marked COM visible ? Is there really a demand for using NAnt as an COM object ? Has anyone ever tried to use NAnt as a COM component ? If so, for what purpose ? Currently, there are lots of classes that are not usable at all in a COM context because they : - have no default public constructor - have static methods What's the use of making, for example, the NAnt.Win32Tasks assembly visible to COM clients ? In my opinion, we should make a decision on this matter. Personally, I think it's of no use to actually mark the assemblies COM visible if they're not really usable as COM components, and if we're not planning on doing anything to support this. What do you think about this ? Gert --- This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ ___ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers --- This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ ___ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] original exception is discarded
while in fact we could add more infomation to that error message by adding the Message of the innerexception, eg. you bet! --- This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ ___ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
RE: [nant-dev] [Nant-users] How to use nunit2 task (resend)
Can you run the NUnit gui correctly? Is it installed under Program Files or somewhere else? Have you tried setting the assembly reference in your test project to the assembly in the NAnt/bin directory? It almost has to be mismatched dlls. --- Anthony Francisco [EMAIL PROTECTED] wrote: Actually that was the first thing that I checked. The only file with the same filename that I could find between my nant\bin and nunit\bin directories was nunit.framework.dll. Doing a binary file compare between the two files indicated a perfect match. - Ants | -Original Message- | From: Matthew Mastracci [mailto:[EMAIL PROTECTED] | Sent: Friday, 28 March, 2003 07:59 | To: Anthony Francisco | Cc: [EMAIL PROTECTED]; | [EMAIL PROTECTED] | Subject: Re: [nant-dev] [Nant-users] How to use nunit2 task (resend) | | | Make sure that you're using the same version of NUnit for | linking your | test assemblies that NAnt uses. You'll get this error if there is a | mismatch. I'm not sure what we can do to fix the issue of linking | against the wrong NUnit, but I'm guessing that this is what | the problem is. | | Anthony Francisco wrote: | | I getting a crash in NAnt when trying to use the nunit2 task. | | I tried using the nunit2 task using the following in my | build script: | | target name=test depends=build description=Runs NUnit tests |nunit2 | test assemblyname=Reveal.exe / |/nunit2 | /target | The result I get is: | INTERNAL ERROR | System.IO.FileLoadException: Unable to load file 'nunit.framework'. | File name: nunit.framework | | Server stack trace: | at System.Reflection.Assembly.nLoad(AssemblyName fileName, String | codeBase, B | oolean isStringized, Evidence assemblySecurity, Boolean | throwOnFileNotFound, Ass | embly locationHint, StackCrawlMark stackMark) | at System.Reflection.Assembly.InternalLoad(AssemblyName | assemblyRef, Boolean | stringized, Evidence assemblySecurity, StackCrawlMark stackMark) | at System.Reflection.Assembly.InternalLoad(String | assemblyString, | Evidence as | semblySecurity, StackCrawlMark stackMark) | at System.Activator.CreateInstance(String assemblyName, String | typeName, Bool | ean ignoreCase, BindingFlags bindingAttr, Binder binder, Object[] | args, CultureI | nfo culture, Object[] activationAttributes, Evidence securityInfo, | StackCrawlMar | k stackMark) | at System.Activator.CreateInstance(String assemblyName, String | typeName, Bool | ean ignoreCase, BindingFlags bindingAttr, Binder binder, Object[] | args, CultureI | nfo culture, Object[] activationAttributes, Evidence securityInfo) | at System.AppDomain.CreateInstance(String assemblyName, String | typeName, Bool | ean ignoreCase, BindingFlags bindingAttr, Binder binder, Object[] | args, CultureI | nfo culture, Object[] activationAttributes, Evidence | securityAttributes) | at | | System.Runtime.Remoting.Messaging.StackBuilderSink.PrivateProc | essMessage(M | ethodBase mb, Object[] args, Object server, Int32 | methodPtr, Boolean | fExecuteInC | ontext, Object[] outArgs) | at | | System.Runtime.Remoting.Messaging.StackBuilderSink.SyncProcess | Message(IMes | sage msg, Int32 methodPtr, Boolean fExecuteInContext) | | Exception rethrown at [0]: | at | | System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage( | IMessage req | Msg, IMessage retMsg) | at | | System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(Messag | eData msgDa | ta, Int32 type) | at System.AppDomain.CreateInstance(String assemblyName, String | typeName, Bool | ean ignoreCase, BindingFlags bindingAttr, Binder binder, Object[] | args, CultureI | nfo culture, Object[] activationAttributes, Evidence | securityAttributes) | at | | SourceForge.NAnt.Tasks.NUnit2.NUnit2TestDomain.CreateTestRunne | r(AppDomain | domain) | at SourceForge.NAnt.Tasks.NUnit2.NUnit2TestDomain.Run(String | assemblyFile, St | ring configFilePath, EventListener listener) | at | | SourceForge.NAnt.Tasks.NUnit2.NUnit2Task.RunRemoteTest(NUnit2T | est test, Ev | entListener listener) | at SourceForge.NAnt.Tasks.NUnit2.NUnit2Task.ExecuteTask() | at SourceForge.NAnt.Task.Execute() | at SourceForge.NAnt.Target.Execute() | at SourceForge.NAnt.Project.Execute(String targetName) | at SourceForge.NAnt.Project.Execute() | at SourceForge.NAnt.Project.Run() | | Fusion log follows: | | Please send bug report to [EMAIL PROTECTED] | mailto:[EMAIL PROTECTED] | Try 'nant -help' for more information | I can run nunit-console just fine from the command-line, but NAnt | seems unable to be crashing. | | Is there anything special I need to do to my NT CMD shell ? | | - Ants | | --- This SF.net
Re: [nant-dev] NAnt.Win32Tasks
--- Ian MacLean [EMAIL PROTECTED] wrote: I've created a new NAnt.Win32Tasks assembly to hold win32 specific stuff. I've moved those tasks that fail to compile on linux in there to start with so that I can move forward with getting NAnt building on with mono/linux. Obviously compile on linux doesn't mean run on linux - the ReadRegistry task suprisingly built fine on mono/linux - it seems they've stubbed out the registry classes - but it fails at runtime. That one gets delegated to wine I think. It *could* work as expected if you 1 - have wine setup with a version that matches the mono build and 2 - setup a registry in wine that ms programs would use. --- 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] SharpZipLib bug (was: Problem installing Nant0.8.01)
(BTW, was curious if any NAntians are using #Develop rather than Studio to work on NAnt. Anyone?) I use it when I work at home but aren't booted in linux where I use gvim ;-) --- This SF.net email is sponsored by: Tablet PC. Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en ___ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
[nant-dev] Nant/Linux tale to tell
Actually, nothing to report with Nant except that the tedious process of building the gnome libraries and all supporting packages on my older suse linux system, did finally get me to the point of running a gui debugger on NAnt. And the result? I stepped into an infinite loop. Same thing with the command line debugger. Same thing with a 5 line hello world type program, though I could step until I accessed a system dll. So, I am left with the question I posed back awhile. To debug, I have to either wait until the debugger stabilizes, or go to something like log4net where I can assert debug statements (that could be turned off later with a config file change). If I were to go that way, I would prefer that the using log4net statements and the logger setup stay in the code. Ideally, some rationale and best practices for leaving logging assertions in the libraries would be useful too for later debugging purposes. But, there would have to be some agreement on style etc. so it didn't turn into chaos. Any thoughts? --- This SF.net email is sponsored by: Tablet PC. Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en ___ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] bug in recursive source compile using '**/*.cs' ?
What seems to happen is that the top level directory is ignored or identified as an invalid URI if I attempt to compile my sources from the same directory as my build file. I have the following code: sources basedir= includes name=**/*.cs/ /sources A basedir of the current directory should be indicated as .. **/*.cs means all .cs files in any subdirectory of the current directory so that wouldn't get the files in the current directory. Instead: sources basedir=. includes name=*.cs / includes name=**/*.cs/ /sources --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] NAnt on Linux findings (some) and questions (more)
Then, get rid of any classes that have using Win32 in them. Unfortunately I just added using Win32 to project.cs to support the multiple runtimes. I want to come up with a way to partition this so that the registry access stuff is skipped on a non-windows build. Maybe thru use of #ifdef. Anyone have a better way to do this ? If I ever get the debugger compiled, I was intending to look into this further. I suggested dropping those files that had using Win32 from the build just to get going under linux, but hopefully, that wouldn't have to be an absolute rule. It is my understanding that certain parts of Mono are implemented using the wine libraries. Not all systems will have this installed or installed and configured, like mine was. Of course any .net compiled libraries that used PInvoke may hit kernel32.dll by themselves, but the original set of wine libraries had a version of kernel32.dll and this is why Brian saw that error most likely. The current versions of wine delegate everything to a single shared library and emulate the win32 calls by some sort of configuration. They also emulate the Registry but that must be setup to work correctly. I am going to guess that it will be possible to say using Win32 without wine and without error, but I don't know what the limitations are yet. My next couple of free time sessions are going to be spent rebuilding my linux system so that I have more source packages, now that I finally figured out the connection between tarballs (.tar.gz), source rpms, spec files and packages, so I'll be a few days from any more work on NAnt. Hopefully after that I can hit this hard again. As for the using Win32 in project.cs, I'd say leave it there for now until me or somebody else can look into this a little more. --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] proposal : change to if task behaviour
propertyexists is false when the property does NOT exist OR the property is false sounds dangerous to me. Some operation x is supposed run or not, presumably based on a carefully considered condition. If I forget to set it, I may get unexpected results. --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] Mono Support
And Philip... I'm curious as to the environment you got mono NAnt to run in. Cygwin, or the real deal in linux? Suse Linux 8.0, shell script for the initial build, GVim text editor --- 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] Mono Support
--- Ian MacLean [EMAIL PROTECTED] wrote: Which is why the mcs task should go and we use the same csc task for both. The stuff i'm working on with loading settings from the confiog will allow this. Ie if you set the current runtime to be mono - it will know to call mcs.exe instead of csc.exe Makes sense to me as long as there aren't unique mcs features somebody wants to call. While your at it VolumeInfo.cs is going to be a problem under linux. My problems with wine (a quasi mswin32 api compatibility layer for linux that allows certain windows program to operate on a linux box) were actually triggered by the VolumeInfo.IsCaseSensitive call which cascades off to a bunch of dllimport supported methods. There is still a problem with Mono and wine, but if we're lucky we can avoid the problem altogether with NAnt by not requiring win32 api calls at all, at least under linux/mono. I got NAnt.Core, NAnt.exe and NAnt.DotNetTasks (partially) compiled last night. I still have a problem with parsing the uri with -buildfile to work through and the figuring what I missed with the ProjectHelp.xslt resource file. Hopefully, this weekend I can get to the NUnit tests and run them from the NAnt build file. --- 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] Mono Support
Trying to compile nant under mono. What I originally thought was an xml short fall is actually a reflection shortfall: element has more than one match for attribute_type Anyway, the problem occurs trying to compile McsTask (and other times using Mono with .net compiled assemblies). McsTask inherits from CompilerBase which depends on ResgenTask which inherits from MsftSDKExternalProgramBase.cs which uses the Registry. Can I assume that the registry won't be supported under Mono? --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] Mono Support
hmm - well that registry code will be removed shortly. Its just to get the SDKFramework path I think. exactly. Can I assume that the registry won't be supported under Mono? I would have thought not. Considering its in the Microsoft.Win32 namespace. And it definately won't be available on linux. out of interest are you using mono on windows or linux ? Linux, suse 8.0, just installed the .20 release of mono. I got NAnt.Core and NAnt.exe compiled, only removing the Script task. NAnt.exe runs but still can't get through a build file without errors. I still need to check my version of wine because some of the errors are related to missing libkernel32, which of course is not missing. --- 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
[nant-dev] patched NAntExplorer
A few people wrote about a bug that happens if you load a project without first selecting a build file. Thanks! This version just dims the load button until a file is selected. Amazing I never did that in over 8 months of use ;-) I included only the .exe and source. To use, you will have to copy NAnt.Core.dll and most likely NAnt.DotNetTasks.dll to the bin directory where you unpack it. Of course any other task or support dlls needed by your build would have to go as well. NAntExplorer.zip Description: NAntExplorer.zip
RE: [nant-dev] Mono Support
--- Brian Deacon [EMAIL PROTECTED] wrote: Just wanted to pipe up and say that I personally am really interested in hearing any gotchas and resolutions in getting nant and mono to play nice with each other. So thanks, Philip. Yeah, I had pretty much set aside my interest in Mono until NAnt was working. I don't care for makefiles and NAnt seems like a good reality check on how far Mono has come. Doesn't require windows forms, asp.net, ado.net, but still exercizes a good portion of standard functionality. So, we'll see where this goes... --- 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] Mono Support
--- Scott Hernandez [EMAIL PROTECTED] wrote: I would like to see NAnt run on Mono. Does anyone want to volunteer to be the point man on this? For the next major release I'd like to see us provide a Mono distribution. What parts of NAnt? I had gotten NAnt.exe to partially run with the last release of Mono but there are serious parts missing, particularly in Xml support that could make this difficult at this time. And how do you account for core tasks that would never run on Mono, if at all? --- This SF.net email is sponsored by: Scholarships for Techies! Can't afford IT training? All 2003 ictp students receive scholarships. Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. www.ictp.com/training/sourceforge.asp ___ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] Mono Support
--- Scott Hernandez [EMAIL PROTECTED] wrote: Those are good questions. My goal would be to get things working well enough so that the mono team feels confident is using NAnt to do their builds. That at least may be an easier first goal. The MCS task and possibly some other file utilities? Mono is pretty big though and as I recall, the mono developers are happy with their existing build system, so that would possibly take some doing. I'll take a look tonight possibly. For tasks that will never run on mono we should separate them from the core. We should build separate assemblies for the tasks that require Win32 functionality. The other option is to use a compiler flag to strip out code that will not compile on mono. It can get a little dirty, but we will need to figure some strategy out. I think we are all open to suggestions. :) There's also the issue of linux vs win32 that's separate from mono vs .net. Would it make more sense to separate mono specific tasks into one dll and linux specific tasks, if any, into another? Core - works anywhere a compliant clr is working Win32 - only windows supported tasks, including csc and vbc Mono - mcs, mono and related tasks Linux - only linux supported tasks if any. Would anybody on the mono team likely volunteer for this? --- This SF.net email is sponsored by: Scholarships for Techies! Can't afford IT training? All 2003 ictp students receive scholarships. Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. www.ictp.com/training/sourceforge.asp ___ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
RE: [nant-dev] Mono Support
(from memory) mcs syntax and command line parameters are fairly different than csc so, if you are a developer familiar with mono, you won't know the correct syntax for the parameters if they are done in a csc sort of way. Plus, the compilers don't support exactly the same set of features, so to put the options all in one would force nant to have the least common denominator. Off hand, I would think that if mcs and csc both support references and filesets, with excludes, it would be easier to allow the developer to specify the compiler. FWIW, the ide's that support mono, SharpDevelop(does it?) and Eclipse(which uses Ant) with a plugin, have you specify the compiler. --- Shaw, Gerry [EMAIL PROTECTED] wrote: In an effort to one up people I'm going to try to get nant working under mono on my iBook (OS X). My vision is for the core nant distribution to work on any .NET platform with platform specific tasks in different dll's. I think a global property should control what compiler the csc task uses. For example, property name=csc.program value=/usr/local/bin/mcs/ property name=csc.style value=Mono/ property name=csc.program value=C:\windows\Microsoft.NET\Framework\v1.0.3705\csc/ property name=csc.style value=Microsoft/ property name=csc.program value=??/ property name=csc.style value=DotGnu/ By default the csc task should work out of the box (ie, MS on Windows, Mono on Linux) but there should be a clean way to override the compiler. --- This SF.net email is sponsored by: Scholarships for Techies! Can't afford IT training? All 2003 ictp students receive scholarships. Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. www.ictp.com/training/sourceforge.asp ___ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
[nant-dev] contribution to project
I have a fairly low tech, but useful winforms app I wrote that I would like to contribute to the project. It's a gui for NAnt, but unlike the nant gui for vs-studio, this is an alternative to the command line for NAnt build files. I call it NAnt Explorer and here are it's features (and not much more!) - add/remove a build file into a saved list of build files. These lists are serialized to a config file as new entries are loaded. - click on a build file and it's targets show in another list - click on a target, and if available, the target description from the build file is displayed - execute any target from the selected build file - display target results in a scrolling text box - optionally select the verbose option for the target My purpose in writing this was to encourage my developers who have nasty knee jerk reactions and facial ticks whenever they encounter a command line to use this wonderful NAnt tool, and it worked! Of course I am their boss so that may have been a factor. I use NAnt for software builds and deployments from developer machines to dev/qa/prod machines and having this tool on the server desktops makes access to the tasks a few clicks shorter. What do you tbink? Any interest? --- 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
