[nant-dev] NAnt contrib build file
Title: Message
Hi,
I have put together a little
build script to make it easier to build/ rebuild NAnt and NAntContrib.
Itispretty basic so far but if it is useful to others I can check it
in. It is attached (build-contrib.xml)for review along with a
modified NAnt.build file (target BuildContrib added).
Cheers,
Clayton
project name=NAntContrib fetch and build default=build
property name=cvs.root value=:pserver:[EMAIL PROTECTED]:/cvsroot/NAntContrib/
property name=cvs.rsh value=e:/dev/bin/plink.exe/
property name=cvs.module value=NAntContrib/
property name=dir.root value=${nant.project.basedir}/.. /
property name=dir.base value=${dir.root}/${cvs.module}/
property name=dir.build value=${dir.base}/
property name=dir.home value=h:/
property name=sourcecontrol.usesharpcvslib value=false/
target name=fetch description=Fetch NAntContrib from sourceforge.
ifnot test=${directory::exists(dir.base)}
cvscommand=checkout
destination=${dir.root}
cvsroot=${cvs.root}
module=NAntContrib
cvspass=${dir.home}
cvsrsh=plink
/cvs
/ifnot
if test=${directory::exists(dir.base)}
cvscommand=update
destination=${dir.base}
cvsroot=${cvs.root}
module=NAntContrib
cvspass=${dir.home}/.cvspass
cvsrsh=plink
/cvs
/if
/target
target name=build depends=fetch description=Build NAntContrib
nant buildfile=${dir.build}/NAntContrib.build target=build
property name=nant.dir value=${nant.dir} /
/nant
/target
/project
NAnt.build
Description: NAnt.build
[nant-dev] Solution Error With DependantOn
Hello. Awesome job on the Solution tasks. I write bi/tri lingual applications and I am happy to see that support added in. But, I found a little bug. I don't know HOW I ended up with two dependent resources files but it would be good to correctly load them. I have an item in a project that has multiple dependent resources: File RelPath = ChangeLanguageControl.fr-ca.resx DependentUpon = ChangeLanguageControl.cs BuildAction = EmbeddedResource / File RelPath = ChangeLanguageControl.resx DependentUpon = ChangeLanguageControl.cs BuildAction = EmbeddedResource / The solution task incorrectly guesses the name of ChangeLanguageControl.fr-ca.resx is ChangeLanguageControl. I have attached the verbose output of the project. But it looks like this is the offending line: [solution] /res:C: \DOCUME~1\mfletche\LOCALS~1\Temp\ao_tdzw_\PetroCanada.CorpExec.Localizat ion\ChangeLanguageControl.fr- ca.resources,PetroCanada.CorpExec.Localization.ChangeLanguageControl.r esources and then ... [compile] error CS1508: Resource identifier 'PetroCanada.CorpExec.Localization.ChangeLanguageControl.resources' has already been used in this assembly C:\Documents and Settings\mfletche\Desktop\BuildTest..\nant\bin\nant NAnt 0.85 (Build 0.85.1533.0; net-1.0.win32; nightly; 13/03/2004) Copyright (C) 2001-2004 Gerry Shaw http://nant.sourceforge.net Buildfile: file:///C:/Documents and Settings/mfletche/Desktop/BuildTest/test.build Target(s) specified: build build: [solution] Starting solution build. [solution] Loading projects... [solution] Loading project 'C:\Documents and Settings\mfletche\Desktop\BuildTest\Solutions\..\Assemblies\External\PetroCanada.CorpExec.Maintenance\PetroCanada.CorpExec.Maintenance.csproj'. [solution] Loading project 'C:\Documents and Settings\mfletche\Desktop\BuildTest\Solutions\..\Assemblies\External\PetroCanada.CorpExec.DataAccess\PetroCanada.CorpExec.DataAccess.csproj'. [solution] Loading project 'C:\Documents and Settings\mfletche\Desktop\BuildTest\Solutions\..\Assemblies\External\PetroCanada.CorpExec.Maintenance.Web\PetroCanada.CorpExec.Maintenance.Web.csproj'. [solution] Loading project 'C:\Documents and Settings\mfletche\Desktop\BuildTest\Solutions\..\Assemblies\External\PetroCanada.CorpExec.Localization\PetroCanada.CorpExec.Localization.csproj'. [solution] Loading project 'C:\Documents and Settings\mfletche\Desktop\BuildTest\Solutions\..\Assemblies\External\PetroCanada.CorpExec.ErrorNotification\PetroCanada.CorpExec.ErrorNotification.csproj'. [solution] Loading project 'C:\Documents and Settings\mfletche\Desktop\BuildTest\Solutions\..\Assemblies\External\PetroCanada.CorpExec.Security\PetroCanada.CorpExec.Security.csproj'. [solution] Loading project 'C:\Documents and Settings\mfletche\Desktop\BuildTest\Solutions\..\Assemblies\PetroCanada.Legal.MatterMng.WebControls\PetroCanada.Legal.MatterMng.WebControls.csproj'. [solution] Loading project 'C:\Documents and Settings\mfletche\Desktop\BuildTest\Solutions\..\Assemblies\PetroCanada.Legal.MatterMng.QueryGenerator\PetroCanada.Legal.MatterMng.QueryGenerator.csproj'. [solution] Loading project 'C:\Documents and Settings\mfletche\Desktop\BuildTest\Solutions\..\Assemblies\PetroCanada.Legal.MatterMng.Data\PetroCanada.Legal.MatterMng.Data.csproj'. [solution] Loading project 'C:\Documents and Settings\mfletche\Desktop\BuildTest\Solutions\..\Assemblies\External\PetroCanada.CorpExec.Reports\PetroCanada.CorpExec.Reports.csproj'. [solution] Loading project 'C:\Documents and Settings\mfletche\Desktop\BuildTest\Solutions\..\Assemblies\External\PetroCanada.CorpExec.Searcher\PetroCanada.CorpExec.Searcher.csproj'. [solution] Loading project 'C:\Documents and Settings\mfletche\Desktop\BuildTest\Solutions\..\WebProjects\MatterMng\MatterMng.csproj'. [solution] Loading project 'C:\Documents and Settings\mfletche\Desktop\BuildTest\Solutions\..\Assemblies\PetroCanada.Legal.MatterMng\PetroCanada.Legal.MatterMng.csproj'. [solution] Loading project 'C:\Documents and Settings\mfletche\Desktop\BuildTest\Solutions\..\Assemblies\PetroCanada.CorpExec.SQLMaps\PetroCanada.CorpExec.SQLMaps.csproj'. [solution] Loading project 'C:\Documents and Settings\mfletche\Desktop\BuildTest\Solutions\..\Assemblies\External\PetroCanada.CorpExec.WebControls\PetroCanada.CorpExec.WebControls.csproj'. [solution] Gathering additional dependencies... [solution] Fixing up references... [solution] Building 'PetroCanada.CorpExec.Maintenance' [debug]... [solution] Project is up-to-date. [solution] Fixing up references... [solution] Building 'PetroCanada.CorpExec.DataAccess' [debug]... [solution] Project is up-to-date. [solution] Fixing up references... [solution] Building 'PetroCanada.CorpExec.Localization' [debug]...
Re: [nant-dev] Error while Building solution with NAnt
I can still see this one... With the 03/13/2004 build.
I suppose I should be using the PIA for Office rather than a manually
generated interop assembly... But I don't think that's the culprit.
- Original Message -
From: Gert Driesen
Subject: Re: [nant-dev] Error while Building solution with NAnt
Date: Thu, 26 Feb 2004 23:42:51 -0800
Rajeev,
Can you try using the latest nightly build
(http://nant.sourceforge.net/nightly/builds) as there have been some
fixed
in this area recently ?
Thanks,
Gert
- Original Message -
From: Rajeev Ramaswamy [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, February 26, 2004 7:34 AM
Subject: [nant-dev] Error while Building solution with NAnt
I got the following error while using the solution task for
building my
project.
VSSSolution:
[solution] Starting solution build.
BUILD FAILED
INTERNAL ERROR
System.ApplicationException: Couldn't find reference to type library
'Office' (T
YPELIB\{2DF8D04C-5BFA-101B-BDE5-00AA0044DE52}\2.0\0\win32).
at NAnt.VSNet.Reference.HandleWrapperImport(XmlElement
elemReference)
---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] Error while Building solution with NAnt
Jeff,
You should definitely get another message using the latest nightly build.
Can you package up a zip file that allows me to reproduce this issue, and
possible also send me your build log, created using :
NAnt.exe -buildfile:build file -verbose -logfile:buildlog.txt
(so also send me the buildlog.txt file)
Gert
- Original Message -
From: Jeff Vanerwegen [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, March 15, 2004 4:09 AM
Subject: Re: [nant-dev] Error while Building solution with NAnt
I can still see this one... With the 03/13/2004 build.
I suppose I should be using the PIA for Office rather than a manually
generated interop assembly... But I don't think that's the culprit.
- Original Message -
From: Gert Driesen
Subject: Re: [nant-dev] Error while Building solution with NAnt
Date: Thu, 26 Feb 2004 23:42:51 -0800
Rajeev,
Can you try using the latest nightly build
(http://nant.sourceforge.net/nightly/builds) as there have been some
fixed
in this area recently ?
Thanks,
Gert
- Original Message -
From: Rajeev Ramaswamy [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, February 26, 2004 7:34 AM
Subject: [nant-dev] Error while Building solution with NAnt
I got the following error while using the solution task for
building my
project.
VSSSolution:
[solution] Starting solution build.
BUILD FAILED
INTERNAL ERROR
System.ApplicationException: Couldn't find reference to type library
'Office' (T
YPELIB\{2DF8D04C-5BFA-101B-BDE5-00AA0044DE52}\2.0\0\win32).
at NAnt.VSNet.Reference.HandleWrapperImport(XmlElement
elemReference)
---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
[nant-dev] Solution task fixes + speedups
I've spent a bit more time speeding up the solution task and fixing differences from VS.NET. Here's a short summary of what to expect with the latest CVS: 1. We only create one AppDomain per solution build and per project build. We were creating dozens of AppDomains per project build before. 2. GAC checks (IsAssemblyInGac) are now cached per solution build. This cuts 25% of the build time off alone. 3. The HintPath for a reference is now checked before the AssemblyFolders. VS.NET checks it this way and it can break a solution that wants to reference (using a direct assembly reference) a different version of an assembly than might have been installed in an AssemblyFolder path. Matt. --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] Solution task fixes + speedups
- Original Message - From: Matthew Mastracci [EMAIL PROTECTED] To: Gert Driesen [EMAIL PROTECTED] Cc: Nant-Developers (E-mail) [EMAIL PROTECTED] Sent: Tuesday, March 16, 2004 11:05 PM Subject: Re: [nant-dev] Solution task fixes + speedups Gert Driesen wrote: 3. The HintPath for a reference is now checked before the AssemblyFolders. VS.NET checks it this way and it can break a solution that wants to reference (using a direct assembly reference) a different version of an assembly than might have been installed in an AssemblyFolder path. Are you sure about this ??? I haven't checked this, but according to MS this is kind of the last resort ... Guaranteed. I have a project that references an assembly (v1 of the DLL) with the same name as an assembly in one of my assembly folders (v2 of the DLL). Before my change, it was incorrectly picking up v2. After the change, it correctly picks up v1. But you actually have two different assembly folders : you have the assembly folder that is referenced in your project file using the AssemblyFolderKey attribute of the Reference element, eg. Reference Name = Infragistics.Win.UltraWinListBar.v3 AssemblyName = Infragistics.Win.UltraWinListBar.v3 AssemblyFolderKey = hklm\infragistics.win.ultrawinlistbar.v3.00.20033 / and you have the rest of the AssemblyFolder registry keys. Perhaps VS.NET first checks the AssemblyFolderKey, then the HintPath and then the rest of the assembly folders. But I'm just guessing here. Even if Microsoft describes it as a last resort, it's definitely not how VS.NET does it. I'll verify it tomorrow, and report it to MS if necessary Gert --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
[nant-dev] Re: Change to call task makes upgrade difficult
James C. Papp wrote:
This was also my rational of not just adding a flag to call/. The depends/
task is just a dynamic form of the target/ task's depends attribute..., in
all other respect their ultimate functionality would be identical. The
depends/ task was not meant to be used as a way to call targets, but (more
accurately), to assert that a set of dependencies were meet or handled (if
needed) before continuing. This is similar a little bit to .NET security with
the way you can request certain privileges up front (as assembly metadata), or
dynamically by asserting them within code.
Heh... I just ran into the same problem you have. My workaround so far
is to add the following attribute to all of my execute-once targets:
unless=${target::has-executed(target::get-current-target())}
I would love to have the depends/ task instead. :)
Matt.
---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
[nant-dev] NAnt pedantic mode
I've run into a number of build-script bugs today that are related to NAnt task properties changing/disappearing/obsoleting/etc. What does everyone think of a command-line flag to put NAnt into pedantic mode? This would throw an error if any build task tried to use a property that didn't exist or was obsoleted. I would personally run in pedantic mode all the time. Ideas? Comments? Flames? :) Matt. --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] NAnt pedantic mode
- Original Message - From: Matthew Mastracci [EMAIL PROTECTED] To: Nant-Developers (E-mail) [EMAIL PROTECTED] Sent: Wednesday, March 17, 2004 1:52 AM Subject: [nant-dev] NAnt pedantic mode I've run into a number of build-script bugs today that are related to NAnt task properties changing/disappearing/obsoleting/etc. What does everyone think of a command-line flag to put NAnt into pedantic mode? This would throw an error if any build task tried to use a property that didn't exist or was obsoleted. You mean an attribute that didn't exist ? Properties that don't exist cause a build error already ... But I agree that we should indeed have this mode (or just always run NAnt in this mode, what do you propose) ... In what cases should NAnt throw a build error : - a system property that no longer exist - an attribute/child element that is deprecated, and the IsError property of the ObsoleteAttribute is set to true - a task/type that is deprecated, and the IsError property of the ObsoleteAttribute is set to true - an attribute/child element that does not (or no longer) exist in what cases should NAnt output a warning (deprecated message) in the build log : - a system property that has been replaced/renamed (eg. replaced by a function), but the original property still exists. - an attribute/child element that is deprecated, and the IsError property of the ObsoleteAttribute is set to false - a task/type that is deprecated, and the IsError property of the ObsoleteAttribute is set to false Please correct me wherever necessary and add items to these lists Gert --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] Re: Change to call task makes upgrade difficult
Matthew, can you add this task to NAntContrib cvs ? Its in the NAnt patches
tracker.
But I wonder if we should change it to use a collection of target elements,
eg.
depends
target name=... if=${build.all} /
target name=... /
target name=... /
/depends
That way you can also conditionally execute a certain target. (by the way:
not sure I like the name of the task)
We could ofcouse always reinstate the force attribute of the call task,
but in that case it should be true by default ...
Gert
- Original Message -
From: Matthew Mastracci [EMAIL PROTECTED]
To: James C. Papp [EMAIL PROTECTED]; Nant-Developers (E-mail)
[EMAIL PROTECTED]
Sent: Wednesday, March 17, 2004 1:21 AM
Subject: [nant-dev] Re: Change to call task makes upgrade difficult
James C. Papp wrote:
This was also my rational of not just adding a flag to call/. The
depends/
task is just a dynamic form of the target/ task's depends
attribute..., in
all other respect their ultimate functionality would be identical. The
depends/ task was not meant to be used as a way to call targets, but
(more
accurately), to assert that a set of dependencies were meet or handled
(if
needed) before continuing. This is similar a little bit to .NET security
with
the way you can request certain privileges up front (as assembly
metadata), or
dynamically by asserting them within code.
Heh... I just ran into the same problem you have. My workaround so far
is to add the following attribute to all of my execute-once targets:
unless=${target::has-executed(target::get-current-target())}
I would love to have the depends/ task instead. :)
Matt.
---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] Re: Solution task fixes + speedups
Matthew, I looked into this again, and I'm pretty sure I'm right : The HintPath is definitely the last resort for VS.NET. So we should undo your change (unless you can send me a repro). The issue you encountered was probably due to the fact that we don't yet use the path list in the ReferencesPath attribute (of the Settings node) in the .user file (the project user options) to locate assemblies. (feel free to add support for this to the solution task :-)) Gert - Original Message - From: Matthew Mastracci [EMAIL PROTECTED] To: Gert Driesen [EMAIL PROTECTED] Cc: Nant-Developers (E-mail) [EMAIL PROTECTED] Sent: Tuesday, March 16, 2004 11:35 PM Subject: [nant-dev] Re: Solution task fixes + speedups Gert Driesen wrote: But you actually have two different assembly folders : you have the assembly folder that is referenced in your project file using the AssemblyFolderKey attribute of the Reference element, eg. ... and you have the rest of the AssemblyFolder registry keys. Perhaps VS.NET first checks the AssemblyFolderKey, then the HintPath and then the rest of the assembly folders. But I'm just guessing here. Aha... I don't have an AssemblyFolderKey attribute on my reference - it's a direct file reference. The AssemblyFolder check was still picking it up, however. Perhaps the order was correct as you had it, but we should skip the assembly folder check if that attribute is missing. Even if Microsoft describes it as a last resort, it's definitely not how VS.NET does it. I'll verify it tomorrow, and report it to MS if necessary Cool. Thanks! Matt. --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
