with current framework set to 1.1, the only correct place to find
System.Xml.dll is the 1.1 framework path. That's what you get when you
do asis=true.
-Original Message-
From: Clayton Harbour [mailto:[EMAIL PROTECTED]
Sent: Friday, June 13, 2003 2:21 PM
To: Erv Walter; [EMAIL PROTECTED]
I might
that is
understandable so that people know what to expect. Heck, until NAnt is
1.0, anything goes, right? :)
-Original Message-
From: John Barstow [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 26, 2003 9:07 PM
To: 'Erv Walter'; [EMAIL PROTECTED]
Erv Walter wrote:
It seems kind of odd
We do something similar except our master build file explicitly calls
the sub build files in the correct order. There is some elegance to the
idea of adding a subproject without having to modify an existing build
file. That doesn't work for us, and it doesn't work in general when you
have
I'm not sure I understand your proposed change. Can
you clarify?
There are 2 camps (and now possibly a third). The
difference between the camps is personal preference, really.
Onecamp is the group of people who find dually
managing build files and project/solution files undesirable (a
is that the existing Build / Rebuild functions continue to
work for the solution and that build errors show up in the normal build
errors task list instead of only in the Output window.
-Original Message-
From: Erv Walter [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 24, 2003 11:56 AM
To: Tomas
be to build VS.NET solution/project
files via the object model (essentially letting "something" else be the master
of files, references, interproject dependencies, etc...), which could maybe
resolve your CVS problem - conflicts in .csproj files due to teamdev
-you[Erv Walter] mention
The biggest issue is exclusions. In a complex application, I guarentee
that you'll have some FxCop violations that are false positives. Even
Microsoft reminded us recently that FxCop is not omniscient and
developers shouldn't be blindly fixing everything that FxCop complains
about.
When you use
This used to be broken and was fixed. It sounds like a recent checkin
broke things again. The 1.27 revision of resgentask.cs broke things
(Mon Aug 18 11:58:18 2003 UTC (8 days, 6 hours ago) by drieseng).
GetOutputFile() depends on being able to tell if someone didn't pass in
todir. The change
This is the setup we use that allows Nant to handle all build duties
from withing VS.NET and it supports debugging:
http://nant.sourceforge.net/wiki/index.php/VSNETIntegrationViaMakefile
-Original Message-
From: Erick Thompson [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 03,
Great Idea. I'd love to get a few more exec tasks out of my builds.
My only suggestion would be to include a Restart action (which would
be equivalent to Stop followed by Start with the appropriate
waitforstatuses).
-Original Message-
From: Gert Driesen [mailto:[EMAIL PROTECTED]
Sent:
VS.NET uses the full name of the class (namespace.classnam) for the behind the
scenes .resx files (those resource files automatically created to hold WinForm
resources, etc.
If you create a .resx explicitly and add it to your project (for example, to hold
string resources for
In my opinion, it would be a good thing if at some point the
solution task did very little work itself. Instead it should
dynamically determine which of the existing tasks should be called and
then call them (instead of calling csc.exe directly, for example). This
would allow the solution task
the drive mapping in your nant script (using the
net use command) instead of depending on a permanent mapping?
--
Erv Walter
608-271-9000
Different all twisty a of in maze are you, passages little
-Original Message-
From: Phil Knight [mailto:[EMAIL PROTECTED]
Sent: Friday, October 17
+1 for that idea.
-Original Message-
From: Matthew Mastracci [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 06, 2003 5:15 PM
To: Nant-Developers (E-mail)
Subject: [nant-dev] touch task w/non-existant files
Should the touch task create a non-existant file? The documentation
says
You can also set this by right-clicking on a .build file in a project
(add one to a project temporarily if you need to) and choosing Open
With... Choose HTML/XML Editor and click Set as Default.
-Original Message-
From: Matthew Mastracci [mailto:[EMAIL PROTECTED]
Sent: Thursday,
Title: Nant Bug?
One of my team members sent me some details on a possible bug with resource handling. It was working in an old version of Nant and they are seeing the following problem when testing the latest RC. It seems that CompilerBase is trying to clean up compiled resource files when
Title: Nant Bug?
Oops. Sorry for not following the list
carefully enough J
From: Gert Driesen
[mailto:[EMAIL PROTECTED]
Sent: Friday, December 12, 2003
10:29 AM
To: Erv Walter;
[EMAIL PROTECTED]
Subject: Re: [nant-dev] Nant Bug?
Erv,
This issue has been
This actually breaks things also. We run Nant from within Visual Studio
to do our builds. With the old way, VS.NET new how understand the
errors from CSC and you could double click on them and VS would jump to
the right spot for the error. This no longer works with the prefix in
place. Can we
Cool, thanks!
-Original Message-
From: Gert Driesen [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 25, 2004 3:56 PM
To: Erv Walter; Nant-Developers (E-Mail)
Subject: Re: [nant-dev] Console logging output
Erv,
You can use the -emacs command line option to accomplish this.
Gert
Title: cl and link tasks
Is there any way to get the cl/ and link/ tasks to work without having Visual Studio environment variables setup (i.e. the PATH variable)? The .NET tasks detect the correct location to run from, but the C++ tasks dont. Is there anything I can do in Nant.exe.config to
Title: compiling .resx files is slow (patch included)
The automatic compilation of .resx resource files by the csc/ task is quite slow. We have several assemblies with many .resx files (40+ resx files) that get included as resources. It was taking 2-3 seconds per .resx file when compiling
was trying to avoid duplicating the logic of
resources.ResxFiles in another function. That could be tweaked either
way as needed.
-Original Message-
From: Gert Driesen [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 05, 2004 4:00 PM
To: Erv Walter; Nant-Developers (E-Mail)
Subject: Re: [nant-dev
Those tasks are better handled by a build coordinator
tool.
Check out one of these (both support using nant to do the
actual build):
http://draconet.sourceforge.net/
http://www.continuousintegration.net/
These tools monitor source control systems (or even just
a directory on the file
I am wondering about another issue that I initially
thought might be helped bythe change below, but it turned out not
quite. I think this has been asked before (a long time ago), but I figured
I'd ask again.
Currently (in cvs), the csc task sets the DEBUG symbol
if debug is true, Full, or
That would work great! I agree that
whatever is done, it should be non breaking to existing true/false settings.
From: Gert Driesen
[mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 08, 2005 2:45
PM
To: Erv Walter;
nant-developers@lists.sourceforge.net
Subject: RE: [nant-dev
Title: Another RC soon?
Any idea when there will be another RC? It's been a while since RC3 and there have been lots of useful/important changes.
26 matches
Mail list logo
