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=7637&alloc_id=16865&op=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=7637&alloc_id=16865&op=click
_______________________________________________
nant-developers mailing list
nant-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nant-developers
