Re: [nant-dev] need VS 2005 solution task support
Martin Aliger wrote: I don't think we need to make solution task compatibility a goal here. I was thinking same, but first I wanted to use msbuild, I found myself in situation where solution is used today. Even that msbuild is quite general system, we, nant users, will call it mainly to compile vs2005 solutions. So I rethink it, and it makes some sense to me. Creating a solution on the fly is not something we should support, as you need to make a bunch of assumptions anyway (dependencies, platform, ...). In fact, this was first issue I come around, when writing msbuild wrapper task. Thats why I rethinked implementation. If you find more appropriate, we could make msbuild task as direct wrapper and make another task,say vs2005 or msbuild-solution, which could do those additional wrapping. This sounds like a good compromise. msbuild gives you full control of the msbuild commandline while msbuild-solution provides a nice upgrade path for vs2003 solution task users. Good think about this on-the-fly solution creation is, that msbuild imply dependences and project compile order from it. Exacly what our solution do when we fed it with project fileset. Sure - there are assumption, but I beleive they could be made configurable where appropriate. so it sounds like there is definately a place for solution like functionality in an msbuild wrapping task. About namespace/packaging: would it be ok to add it to NAntContrib first, and move it to NAnt once it has stabilized ? This is our policy for all new tasks. np. I do not use NAntContrib currently, but no problems with relocating to another project. It is quite stand-alone task (depending on just ExternalProgramBase). Putting it NAntContrib first is the correct policy decision but I suspect we'll have some demand to move it into main fairly soon - vs2005 support for solution has been one of the most requested features. Thanks for starting this Martin - I'm sure there will be many happy solution task users. Ian --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click ___ nant-developers mailing list nant-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] need VS 2005 solution task support
-Original Message- From: Ian MacLean [mailto:[EMAIL PROTECTED] Sent: Friday, December 9, 2005 09:06 AM To: 'Martin Aliger' Cc: ''Gert Driesen'', ''Gert Driesen'', ''! nant'' Subject: Re: [nant-dev] need VS 2005 solution task support Martin Aliger wrote: I don't think we need to make solution task compatibility a goal here. I was thinking same, but first I wanted to use msbuild, I found myself in situation where solution is used today. Even that msbuild is quite general system, we, nant users, will call it mainly to compile vs2005 solutions. So I rethink it, and it makes some sense to me. Creating a solution on the fly is not something we should support, as you need to make a bunch of assumptions anyway (dependencies, platform, ...). In fact, this was first issue I come around, when writing msbuild wrapper task. Thats why I rethinked implementation. If you find more appropriate, we could make msbuild task as direct wrapper and make another task,say vs2005 or msbuild-solution, which could do those additional wrapping. This sounds like a good compromise. msbuild gives you full control of the msbuild commandline while msbuild-solution provides a nice upgrade path for vs2003 solution task users. Yes, I agree that this is the right thing to do. Good think about this on-the-fly solution creation is, that msbuild imply dependences and project compile order from it. Exacly what our solution do when we fed it with project fileset. Sure - there are assumption, but I beleive they could be made configurable where appropriate. so it sounds like there is definately a place for solution like functionality in an msbuild wrapping task. About namespace/packaging: would it be ok to add it to NAntContrib first, and move it to NAnt once it has stabilized ? This is our policy for all new tasks. np. I do not use NAntContrib currently, but no problems with relocating to another project. It is quite stand-alone task (depending on just ExternalProgramBase). Putting it NAntContrib first is the correct policy decision but I suspect we'll have some demand to move it into main fairly soon - vs2005 support for solution has been one of the most requested features. I think the pure msbuild wrapper task should more easily (rapidly) find its way to NAnt, as its built upon a stable command line interface. If you look at the features requested by users of the current solution task, the msbuild-based solution task might actually be better off in NAntContrib as it allows more custom tailoring (and you'll find less resistance to breaking changes) while tasks in NAnt should be more stable and only contain generally useful features. Note: I'm not saying the msbuild-based solution task is not generally useful. Thanks for starting this Martin - I'm sure there will be many happy solution task users. Definitely agree with this ! Gert --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37alloc_id865op=click ___ nant-developers mailing list nant-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nant-developers
RE: [nant-dev] need VS 2005 solution task support
Hi, I don't think we need to make solution task compatibility a goal here. I was thinking same, but first I wanted to use msbuild, I found myself in situation where solution is used today. Even that msbuild is quite general system, we, nant users, will call it mainly to compile vs2005 solutions. So I rethink it, and it makes some sense to me. Creating a solution on the fly is not something we should support, as you need to make a bunch of assumptions anyway (dependencies, platform, ...). In fact, this was first issue I come around, when writing msbuild wrapper task. Thats why I rethinked implementation. If you find more appropriate, we could make msbuild task as direct wrapper and make another task,say vs2005 or msbuild-solution, which could do those additional wrapping. Good think about this on-the-fly solution creation is, that msbuild imply dependences and project compile order from it. Exacly what our solution do when we fed it with project fileset. Sure - there are assumption, but I beleive they could be made configurable where appropriate. We should start it off as a simple wrapper for MSBuild.exe. I think it should be closer to the nant task than the solution task. I think we should add support for : - properties (nested element with collection, similar to nant task) arg is already present. To add property just write arg/p:name=value/arg No problem to add something more similar to nant task though. - target(s) (string attribute or nested element with collection of targets ?) true. forgot to it :) - logger (string attribute, or nested element with class and assembly attribute, and parameters collection ?) I'd like to add XmlLogger to our code (that one from ccnet, if they will borrow it to us, or write ours own), since msbuild comes with only console logger. - verbosity (enum attribute, do we let this coexist with our verbose attribute ?) I mirror Verbose property (nant -v) into that. I still do not grok nant's verbosity system (you remember I have alot complaints about it some time ago). But I believe we could somehow place both worlds together in this respect. Optional: -noconsolelogger (bool attribute) -consoleloggerparameters (nested element, containing collection of parameters) -noautoresponse (bool attribute) -validate (nested element, as it should have an on/off switch and a way to specify a schema file) Ok, no problems with those. Martin: don't mean to sound negative about the work you've done. Thanks for starting with this !! :-) About namespace/packaging: would it be ok to add it to NAntContrib first, and move it to NAnt once it has stabilized ? This is our policy for all new tasks. np. I do not use NAntContrib currently, but no problems with relocating to another project. It is quite stand-alone task (depending on just ExternalProgramBase). Martin --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click ___ nant-developers mailing list nant-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nant-developers
RE: [nant-dev] need VS 2005 solution task support
Hi Martin, I don't think we need to make solution task compatibility a goal here. Creating a solution on the fly is not something we should support, as you need to make a bunch of assumptions anyway (dependencies, platform, ...). We should start it off as a simple wrapper for MSBuild.exe. I think it should be closer to the nant task than the solution task. I think we should add support for : - properties (nested element with collection, similar to nant task) - target(s) (string attribute or nested element with collection of targets ?) - logger (string attribute, or nested element with class and assembly attribute, and parameters collection ?) - verbosity (enum attribute, do we let this coexist with our verbose attribute ?) Optional: -noconsolelogger (bool attribute) -consoleloggerparameters (nested element, containing collection of parameters) -noautoresponse (bool attribute) -validate (nested element, as it should have an on/off switch and a way to specify a schema file) Martin: don't mean to sound negative about the work you've done. Thanks for starting with this !! About namespace/packaging: would it be ok to add it to NAntContrib first, and move it to NAnt once it has stabilized ? This is our policy for all new tasks. Gert -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Martin Aliger Sent: dinsdag 6 december 2005 21:15 To: 'Ian MacLean'; 'Gert Driesen' Cc: '! nant' Subject: RE: [nant-dev] need VS 2005 solution task support Hello, here is first attempt to implement msbuild task for MSBuild interation. To be a little usable for us, NAnt users, I made it atleast little compatible with solution task. So its not a simple wrapper around msbuild.exe. Mainly it accept fileset of projects, which msbuild itself do not. Property names are compatible with solution task as well. I also implement function to distinguish between vs2003/vs2005 projects, but I'm not sure if it'd be useful. For now, I place it to NAnt.DotNet project. Maybe other location is more appropriate? No testcases yet, but they should be next step. Let me know, if you like this approach. More attibutes/element will be needed as well, I think. Ideas are welcomed :-) Almost forgot: you need to add task name=msbuild attribute name=exenameMSBuild/attribute /task to NAnt.exe.config under framework name=net-2.0. Regards, Martin Aliger PS: I'll refactor to follow nant's conding standarts lately. Sorry for inconvenience. This is just a preview... Note: MSBuild from net 2.0 Beta 2 will not compile solutions from VS2005 final. Took me hour to figure :) --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click ___ nant-developers mailing list nant-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nant-developers
RE: [nant-dev] need VS 2005 solution task support
Hello,
here is first attempt to implement msbuild task for MSBuild interation. To
be a little usable for us, NAnt users, I made it atleast little compatible
with solution task. So its not a simple wrapper around msbuild.exe. Mainly
it accept fileset of projects, which msbuild itself do not. Property names
are compatible with solution task as well.
I also implement function to distinguish between vs2003/vs2005 projects, but
I'm not sure if it'd be useful.
For now, I place it to NAnt.DotNet project. Maybe other location is more
appropriate?
No testcases yet, but they should be next step. Let me know, if you like
this approach. More attibutes/element will be needed as well, I think. Ideas
are welcomed :-)
Almost forgot:
you need to add
task name=msbuild
attribute name=exenameMSBuild/attribute
/task
to NAnt.exe.config under framework name=net-2.0.
Regards,
Martin Aliger
PS: I'll refactor to follow nant's conding standarts lately. Sorry for
inconvenience. This is just a preview...
Note: MSBuild from net 2.0 Beta 2 will not compile solutions from VS2005
final. Took me hour to figure :)
// NAnt - A .NET build tool
// Copyright (C) 2001-2004 Gerry Shaw
//
// This program is free software; you can redistribute it and/or modify
// it under the terms of the GNU General Public License as published by
// the Free Software Foundation; either version 2 of the License, or
// (at your option) any later version.
//
// This program is distributed in the hope that it will be useful,
// but WITHOUT ANY WARRANTY; without even the implied warranty of
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
// GNU General Public License for more details.
//
// You should have received a copy of the GNU General Public License
// along with this program; if not, write to the Free Software
// Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
//
// Martin Aliger ([EMAIL PROTECTED])
using System;
using System.IO;
using System.Collections;
using System.Reflection;
using System.Globalization;
using NAnt.Core;
using NAnt.Core.Types;
using NAnt.Core.Attributes;
namespace NAnt.DotNet.Functions
{
/// summary
/// Functions to return information for MSBuild system.
/// /summary
[FunctionSet(msbuild, MSBuild)]
public class MsbuildFunctions : FunctionSetBase
{
#region Public Instance Constructors
/// exclude/
public MsbuildFunctions(Project project, PropertyDictionary
properties) : base(project, properties) {}
#endregion Public Instance Constructors
#region Public Instance Methods
/// summary
/// Test whether project is VS2005 project and could be built
using lt;msbuildgt;
/// /summary
/// param name=projectThe name or path of the project file
(csproj, vbproj, ...)./param
/// returns
/// True, if it is msbuild project, False otherwise.
/// /returns
[Function(is-msbuild-project)]
public bool IsMsbuildProject(string project)
{
using(StreamReader str = new
StreamReader(File.Open(project,FileMode.Open,FileAccess.Read,FileShare.ReadWrite)))
{
System.Xml.XmlDocument doc = new
System.Xml.XmlDocument();
doc.Load(str);
string ns =
doc.NameTable.Get(http://schemas.microsoft.com/developer/msbuild/2003;);
return ns!=null;
}
}
#endregion Public Static Methods
}
}
// NAnt - A .NET build tool
// Copyright (C) 2001-2002 Gerry Shaw
//
// This program is free software; you can redistribute it and/or modify
// it under the terms of the GNU General Public License as published by
// the Free Software Foundation; either version 2 of the License, or
// (at your option) any later version.
//
// This program is distributed in the hope that it will be useful,
// but WITHOUT ANY WARRANTY; without even the implied warranty of
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
// GNU General Public License for more details.
//
// You should have received a copy of the GNU General Public License
// along with this program; if not, write to the Free Software
// Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
//
// Martin Aliger ([EMAIL PROTECTED])
using System;
using System.Globalization;
using System.IO;
using System.Text.RegularExpressions;
using System.Text;
using System.Collections;
using System.Collections.Specialized;
using System.CodeDom.Compiler;
using NAnt.Core;
using NAnt.Core.Tasks;
using NAnt.Core.Attributes;
using NAnt.Core.Types;
using
Re: [nant-dev] need VS 2005 solution task support
Ian, Martin, Do you think we should support VS.NET 2005 solutions/projects in the solution task ? As far as I can tell, we have two options for supporting this: 1. Do the full parsing, and processing of the solutions/projects ourselves, like we do for VS.NET 2002/2003, and use our built-in tasks (and extend these where required) to do the heavy work. 2. Invoke MSBuild (behind the scenes) to build VS.NET 2005 solutions/projects. The advantage of (1) could be that it allows users to target multiple framework versions, but the code that is generated (behind the scenes) by VS.NET 2005 makes it impossible to compile for older versions of .NET. However, we might be able to compile most code using Mono once the Mono tools support some of the stuff that's introduced in .NET 2.0 (eg. creating strongly typed code for accessing resources) Users (build authors) can also extend the VS.NET 2005 project files. This is definitely not something we can support. So, we'd be putting in a lot of effort just to support very basic VS.NET 2005 projects. Option (2) makes perhaps even less sense: if we do not process the VS.NET 2005 solutions/projects ourselves, then we cannot support more advanced options of the solution task for them (such as assemblyfolders, outputdir, ...). And if we cannot do this, then what's the benefit over using a msbuild task anyway ? What do you think ? Gert -Original Message- From: Ian MacLean [mailto:[EMAIL PROTECTED] Sent: Monday, December 5, 2005 06:38 AM To: 'Martin Aliger' Cc: [EMAIL PROTECTED], '! nant' Subject: Re: [nant-dev] need VS 2005 solution task support Martin Aliger wrote: Or, alternativelly, it should not be hard at all to write msbuild task just as a wrapper around msbuild.exe as ccnet do it. Something like ant already do. Not bad idea. What others think about this? Maybe I'd not give up mine hard-earned build scripts after all :-) I think thats a great idea. I think that would be a big help for the many people migrating to vs2005 but wanting to retain their existing NAnt build scripts. Ian --- --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click ___ nant-developers mailing list nant-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nant-developers --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37alloc_id865op=click ___ nant-developers mailing list nant-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nant-developers
RE: [nant-dev] need VS 2005 solution task support
Hello, I was thinking simmilary. full parsing of vs2005 solutions could be pretty hard work and, as you wrote, we'd have just very basic support. So I'd perhaps rather make just msbuild task as a wrapper around msbuild itself, and some function to distinguish between vs2002-3 and vs2005 solutions/csprojs. Next, it could be handy to have some half-automated tool to convert between nant and msbuild scripts. I dont beleive this could be reliably done full automated. msbuild-nant could be used by mono users to compile vs2005 solutions. nant-msbuild could be used by those renegades leaving us. But maybe every build author could translate his scripts himself. Do you know, whether mono team have any plans about msbuild? Do they still use nant internally? I dont follow mono lately and dont find anything about it on web site. == I'll try to write first version of msbuild and vs-proj-is2005 function (suggest name). It could be good starting point atleast. I'll give you know. Martin Aliger -Original Message- From: Gert Driesen [mailto:[EMAIL PROTECTED] Sent: Monday, December 05, 2005 1:54 PM To: Ian MacLean; Martin Aliger Cc: [EMAIL PROTECTED]; ! nant Subject: Re: [nant-dev] need VS 2005 solution task support Ian, Martin, Do you think we should support VS.NET 2005 solutions/projects in the solution task ? As far as I can tell, we have two options for supporting this: 1. Do the full parsing, and processing of the solutions/projects ourselves, like we do for VS.NET 2002/2003, and use our built-in tasks (and extend these where required) to do the heavy work. 2. Invoke MSBuild (behind the scenes) to build VS.NET 2005 solutions/projects. The advantage of (1) could be that it allows users to target multiple framework versions, but the code that is generated (behind the scenes) by VS.NET 2005 makes it impossible to compile for older versions of .NET. However, we might be able to compile most code using Mono once the Mono tools support some of the stuff that's introduced in .NET 2.0 (eg. creating strongly typed code for accessing resources) Users (build authors) can also extend the VS.NET 2005 project files. This is definitely not something we can support. So, we'd be putting in a lot of effort just to support very basic VS.NET 2005 projects. Option (2) makes perhaps even less sense: if we do not process the VS.NET 2005 solutions/projects ourselves, then we cannot support more advanced options of the solution task for them (such as assemblyfolders, outputdir, ...). And if we cannot do this, then what's the benefit over using a msbuild task anyway ? What do you think ? Gert -Original Message- From: Ian MacLean [mailto:[EMAIL PROTECTED] Sent: Monday, December 5, 2005 06:38 AM To: 'Martin Aliger' Cc: [EMAIL PROTECTED], '! nant' Subject: Re: [nant-dev] need VS 2005 solution task support Martin Aliger wrote: Or, alternativelly, it should not be hard at all to write msbuild task just as a wrapper around msbuild.exe as ccnet do it. Something like ant already do. Not bad idea. What others think about this? Maybe I'd not give up mine hard-earned build scripts after all :-) I think thats a great idea. I think that would be a big help for the many people migrating to vs2005 but wanting to retain their existing NAnt build scripts. Ian --- --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click ___ nant-developers mailing list nant-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nant-developers --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click ___ nant-developers mailing list nant-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] need VS 2005 solution task support
Gert Driesen wrote: -Original Message- From: Martin Aliger [mailto:[EMAIL PROTECTED] Sent: Monday, December 5, 2005 02:19 PM To: ''Gert Driesen'', ''Ian MacLean'' Cc: [EMAIL PROTECTED], ''! nant'' Subject: RE: [nant-dev] need VS 2005 solution task support Do you know, whether mono team have any plans about msbuild? Do they still use nant internally? Nope, NAnt is not used internally in the Mono project. Note: we fully support Mono though. not strictly speaking 100% true. Cecil - which is part of mono uses nant although there is a make file as well. But in general everything mono is makefile, autotools based. I dont follow mono lately and dont find anything about it on web site. I know someone was working on it a while ago, but I'm pretty sure there's no longer any activity there. There was a project as part of the google summer of code program. I think it got to the point of being able to build itself but I don't think its been worked in since then. Ian --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click ___ nant-developers mailing list nant-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] need VS 2005 solution task support
Gert Driesen wrote: Ian, Martin, Do you think we should support VS.NET 2005 solutions/projects in the solution task ? As far as I can tell, we have two options for supporting this: 1. Do the full parsing, and processing of the solutions/projects ourselves, like we do for VS.NET 2002/2003, and use our built-in tasks (and extend these where required) to do the heavy work. As Martin already mentioned this is quite a lot fo work - effectively re-implementing msbuild in a revamped solution task. 2. Invoke MSBuild (behind the scenes) to build VS.NET 2005 solutions/projects. This is certainly the easier solution. The advantage of (1) could be that it allows users to target multiple framework versions, but the code that is generated (behind the scenes) by VS.NET 2005 makes it impossible to compile for older versions of .NET. However, we might be able to compile most code using Mono once the Mono tools support some of the stuff that's introduced in .NET 2.0 (eg. creating strongly typed code for accessing resources) For windows platforms there is a project under way to use MSBuild to target vs2005 projects to version 1.1 of the framework - see : http://blogs.msdn.com/clichten/archive/2005/11/08/490541.aspx Depending on how that is distributed we could utilise it to target previous framework versions. Users (build authors) can also extend the VS.NET 2005 project files. This is definitely not something we can support. So, we'd be putting in a lot of effort just to support very basic VS.NET 2005 projects. Short of re-implemening the whole of msbuild - thats right we couldn't do that. Option (2) makes perhaps even less sense: if we do not process the VS.NET 2005 solutions/projects ourselves, then we cannot support more advanced options of the solution task for them (such as assemblyfolders, outputdir, ...). And if we cannot do this, then what's the benefit over using a msbuild task anyway ? Just thinking out loud - but things like assembly folders could be simulated by re-writing the solution/project file before passing it to MSBuild but maybe initially going with a plain msbuild task could be the way to go. Ian -Original Message- From: Ian MacLean [mailto:[EMAIL PROTECTED] Sent: Monday, December 5, 2005 06:38 AM To: 'Martin Aliger' Cc: [EMAIL PROTECTED], '! nant' Subject: Re: [nant-dev] need VS 2005 solution task support Martin Aliger wrote: Or, alternativelly, it should not be hard at all to write msbuild task just as a wrapper around msbuild.exe as ccnet do it. Something like ant already do. Not bad idea. What others think about this? Maybe I'd not give up mine hard-earned build scripts after all :-) I think thats a great idea. I think that would be a big help for the many people migrating to vs2005 but wanting to retain their existing NAnt build scripts. Ian --- --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click ___ nant-developers mailing list nant-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nant-developers --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click ___ nant-developers mailing list nant-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nant-developers
RE: [nant-dev] need VS 2005 solution task support
Thought I'd throw in my 2c as a heavy NAnt user. Gert wrote: Do you think we should support VS.NET 2005 solutions/projects in the solution task ? My thought is that the solution task should *only* handle Visual Studio 2003 projects. Why? It seems to me that VS2003 and VS2005 are sufficiently different creatures that any attempt to handle them within a unified task is going to be fraught with difficulties and likely to have a dozen or so confusing special cases that need to be documented for users. Instead, I'd suggest that the best way to provide 1st class support for VS2005 would be to include an msbuild task that exposes the full capability of the msbuild commandline. By doing this you are ensuring 100% compatibility with what VS2005 does; you may even gain support for other languages at no cost. I think that one key meme to retain is that NAnt has a wider scope than just builds - so even if MSBuild managed to totally displace NAnt as the compilation tool of choice (very unlikely), NAnt would still have a strong role to play. Keep Smiling, Bevan. ** This message (and any files transmitted with it) are confidential and may be legally privileged. If you are not the intended recipient please notify the sender immediately and delete this message from your system. This message does not necessarily reflect the views of the Reserve Bank of New Zealand. If the recipient has any concerns about the content of this message they should seek alternative confirmation from the Reserve Bank of New Zealand. ** --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37alloc_id865op=click ___ nant-developers mailing list nant-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] need VS 2005 solution task support
Martin Aliger wrote: Or, alternativelly, it should not be hard at all to write msbuild task just as a wrapper around msbuild.exe as ccnet do it. Something like ant already do. Not bad idea. What others think about this? Maybe I'd not give up mine hard-earned build scripts after all :-) I think thats a great idea. I think that would be a big help for the many people migrating to vs2005 but wanting to retain their existing NAnt build scripts. Ian --- --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click ___ nant-developers mailing list nant-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nant-developers
RE: [nant-dev] need VS 2005 solution task support
Hello, I do not try ccnet's new msbuild support yet (I'm busy man lately), but this should work, imho. If whole your company will switch to vs2005, you could manualy translate yout nant scripts to msbuild as well and use msbuild instead of nant completely. Its mine plan here in our company. But we're not switching yet. Also I fear, alot of nant feature will not be present in msbuild. Also I have ~1000 c# lines of code embedded in nant via custom tasks, so I'd have to translate those too. I fear, I'll miss nant. But I'd have to live with that... Or, alternativelly, it should not be hard at all to write msbuild task just as a wrapper around msbuild.exe as ccnet do it. Something like ant already do. Not bad idea. What others think about this? Maybe I'd not give up mine hard-earned build scripts after all :-) Martin Aliger -Original Message- From: Gean Boegman [mailto:[EMAIL PROTECTED] Sent: Friday, December 02, 2005 10:33 AM To: Martin Aliger Subject: RE: [nant-dev] need VS 2005 solution task support Hi Martin, Mmm , that does not sound like good news indeed... Damn MS :-) I guess the send best option would be to add support for MSBuild integration... Cruise Control style? I guess that will not work on mono, but at least one can use Visual studio to develop in (I've given up trying to confince our VB dudes from Visual studio)... The Cruise control XML logger and the XSLT does seem to be useable. Laters. Gean --- Martin Aliger [EMAIL PROTECTED] wrote: Gean, I fear it is HUGE task. VS2005 solutions are msbuild files. msbuild is competetive product to NAnt, so its something like NAnt's .build file. Even that msbuild and nant have alot common there are also big differences. I fear there is not such simple conversion as xslt template between msbuild and nant files. To be a little more possitive, vs2005 solutions (if you dont hand-tune them) are all pretty same, so maybe some conversion for this special case could be done. And this special case could serve 99% of cases. But its all about how whole nant project would or would not cooperate with msbuild. For now, we have 2 incompatible build systems (I'm sorry I ignore others...) btw: vs2003 sln support is not simple xslt either. Its more than 5000 c# line codes. Regards, Martin Aliger -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gean Boegman Sent: Thursday, November 24, 2005 7:01 AM To: nant-developers@lists.sourceforge.net Subject: [nant-dev] need VS 2005 solution task support We could really use a VS 2005 sln support, is this beeing planned, how hard would it be for me to try and do a XSLT (I think that's how you do the 2003?). I can try to create one if you guys reckon it's not a huge task. Thanks. Gean _ Have a video conversation in real time - Get MSN Messenger - FREE download. http://messenger.msn.co.za?DI=1054XAPID=2532 --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click ___ nant-developers mailing list nant-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nant-developers ___ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click ___ nant-developers mailing list nant-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nant-developers
[nant-dev] need VS 2005 solution task support
We could really use a VS 2005 sln support, is this beeing planned, how hard would it be for me to try and do a XSLT (I think that's how you do the 2003?). I can try to create one if you guys reckon it's not a huge task. Thanks. Gean _ Have a video conversation in real time - Get MSN Messenger - FREE download. http://messenger.msn.co.za?DI=1054XAPID=2532 --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click ___ nant-developers mailing list nant-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nant-developers
RE: [nant-dev] need VS 2005 solution task support
Gean, I fear it is HUGE task. VS2005 solutions are msbuild files. msbuild is competetive product to NAnt, so its something like NAnt's .build file. Even that msbuild and nant have alot common there are also big differences. I fear there is not such simple conversion as xslt template between msbuild and nant files. To be a little more possitive, vs2005 solutions (if you dont hand-tune them) are all pretty same, so maybe some conversion for this special case could be done. And this special case could serve 99% of cases. But its all about how whole nant project would or would not cooperate with msbuild. For now, we have 2 incompatible build systems (I'm sorry I ignore others...) btw: vs2003 sln support is not simple xslt either. Its more than 5000 c# line codes. Regards, Martin Aliger -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gean Boegman Sent: Thursday, November 24, 2005 7:01 AM To: nant-developers@lists.sourceforge.net Subject: [nant-dev] need VS 2005 solution task support We could really use a VS 2005 sln support, is this beeing planned, how hard would it be for me to try and do a XSLT (I think that's how you do the 2003?). I can try to create one if you guys reckon it's not a huge task. Thanks. Gean _ Have a video conversation in real time - Get MSN Messenger - FREE download. http://messenger.msn.co.za?DI=1054XAPID=2532 --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click ___ nant-developers mailing list nant-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nant-developers --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click ___ nant-developers mailing list nant-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nant-developers
