Eric,
It depends how you compile your apps. The way I have done this (and I'm not
saying it's the best!) is I use the / tasks rather than the
task, and every project has its own .build file to build it. I
then have a controlling script and a properties file, and the properties
file contains a b
A great, helpful discussion
I absolutely agree with the concept of treating "internally-created"
assemblies/dll's in the same way as we would "third-party" stuff. It's
a powerful concept, though I've known developers who seem to get really
confused by the idea!
Rod
-Original Message---
Do you have a link to that article?
He is absolutely right. When multiple projects are in a single solution
using a project reference is the best way to do it. But, having all have
to get all source to common projects and needing to rebuild that project
is a pain. Or course, there is an advantage
Actually, John Mischel at Microsoft put out an article
entitled "Project Structure Best Practices" where he
said (note paragraph 2):
There are several different ways that you can
structure your solutions and projects. The most common
method is a single solution that contains multiple
projects. Thi
MS has a white paper on this at
http://msdn.microsoft.com/practices/compcat/default.aspx?pull=/library/e
n-us/dnbda/html/tdlg_rm.asp
And they list several ways of structuring a project. But, no where do
they say which one is "best"... the basically say it depends on your
project and circumstances
Hi, Eric
Sounds OK at first blush...assuming you're getting everything you need
for all possible "shared projects">
Rod
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Eric
Fetzer
Sent: Tuesday, September 12, 2006 10:43 AM
To: Bob Archer; Nant User
Thanks for your reply Bob and Rod!
We've got a new twist that developed in a meeting this
morning. We're moving over to project references
only. The lead architect here is insistent because
Microsoft considers this "Best Practice". From a CM
perspective, this makes it tougher in reference to
sh
> If I have dll references, I have to get all of the developers to keep
these components in the same place as I keep them for the build so that
the hint path resolves.
My first comment is having all your devs use the same directory
structure is actually a good thing. It makes source control much e
Hi, Eric
I've got a couple of variations.
For one, we have an "Assemblies" folder in VSS, and I can get from
their. It's a little not neat, because I have to do a setup each Build
separately. Also, I've found that Developers don't keep the shared
folder current...or they make minor tweaks f
I'm looking for "Best Practices" for components that
are shared among several applications in reference to
NAnt. First of all, dll or project references. If I
have dll references, I have to get all of the
developers to keep these components in the same place
as I keep them for the build so that t
I would suggest that if you've moved from vss to vsts, you should
perhaps rexamine your scm usage.
Just because you did it in vss doesn't mean it's a good idea with vsts.
Despite being rather a lock in product, it does have _substantial_
improvements in allowed workflows.
I mean, what on earth
11 matches
Mail list logo
