Re: The way NuGet works
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
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
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
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
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
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
