Re: The way NuGet works

2012-01-25 Thread Preet Sangha
It is possible to create a nuget 'master libs' type arrangement. I recall
doing it in my last role.

You create a nuget.config file in the same directory as the solution file
 containing the shared location. It worked great

repositories
repository path=..\MyProject\packages.config /
/repositories

http://stackoverflow.com/a/8918617/30225
On 25 January 2012 20:46, Michael Minutillo michael.minuti...@gmail.comwrote:

 Hi Greg,

 Check out
 http://docs.nuget.org/docs/workflows/using-nuget-without-committing-packagesfor
  details of how to get nuget to manage the dependencies without checking
 in all of those files into source control. This gets even more powerful if
 you have a corporate NuGet server so that you get to control all of the
 dependencies without duplicating them over and over in the repository.


 Michael M. Minutillo
 Indiscriminate Information Sponge
 http://codermike.com



 On Wed, Jan 25, 2012 at 3:36 PM, Peter Gfader pe...@gfader.com wrote:

 Hi Greg

 Then I see that it has created a packages folder under my solution
 folder containing 55 files in 4 folders with a total size of 3.8MB. Now
 this seems a bit heavy-handed ... it will create duplicated and redundant
 files in projects everywhere, multiple tool versions can be installed, and
 it will make version control and deployment trickier.

 Why would you say that it makes deployment trickier?

 I am not a big fan of having lots of duplicated files either, for every
 little pet project. But the advantage is that it just works: Get latest
 from source control - all references can be resolved...

 .peter.gfader.
 http://blog.gfader.com

 fat fingers + tiny touchscreen - short emails
 On Jan 25, 2012 7:53 AM, Greg Keogh g...@mira.net wrote:

 People have been talking about NuGet a bit so I thought I’d try it out.*
 ***

 ** **

 The very first thing that confused me was the relationship between the
 NuGet packages I install and those that I have already installed by other
 means. For example I get packages for Entity Framework, Nunit and SQL CE,
 but I already have these installed. So I opened a small console app and
 added the NUnit package to see what happens. I see that it adds 3
 references like this sample:

 ** **

 E:\dev\command\myapp\packages\NUnit.2.5.10.11092\lib\nunit.framework.dll
 

 ** **

 Then I see that it has created a packages folder under my solution
 folder containing 55 files in 4 folders with a total size of 3.8MB. Now
 this seems a bit heavy-handed ... it will create duplicated and redundant
 files in projects everywhere, multiple tool versions can be installed, and
 it will make version control and deployment trickier. I’m utterly
 bewildered by what NuGet has done and find it hard to believe that anyone
 would find this acceptable.

 ** **

 Am I missing something?

 ** **

 Greg





-- 
regards,
Preet, Overlooking the Ocean, Auckland


Re: The way NuGet works

2012-01-25 Thread David Burela
I don't understand how it makes anything trickier.
Deployment is easy, all the assemblies are set as copy local = true.
having 3mb of files isn't a problem with source control, but there are
strategies around how you can make it NOT check those files in if you are
worried.


On 25 January 2012 17:53, Greg Keogh g...@mira.net wrote:

 People have been talking about NuGet a bit so I thought I’d try it out.***
 *

 ** **

 The very first thing that confused me was the relationship between the
 NuGet packages I install and those that I have already installed by other
 means. For example I get packages for Entity Framework, Nunit and SQL CE,
 but I already have these installed. So I opened a small console app and
 added the NUnit package to see what happens. I see that it adds 3
 references like this sample:

 ** **

 E:\dev\command\myapp\packages\NUnit.2.5.10.11092\lib\nunit.framework.dll**
 **

 ** **

 Then I see that it has created a packages folder under my solution folder
 containing 55 files in 4 folders with a total size of 3.8MB. Now this seems
 a bit heavy-handed ... it will create duplicated and redundant files in
 projects everywhere, multiple tool versions can be installed, and it will
 make version control and deployment trickier. I’m utterly bewildered by
 what NuGet has done and find it hard to believe that anyone would find this
 acceptable.

 ** **

 Am I missing something?

 ** **

 Greg



Re: The way NuGet works

2012-01-25 Thread Grant Molloy
I believe you can also make nuget packages for your own libraries that you
include in your projects, which means that your library is only in source
control once, as the project itself.
You may need a corporate nuget server for this, I'm not 100% sure..
On 26/01/2012 9:46 AM, David Burela david.bur...@gmail.com wrote:

 I don't understand how it makes anything trickier.
 Deployment is easy, all the assemblies are set as copy local = true.
 having 3mb of files isn't a problem with source control, but there are
 strategies around how you can make it NOT check those files in if you are
 worried.


 On 25 January 2012 17:53, Greg Keogh g...@mira.net wrote:

 People have been talking about NuGet a bit so I thought I’d try it out.**
 **

 ** **

 The very first thing that confused me was the relationship between the
 NuGet packages I install and those that I have already installed by other
 means. For example I get packages for Entity Framework, Nunit and SQL CE,
 but I already have these installed. So I opened a small console app and
 added the NUnit package to see what happens. I see that it adds 3
 references like this sample:

 ** **

 E:\dev\command\myapp\packages\NUnit.2.5.10.11092\lib\nunit.framework.dll*
 ***

 ** **

 Then I see that it has created a packages folder under my solution folder
 containing 55 files in 4 folders with a total size of 3.8MB. Now this seems
 a bit heavy-handed ... it will create duplicated and redundant files in
 projects everywhere, multiple tool versions can be installed, and it will
 make version control and deployment trickier. I’m utterly bewildered by
 what NuGet has done and find it hard to believe that anyone would find this
 acceptable.

 ** **

 Am I missing something?

 ** **

 Greg





Re: The way NuGet works

2012-01-24 Thread djones147
Greg
For the last few years, all the projects that I have worked on have had a 
libs or dependencies folder that is included in the source code. 

It's a practice that has come from the Java world, one that I like. It avoids 
conflicts in updating libraries, and all team members have the correct version 
of the dll from source control. 

Davy 
Hexed into a portable ouija board. 

-Original Message-
From: Greg Keogh g...@mira.net
Sender: ozdotnet-boun...@ozdotnet.com
Date: Wed, 25 Jan 2012 17:53:14 
To: 'ozDotNet'ozdotnet@ozdotnet.com
Reply-To: ozDotNet ozdotnet@ozdotnet.com
Subject: The way NuGet works

People have been talking about NuGet a bit so I thought I'd try it out.

 

The very first thing that confused me was the relationship between the NuGet
packages I install and those that I have already installed by other means.
For example I get packages for Entity Framework, Nunit and SQL CE, but I
already have these installed. So I opened a small console app and added the
NUnit package to see what happens. I see that it adds 3 references like this
sample:

 

E:\dev\command\myapp\packages\NUnit.2.5.10.11092\lib\nunit.framework.dll

 

Then I see that it has created a packages folder under my solution folder
containing 55 files in 4 folders with a total size of 3.8MB. Now this seems
a bit heavy-handed ... it will create duplicated and redundant files in
projects everywhere, multiple tool versions can be installed, and it will
make version control and deployment trickier. I'm utterly bewildered by what
NuGet has done and find it hard to believe that anyone would find this
acceptable.

 

Am I missing something?

 

Greg




Re: The way NuGet works

2012-01-24 Thread Peter Gfader
Hi Greg

Then I see that it has created a packages folder under my solution folder
containing 55 files in 4 folders with a total size of 3.8MB. Now this seems
a bit heavy-handed ... it will create duplicated and redundant files in
projects everywhere, multiple tool versions can be installed, and it will
make version control and deployment trickier.

Why would you say that it makes deployment trickier?

I am not a big fan of having lots of duplicated files either, for every
little pet project. But the advantage is that it just works: Get latest
from source control - all references can be resolved...

.peter.gfader.
http://blog.gfader.com

fat fingers + tiny touchscreen - short emails
On Jan 25, 2012 7:53 AM, Greg Keogh g...@mira.net wrote:

 People have been talking about NuGet a bit so I thought I’d try it out.***
 *

 ** **

 The very first thing that confused me was the relationship between the
 NuGet packages I install and those that I have already installed by other
 means. For example I get packages for Entity Framework, Nunit and SQL CE,
 but I already have these installed. So I opened a small console app and
 added the NUnit package to see what happens. I see that it adds 3
 references like this sample:

 ** **

 E:\dev\command\myapp\packages\NUnit.2.5.10.11092\lib\nunit.framework.dll**
 **

 ** **

 Then I see that it has created a packages folder under my solution folder
 containing 55 files in 4 folders with a total size of 3.8MB. Now this seems
 a bit heavy-handed ... it will create duplicated and redundant files in
 projects everywhere, multiple tool versions can be installed, and it will
 make version control and deployment trickier. I’m utterly bewildered by
 what NuGet has done and find it hard to believe that anyone would find this
 acceptable.

 ** **

 Am I missing something?

 ** **

 Greg



Re: The way NuGet works

2012-01-24 Thread Michael Minutillo
Hi Greg,

Check out
http://docs.nuget.org/docs/workflows/using-nuget-without-committing-packagesfor
details of how to get nuget to manage the dependencies without
checking
in all of those files into source control. This gets even more powerful if
you have a corporate NuGet server so that you get to control all of the
dependencies without duplicating them over and over in the repository.


Michael M. Minutillo
Indiscriminate Information Sponge
http://codermike.com


On Wed, Jan 25, 2012 at 3:36 PM, Peter Gfader pe...@gfader.com wrote:

 Hi Greg

 Then I see that it has created a packages folder under my solution
 folder containing 55 files in 4 folders with a total size of 3.8MB. Now
 this seems a bit heavy-handed ... it will create duplicated and redundant
 files in projects everywhere, multiple tool versions can be installed, and
 it will make version control and deployment trickier.

 Why would you say that it makes deployment trickier?

 I am not a big fan of having lots of duplicated files either, for every
 little pet project. But the advantage is that it just works: Get latest
 from source control - all references can be resolved...

 .peter.gfader.
 http://blog.gfader.com

 fat fingers + tiny touchscreen - short emails
 On Jan 25, 2012 7:53 AM, Greg Keogh g...@mira.net wrote:

 People have been talking about NuGet a bit so I thought I’d try it out.**
 **

 ** **

 The very first thing that confused me was the relationship between the
 NuGet packages I install and those that I have already installed by other
 means. For example I get packages for Entity Framework, Nunit and SQL CE,
 but I already have these installed. So I opened a small console app and
 added the NUnit package to see what happens. I see that it adds 3
 references like this sample:

 ** **

 E:\dev\command\myapp\packages\NUnit.2.5.10.11092\lib\nunit.framework.dll*
 ***

 ** **

 Then I see that it has created a packages folder under my solution folder
 containing 55 files in 4 folders with a total size of 3.8MB. Now this seems
 a bit heavy-handed ... it will create duplicated and redundant files in
 projects everywhere, multiple tool versions can be installed, and it will
 make version control and deployment trickier. I’m utterly bewildered by
 what NuGet has done and find it hard to believe that anyone would find this
 acceptable.

 ** **

 Am I missing something?

 ** **

 Greg