What does everyone think of adding native NAnt pre- and post-build
events to the solution task. These tasks would be independent of the
existing project pre- and post-build events.
Ideally, we would make the current pre- and post-build expansion macro
variables available via properties:
My
Taking a look at the build file for the tests, it looks like the MSNet
tests DLL doesn't include any files but the ../../src/CommonAssemblyInfo.cs.
It's possible that the fileset changes broke parent directory traversal.
Gert Driesen wrote:
Hi Martin,
I'll look into that error later. For now,
With the help of Gert Dreisen, we've landed some major file-scanning
performance changes. You'll find them in any nightly builds from today
onward. I'm seeing major CPU usage drops as well as improvements in
scanning many filesets. I can now run a full rebuild on an unchanged
What sort of files are in that temp directory after NAnt completes?
Nicklas Norling wrote:
Hi.
No, my system is not very slow. It's a P4 3(?) GHz with a HD doing 60-40
MB/s random read.
I've tried it both with and without [EMAIL PROTECTED] running and it seemed to
make no differance. I've had
no
it's finished. Only the
directory itself remains.
/Nicke
Matthew Mastracci wrote:
What sort of files are in that temp directory after NAnt completes?
Nicklas Norling wrote:
Hi.
No, my system is not very slow. It's a P4 3(?) GHz with a HD doing
60-40 MB/s random read.
I've tried it both
I think we decided to just document this side-effect.
My memory fails me here ... But if that is what we decided, then I
guess we should indeed document it in both the filset doc and in the
release notes ..
Sounds fair.
The reason for keeping this was that it was more consistent with
patterns
-developers
= = = = = = = = = = = = = = = = = = = =
Your sincerely:
Jackfan
[EMAIL PROTECTED]
2004-09-04
= = = = = = = = = = = = = = = = = = = =
Your sincerely:
Jackfan
[EMAIL PROTECTED]
2004-09-04
--
Matthew Mastracci [EMAIL PROTECTED
of previous runs cached, this shouldn't have
an appreciable impact on performance.
Matt.
On Sat, 2004-09-04 at 09:04, Gert Driesen wrote:
- Original Message -
From: Matthew Mastracci [EMAIL PROTECTED]
To: Gert Driesen [EMAIL PROTECTED]
Cc: Jackfan [EMAIL PROTECTED]; Nant-Developers (E-Mail
,
-- Troy
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of Matthew Mastracci
Sent: Thursday, 8 July 2004 5:34 AM
To: Nant-Developers (E-mail)
Subject: [nant-dev] Two broken testcases - edge case question
It looks like the regex optimization broke an edge case
:
----- Original Message -
From: "Ian MacLean" [EMAIL PROTECTED]
To: "Matthew Mastracci" [EMAIL PROTECTED]
Cc: "Gert Driesen" [EMAIL PROTECTED]
Sent: Friday, July 09, 2004 4:12 AM
Subject: Re: Fw: [nant-dev] current cvs build failure
Matthew
se directory is set to each of the path elements and searched as
above.
If a pattern is rooted, it is tested against the entire path string.
If the full pattern path happens to correspond to the base directory,
it may apply to files beneath the base directory.
We should probably document t
On Thu, 2004-07-08 at 20:12, Ian MacLean wrote:
Matthew Mastracci wrote:
Strange - I had the same issue while I was developing (turned out that
the DirectoryScanner was busted), but the fix for that was checked in.
Where was the fix ? Maybe its manifesting itself in another way on my
Here's a few hot-spots that someone could probably pick off pretty easy.
All percentages are relative to total time.
This is from running a solution task based build. I haven't tried a
csc-based build yet.
ProjectSettingsLoader::ProcessPlatform - 5.6%
+-
3% of the total runtime of NAnt during my test
build - effectively dwarfed by most other operations.
Matt.
Matthew Mastracci wrote:
Just as an extra note-
Before the change, there were 13 regex comparisons in one of our
projects.
The change reduces this to 128000 string comparisons (taking
It looks like the regex optimization broke an edge case:
**/* now matches the base directory, as well as any subdirectories on a
FileSet.DirectoryNames call. For instance, in the following directory
structure, all three will be matched with a base directory of C:\foo:
C:\foo
C:\foo\bar
Can anyone give me a hint on how to create these assembly references in
1.0/1.1 via VS.NET? I haven't seen them before.
Gert Driesen wrote:
- Original Message -
From: Ian MacLean [EMAIL PROTECTED]
To: Gert Driesen [EMAIL PROTECTED]
Cc: Matthew Mastracci [EMAIL PROTECTED]; Nant
;
}
text3 = assembly1.GetName().Name;
LicenseCompiler.assemHash.Add(text3, assembly1);
if (text3 != text1)
{
continue;
}
return assembly1;
}
...
Gert
- Original Message -
From: Matthew Mastracci [EMAIL
Gert Driesen wrote:
Can't we do a quick parse of the resx sources to see if they require
those references ? A large number of cases do not require any references
at all.
Yeah we probably could ... Just didn't/don't have time for that, and didn't
see much need for it at that point ...
I had to
to call lc.exe multiple times.
We should probably be documenting some of these quirks somewhere. I
usually end up running into something that looks like a bug, but turns
out to be by design.
Matt.
Matthew Mastracci wrote:
Gert Driesen wrote:
Matthew,
The .NET 1.1 lc.exe indeed has a command line
Something that changed in the last six months or so (perhaps longer?) is
that the projects no longer set their working directory equal to the
base directory of the project itself.
I'm proposing the following patch to Project.cs to fix this. Since I
don't know if anyone relies on the current,
I just checked in a change to fileset scanning that eliminates a large
chunk of time (checked via profiling) during many of the common NAnt
operations.
One of the biggest losers on the profiling run was Regex.Match(), called
many, many times during a build. The new code replaces a good
for a general solution build to match (or exceed)
VS.NET's compilation speed wherever possible.
Matt.
- Original Message -
From: Matthew Mastracci [EMAIL PROTECTED]
I just checked in a change to fileset scanning that eliminates a large
chunk of time (checked via profiling) during many
of the built-in ones like
**/CVS/**, etc. If we cache the compiled
Matt.
Matthew Mastracci wrote:
I just checked in a change to fileset scanning that eliminates a large
chunk of time (checked via profiling) during many of the common NAnt
operations.
One of the biggest losers on the profiling run
or, when Microsoft went open-source.
Looks like Microsoft has finally jumped on the true open source
bandwagon with the release of WiX - an XML to MSI compiler.
It's unfortunately not under a GPL-compatible license (preventing direct
linking), but the command-line interface would work just
Gert Driesen wrote:
So anyways, I finally understand that you are correct - VS.NET does
check AssemblyFolders before HintPath. IMHO this is a strange way to do
things. VS.NET doesn't make it easy to easily reproduce a build between
two machines, does it?
No, definitely not. In my opinion,
It seems like our CopyLocal logic in the solution task doesn't seem to
match VS.NET 2003. Did this change between 2002/2003?
As far as I can see, if the CopyLocal flag is not specified in 2003, it
should be treated as false. Does anyone know for sure what this is in 2002?
Matt.
Gert Driesen wrote:
Matthew,
The CopyLocal behaviour depends on whether the assembly is a system
assembly or not (and some other criteria too perhaps).
I'm pretty sure the current implement matches the behaviour of VS.NET
2003, but I might be wrong ofcourse.
Do you have a example of where the
Gert Driesen wrote:
You mean an attribute that didn't exist ? Properties that don't exist cause
a build error already ...
Yep - that's what I was thinking.
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
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
Gert Driesen wrote:
I can also guarantee 100% that VS.NET (2003) is only using the hintpath as a
last resort ;)
I've reverted the change in CVS. Thanks for the explanation :)
Matt.
---
This SF.Net email is sponsored by: IBM Linux Tutorials
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
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
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
wrote:
Matthew, can you tell me what makes our WebDAV access to IIS so much more
troublesome, than what VS.NET uses ?
Thanks,
Gert
- Original Message -
From: Matthew Mastracci [EMAIL PROTECTED]
To: Nant-Developers (E-mail) [EMAIL PROTECTED];
[EMAIL PROTECTED]
Sent: Tuesday
As a curiousity, wouldn't you be able to use a regular target and
properties to define what to call? For instance, your gateway project
can just do this:
target
name=process
description=Builds recursively all subprojects
foreach
item=Folder
property=foldername
Giuseppe Greco wrote:
As a curiousity, wouldn't you be able to use a regular target and
properties to define what to call? For instance, your gateway project
can just do this:
Yes, but this is exactly what I'm trying to avoid...
When a master build file contains more than 3 or 4 targets
to
I've had a fix for this one locally for a while - just checked it in.
Gert Driesen wrote:
Matt,
Can you please submit a bug report for this ?
Thanks,
Gert
- Original Message -
*From:* Steele, Matt mailto:[EMAIL PROTECTED]
*To:* '[EMAIL PROTECTED]'
mailto:'[EMAIL
Sure... shouldn't be too tough. I'll just create a testcase that runs
the touch task twice in a row on the same file.
Gert Driesen wrote:
- Original Message -
From: Matthew Mastracci [EMAIL PROTECTED]
To: Gert Driesen [EMAIL PROTECTED]; Nant-Developers (E-mail)
[EMAIL PROTECTED]
Sent
Looks like the nightly task docs broke at some point-
http://nant.sourceforge.net/nightly/help/
You don't have permission to access /nightly/help/index.html on this
server.
Permissions issue with SCP?
Matt.
---
The SF.Net email is sponsored
Guids should be unique. The only way to get this is by copying a
project and forgetting to change it. VS.NET doesn't warn you of this,
but behaves badly in subtle ways.
Ian MacLean wrote:
Is this the right patch ? if it is possible to have two valid projects
with an identical guid should we
For tasks (such as the solution task), what about having C# classes in
NAnt that map to XML itself? They could appear as XML to
xmlpeek/xmlpoke/xmlforeach, but would be backed by C# classes internally.
This would make it far simpler to return values from tasks.
Martin Aliger wrote:
Hi all,
Original Message
Subject: [Nprof-developers] Re: solution task
Date: Tue, 06 Jan 2004 11:09:22 -0700
From: Matthew Mastracci [EMAIL PROTECTED]
To: Martin Aliger [EMAIL PROTECTED],
[EMAIL PROTECTED]
References: [EMAIL PROTECTED]
Sounds good to me too - just ensure that you've
tasks) and
adding context info so tasks know about following task, and preceding tasks,
sounds interesting. But I'm not sure how this ties in here.
What would the user experience be? What would the syntax be?
- Original Message -
From: Matthew Mastracci [EMAIL PROTECTED]
For tasks
-0700
From: Matthew Mastracci [EMAIL PROTECTED]
To: Martin Aliger [EMAIL PROTECTED],
[EMAIL PROTECTED]
References: [EMAIL PROTECTED]
Sounds good to me too - just ensure that you've got compilerargs
specified by language. There's a number of flags that are valid for a
single compiler only.
Martin Aliger
Gert - are we branched for 0.84? I have some minor checkins I'm itching
to get in for the 0.85. I can also look at some solution cleanups over
my vacation time in the next few weeks.
Gert Driesen wrote:
- Original Message -
From: Scott Hernandez [EMAIL PROTECTED]
To: Morris, Jason
/ could also be updated but this probably falls out of the scope
of that. This is pretty specialized, and will need to be very specific to
xml.
- Original Message -
From: Matthew Mastracci [EMAIL PROTECTED]
To: Nant-Developers (E-mail) [EMAIL PROTECTED]
Sent: Thursday, December 18, 2003 12:25 PM
Has somebody modified the project basedir semantics? The latest CVS
version isn't working correctly for me. It's acting as if the basedir
attribute wasn't specified.
I'll try to find out the date that it was busted, but I'm curious if
anyone remembers changing anything to do with this.
This
Well, with additional investigation, it appears that the problem is that
something has broken the includesList element in my build file.
My build files are structured like so:
\build\scripts\nightly.build
basedir=.
\build\scripts\project1.build
basedir=../..
It seems as if project1.build is
So it looks like the recent basedir changes have revealed a
long-standing issue w.r.t. assumptions about the current directory. It
turns out that there are a few places where the tasks assume that the
project's base directory is the same as the current directory. The two
big ones I've found
Looks pretty good to me. Do you notice an impact on compile speed?
I can try patching my local copy of NAnt and running it through our
build torture test - 90+ projects with all sorts of inter-project and
3rd-party references. :) I may not have time to do this until next
week, however.
That would be cool. It would be nice to move the reference code into a
common place (the csc and vbc tasks) to avoid code duplication.
Matt.
Gert Driesen wrote:
- Original Message -
From: Matthew Mastracci [EMAIL PROTECTED]
To: Nant-Developers (E-mail) [EMAIL PROTECTED]
Sent
Sorry! That was a think-o on my part. I meant resource code. Should
have read:
It would be nice to move the *resource* code into a ...
Been a tough week ;)
Matt.
Gert Driesen wrote:
- Original Message -
From: Matthew Mastracci [EMAIL PROTECTED]
To: Gert Driesen [EMAIL PROTECTED
(re-cc'ing the list)
AppDomains allow you load/unload assemblies at will. The .NET runtime
tends to exhibit some odd/unpredictable behaviour as you load assemblies
with the same name, especially if they don't have strong names. You can
end up with types no longer resolving as expected. By
At some point I'd like to use the multiple .resx input of resgen.exe -
it would be nice to swallow output if no errors occur and just output:
[resgen] Transformed 5 .resx files
The solution builds would be a lot easier to read. Perhaps I can
compress all of the reference copy operations into
What about a framework task that sets appropriate properties based on
provided flags? This could allow us to hide a number of different tests
to select appropriate frameworks:
!-- Select the currently executing framework --
framework type=current /
!-- Would these be useful at all? --
I don't know if there has been a consensus about the license change.
The discussion kind of petered off after a while. I'm still supporting
either LGPL or GPL with linking/plugins exception, however.
Matt.
Jaroslaw Kowalski wrote:
Hi!
According to releaseplan.html a Move to an Apache or
Make sure your COM dll is registered on the server that is building your
project.
Gerold Kathan wrote:
hi - we are trying to get our solution to build by nAnt - actually we
are not successful - there seems to be something missing - we reference
a COM dll (BAWPublicV5) and solution task
Viehland, Kirk wrote:
Nant developers,
I am getting this error when I compile a VS.Net 2003 solution with an
ProductInfo file that has been linked from a parent directory.
Just as a side note - what is a Linked file within a solution? How is
one created?
I've been thinking about some of the target dependency functionality,
and I was wondering what people thought about having some extra
specification of target ordering. There's a couple of types in here, so
I've broken them up. I'm interested in hearing opinions of what people
think of these.
Gert Driesen wrote:
No problem for me, but I suggest holding off on this change until after the
0.8.4 release ... would that be ok for you ?
Sure. I'll keep the changes in my tree until 0.8.4 is out the door.
Matt.
---
This SF.net email is
It looks like tons of bug reports are coming from people using the 0.8.3
version of the solution task. Should we put out 0.8.4 ASAP? Any
volunteers for the release?
This might cut down on the repetitive bug reports. :)
Matt.
---
This
I'm not sure if this was posted to these lists before, but this registry
modification with allow you to edit .build file with nice XML syntax
hiliting in VS.NET 2003.
Windows Registry Editor Version 5.00
#1 difference - the source availability! :)
John Lam wrote:
I've spent a fair amount of time recently with MSBuild, and have the
following set of observations about its relationship to [N]Ant:
---
This SF.net email is sponsored by: SF.net
I pointed nprof at NAnt to see if I could get the solution task to
build a little quicker for those of us with extra-large solutions. The
code in Reference.cs was re-loading projects over and over if project
references were being used. This re-loading of projects consumed over
99% of the
I've found a bug in the NUnit2 test domain. It seems that it changes
the current directory to be the directory of the testing assembly, but
then tries to use the relative path to access the assembly. I haven't
checked it in, because this behavour has changed at some point between
0.8.3 and
I agree, though in [2] and [3] I believe that changes (if any) to the
core NAnt code should be contributed back.
Scott Hernandez wrote:
All of these scenarios should be allowed, IMHO.
- Original Message -
From: Brant Carter [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, October
While replying to your note, I noticed the following on our license page:
http://nant.sourceforge.net/license.html
---
NAnt ships with a prebuilt version of NDoc. The NAnt license does not
apply to these components located in the bin folder of the distribution.
NDoc is licensed under the GNU
://lists.sourceforge.net/lists/listinfo/nant-developers
--
Matthew Mastracci [EMAIL PROTECTED]
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
nant-developers mailing
.
Thanks for the clarification,
Matt.
Ian MacLean wrote:
Matthew Mastracci wrote:
Please let me know if I'm totally out to lunch on this one- I'm guessing
that this resx issue you are describing is a problem with the solution
task.
I think he's talking about Compilerbase.cs. The regular compiler
Unfortunately, VS.NET uses the name of the class as the generated
resources filename. Changing this would break any designer-created code.
BTW, as a friendly suggestion. :) I can't read your mail from Sept. 9
because it appears to be encoded in something other than text/plain. I
get
[mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 17, 2003 5:00 AM
To: Matthew Mastracci; Vincent Labatut
Cc: [EMAIL PROTECTED]
Subject: Re: [nant-dev] solution task fix
VS.NET uses the full name of the class (namespace.classnam) for the behind
the scenes .resx files (those resource files
scanner (I'm not
sure, cause I have not much time to dive into this yet). If
I give something like D:\licensed_components\*.dll as
includes in the nested assembly, he tries to load dlls
without the ending. Eg A file name assembly.dll gets only
assembly .
HTH,
-sa
--
Matthew Mastracci [EMAIL
Quick note- should the compiler be specified for each of these args?
Not all args are supported by all compilers. Specifying an argument
that a compiler does not support may break your build. I'd wager that a
good number of places used mixed-language builds.
BTW, thanks for all of the
I agree with Martin. Sometimes you need to override a build setting on
your build machine. At our shop, we tag each build with a string
version that doesn't fit Microsoft's idea of a version number. This
produces a warning and, on assemblies that build with warning = error, a
build failure!
Especially those people using Draco.NET to build Sourceforge projects. :)
Martin Aliger wrote:
Seems ok.
It is not problem for me - just a general thought.
Maybe we could add note about it into doc for NUnit{1,2} tasks. Could
be problem for projects like Draco.NET or CruiseControl.NET
heaven.
http://thinkgeek.com/sf
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
--
Matthew Mastracci [EMAIL PROTECTED]
---
This sf.net
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
--
Matthew Mastracci [EMAIL PROTECTED]
---
This sf.net email is sponsored by:ThinkGeek
Welcome
assembly-folders
includes name=c:\temp\build\dll/
/assembly-folders
/solution
Martin
--
Matthew Mastracci [EMAIL PROTECTED]
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http
Good find. I like your assembly-folders idea. Unfortunately, I'm quite
busy at work and don't have any time for solution task development.
It should be pretty straight-forward to implement if someone has an hour
or so to space.
Martin Aliger wrote:
I did some exploration in this field and
I think I understand. Each developer has a bunch of reference
directories that are set up in VS.NET, right? You're right - we would
likely need to add a references tag to the solution task to handle
this situation.
Matt.
Martin Aliger wrote:
Odd... We simply check in .csproj files and
with the correct reference path for that workstation.
brant
...
From: Martin Aliger [EMAIL PROTECTED]
To: Matthew Mastracci [EMAIL PROTECTED]
CC: ! nant [EMAIL PROTECTED]
Subject: Re: [nant-dev] last suggestion - Solution task again
Date: Mon, 25 Aug 2003 10:52:59 +0200
I'd recommend
Eddie - ignoring non-csproj and non-vbproj files looks good. We
shouldn't do this without at least warning the user that we are ignoring
their projects, however. Can you add a log message to this test?
Eddie Tse wrote:
Hi All,
I've been experimenting with the solution task from CVS and had
I'd recommend against comparing only filenames. This will likely end up
causing trouble down the line. VS.NET is certainly a mess when it comes
to hint paths, but I've found that they are generally accurate. I don't
even think it uses them half of the time. :)
Can you describe your
: Matthew Mastracci [EMAIL PROTECTED]
To: J. Jason De Lorme [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Saturday, August 02, 2003 1:05 AM
Subject: Re: [nant-dev] Avoid using WebDAV with solution task
Just a note- there was recently a submission that added a webmap
URL-filesystem mapping
party libraries (for multiple framework versions).
Apparently you've committed the NAnt.VSNet.build from the main branch to the
0.8.3 branch.
Gert
- Original Message -
From: Matthew Mastracci [EMAIL PROTECTED]
To: John Barstow [EMAIL PROTECTED]
Cc: Nant-Developers (E-mail) [EMAIL
Perhaps it might be better to design an .xsd and use the automatic XML
deserialization routines. I've found that this way is much cleaner than
the methods used in the current solution and slingshot tasks.
Bernard Vander Beken wrote:
Hello Yves,
Have you looked at the parsing logic and
concept. And then it was Matthew Mastracci I believe
(correct me if I'm wrong) that introduced the solution task into
NAnt. Unfortunatly, I'm not quiet happy with its current
implementation, because there's no clear separation between the
solution/project as data (the content of the .sln and .*prj
). Ofcourse, it all depends on your focal point, meaning if
you don't use VS.NET, you probably couldn't care less about the
solution concept. And then it was Matthew Mastracci I believe
(correct me if I'm wrong) that introduced the solution task into
NAnt. Unfortunatly, I'm not quiet happy with its
Does VS.NET save all of your files before doing a build, or do you have
to manually save them?
Bill Conroy wrote:
My whole team does this all too.
Here is the writeup I gave out a while back to the OT list on how to do this:
Here are the steps I used to integrate[note I do not address keeping
release candidate.
Matthew Mastracci wrote:
I've just realized that the temp directory leak in the solution task
is likely slowing my build process down by an order of magnitude!
Those who run checkin/nightly builds with this task may wish to
consider an automated process to clear the temp
This is a bug. I'm pretty sure it's fixed in CVS. Use the lowercase
version of your configuration (ie: release) instead of Release.
[EMAIL PROTECTED] wrote:
I have built some projects successfully and have made sure that the
dependencies are build in order, however, when NAnt tries to
Install the framework SDK. This includes all of the utilities required
to fully build a VS.NET solution, minus devenv.exe.
Aaron Jensen wrote:
Part of our .NET software requires use of a .NET wrapper around a COM
object. As such, during a build (using the sln / taks), tlbimp.exe is
called
Do you have a release configuration in your
MobileAdministratorPlugins project?
Vitaly Livshits wrote:
Hello,
I am getting the following error when trying to to build my solution.
Do you know what might be causing it?
The .build file is attached.
Thanks,
Vitaly Livshits
Senior Software
I've also checked in support for reading resources of VB projects and
generating the appropriate dependent resource name. This was supposed
to go in RC1, but I managed to check it into the wrong CVS branch. Look
for it in the final 0.8.3 release.
Matt.
For those interested, some recent bugfixes checked in:
- Generate the correct filename for .resx files without dependent files
(ie: x\foo.resx in project some.namespace -
some.namespace.x.foo.resources)
- Convert the requested configuration to lowercase to match the rest of
the solution
Bizarre- I thought this was checked in before RC1. You might need to
wait for the final release.
Philippe Lavoie wrote:
Im resending this with RC1 in the title so that John doesnt miss it J
Im getting the following output which I though was solved by Matthew
[solution] -
I thought it was both, but I made a number of fixes and it might have
slipped through my mental net. Will the final release be made against
the HEAD or RC1?
On Thu, 2003-07-17 at 19:25, Ian MacLean wrote:
Matthew Mastracci wrote:
Bizarre- I thought this was checked in before RC1. You might
: Matthew Mastracci [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 03, 2003 12:07 PM
To: Philippe Lavoie
Cc: [EMAIL PROTECTED]
Subject: Re: [nant-dev] Bug in solution task with a web project
Is CSC.EXE in your path while running NAnt?
I'm hoping one day to add a web path mapping property
Message-
From: Matthew Mastracci [mailto:[EMAIL PROTECTED] Sent: Thursday, July
03, 2003 12:07 PM
To: Philippe Lavoie
Cc: [EMAIL PROTECTED]
Subject: Re: [nant-dev] Bug in solution task with a web project
Is CSC.EXE in your path while running NAnt?
I'm hoping one day to add a web path mapping
Is it alright to do a couple of pre-0.8.3 builds before the real one (at
least one)?
I found that for the last release, people are more likely to test and
send bug reports for a pre- build than a development build.
Matt.
John Barstow wrote:
I'm hoping to do an 0.8.3 release sometime next
1 - 100 of 135 matches
Mail list logo
