System.Exception: Couldn't
find referenced assembly: E:\TeamFSI\Program
Files\Microsoft.NET\Odbc.Net\Microsoft.Data.Odbc.dll
at NAnt.VSNet.Tasks.Reference.GetReferenceFiles(ConfigurationSettings
cs)
at NAnt.VSNet.Tasks.Project.Compile(String
strConfiguration, ArrayList alCSCArguments,
Hi,
I've been following (though I should admit
not very actively using) NAnt for a while now (about 1200 nant posts in my
inbox). Especially, not being able to handle the VS.NET "solution"
concept was something that bothered me (well, let me rephrase: not handled
elegantly). Ofcourse, it
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
No problem. I'm all for refactoring the solution task. It's not an
elegant solution for what it accomplishes. My overall goal for the
solution task is to be able to point it at either a solution or a group
of projects and have them built in the correct order, with outputs
identical to how
I'm with you on the .sln thing. We were getting daily conflicts on the
.sln file, so I ended up checking it in as a binary file so that it
wouldn't merge. .csproj files seems to be adequate for our needs. They
occasionally conflict, but not enough so far to annoy us out of using
them (yet).
Every developer (the main dev team has about 8 people) builds
directly with
nant everytime (one of my coworkers came up with the idea to
add a custom
tool to vs.net that fires nant for the project and puts the
nant output in
the vs.net output window. nifty!).
How does one go about
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
It saves them all. One other good side effect of having output go to the output window
is context sensitivity for the errors/warnings on output of csc. You can click on the
output line and get VS.NET takes you to the source line.
-bc
-- Original Message
It's probably clear, but did forget to mention that to use this, you add
this project to your solution and then configure your solution to turn
off building for all projects except this one. The benefit from my
perspective (a minor one) over the External Tool approach that some
people use is that
That makes things much more clear for me, and it sounds
like a great idea.
From: Yves Reynhout [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 24, 2003 4:35 PMTo:
[EMAIL PROTECTED]Subject: Re: [nant-dev]
Solution/Project Parser
From reading the response posts I think I
didn't make myself
10 matches
Mail list logo
