NuGet Needs Your Input

Apr 6, 2011 nuget oss code suggest edit

Hi there, it’s time to shine the bat-signal, or better yet, the NuGet-Signal!

batman-sending-nuget-signal The NuGet community needs your help! We’re wrestling with some interesting wide ranging design decisions and we need data to test out our assumptions and help us make the best possible choices. I won’t go into too much detail about the specific issue as I don’t want to bias the results of the following survey. I simply want to gather information about common practices by answering a set of questions that mostly have empirical answers.

I think it’s a given that most Visual Studio solutions consist of multiple projects. What’s I’m not so sure about is how often those solutions consist of multiple applications?

For example, is it more common for your solution to have a single core app and all of the other projects support that app?

multi-project-single-app

Or is it more common to have a solution with two different apps such as two WinForm apps or two web apps?

multi-project-multi-app

So please answer the following questions:

This survey requires using a browser that supports iframes.

As an example for that last question, here’s the packages folder for a sample solution I created. It has four packages where there are multiple versions.

packages

Thanks for taking the time to answer these questions. I’ll follow up later with more details on what we’re working on.

And feel free to elaborate in the comments if you have more to say!

Found a typo or mistake in the post? suggest edit

Comments

35 responses

marisks • April 7th, 2011
With current NuGet version it is hard to manage packages in projects in solution.
For example, I need NHibernate 2.1 and install it to my Core library, but I also need it in my Web project. Now I cannot add already installed library, but have to install it again. And if I will not provide version it will install me 3d version of NHibernate. Removing it and installing right version is quite hard.
So installing packages to solution would be nice feature. But then we need also some action how to add these packages to particular projects.
@markmario • April 7th, 2011
I have situations where I have multiple solutions each with multiple projects that share a currently share a external-binaries folder. I would love to use nuget with this scenario easily.
haacked • April 7th, 2011
@marisks when you install a package into a project, it does install it into a solution. If you then "install" it into another project, it just "applies" it to that project. It doesn't re-download the project. That's how it works today.
Damien • April 7th, 2011
Question 6 sounds optional - but if you leave it blank and hit submit, all your answers are cleared, you're looking at the bottom of the survey, and it's not obvious that the sentence "please answer every question" has appeared, in red, at the top of the survey.
Grrr.
Damien • April 7th, 2011
And, in the results, questions 5 & 6 switch around. Very confusing.
haacked • April 7th, 2011
Sorry Damien, I'll fix it.
RWHepburn • April 7th, 2011
I'm all for installing packages at the Solution level! Mainly because I just when though the process of adding a large number of NuGet packages to a LOB Silverlight app that had over 20 Projects in the Solution! Although I haven't hit it yet, I can see the need to have different NuGet package versions across different projects.
Urs Enzler • April 7th, 2011
While having one version of a reference for all projects is the normal case in my projects, I really need the possibility to set individual versions. For me it would be nice if there was some sort of overview dialog where all projects of the solution are shown together with the version of each reference and allowing me to update individual or multiple references at once.
Cheers
Urs
Maarten Mensink • April 7th, 2011
I think you should be able to use different of a package within on solution but i also think you should get a notice if you add a newer version of a package that you are using a older package within the same solution.
Two situation i can think of:
1. If you have a application which uses a website frontend and a winforms backend you would most likely want to use the same dll so you are sure you will get the same results.
2. If you run a Azure Cloud and you add multiple website under one role you would like to be able to have one running jquery 1.5.1 and the other 1.5.2 enforcing the same package version may force the developer to change his code if he wishes to host 2 website under one webrole.
Gael Fraiteur • April 7th, 2011
I with the post-install script (install.ps1) could work on the project XML file (for instance an XmlDocument) instead of the project DTE object. In order to integrate PostSharp in a project, the package must add a new import, define some properties and add some XML comments for documentation. It's not possible (or reasonably easy) to do it with the DTE, but quite easy using XmlDocument. However, when we use direct XML project modification, it triggers some dialogs "Project File Has Changed". The hooks should be possibly independent from Visual Studio DTE.
In my opinion, they should be based on XmlDocument and the NuGet library could add some utilities to do common operations.
Jer0enH • April 7th, 2011
I was also under the impression that a package was only added to the project, not to the solution, glad to know that it is actually done right!
Having multiple versions of a same external assembly sounds 'smelly' to me, I just don't see any cases where this would be absolutely required (sounds like I would rather split my solution in multiple parts...).
Paul Cowan • April 7th, 2011
I was the main developer on horn or hornget which you may have heard of.
I think we at least tried to fix the dependency issue albeit in a way that required buy in from all the OSS that I can muster.
I think openwrap is also trying to solve the dependency problem programatically but I am not sure how nuget tries to approach the problem apart from pretending it is not the package manager's problem.
This is the main problem with package management in .NET. Dependencies, dependencies and dependencies.
Signed assemblies are a great evil in this area.
betty • April 7th, 2011
Maybe you could provide some Powershell event hooks to allow people to pick their preferred behaviour via more nuget packages. Ala fervent coders update all package.
Constantinos • April 7th, 2011
I have used NuGet recently in a MVC 3 solution and it seemed to work well with the latest TFS. When a new package was downloaded everything seemed fine.
The weird stuff happens when the solution already has a version of some bit or piece of a package shipped with the template. Say MVC 3 Web Application has jquery.Validate.js which don’t work well with jquery > 1.5.x.
In this case the new package that supports jquery 1.5.1 downloads and seems to be installed but actually the old version remains in the solution.
Without manual intervention this cannot be fixed.
Maybe the default Template of MVC 3 should be altered to better support upgrades through NuGet
Tiendq • April 7th, 2011
I always go with "single core-multi support", if I have more than one core application I'd like to create a separate solution for each core application and those solutions share support projects.
John Ludlow • April 7th, 2011
Hi,
The situation I find myself in with regard to multiple versions of an assembly within a solution is with some of our extensions, companion tools and build tasks which work with WiX. To build some of these we need to include a reference to the version of the WiX dll that the tool targets. (Currently this does not have a NuGet package AFAIK, but in the future maybe)
But we're also in a migration from WiX v2 to v3.5 so we have some tools in both versions, and we need to build both sets of tools with the correct WiX references.
So while it's probably not a common scenario, it can happen that you get a solution with multiple projects with references to different versions of the same package.
Mike • April 7th, 2011
Questions #3 and #4 are tricky- although I'd like to have the exact same version of an assembly in all projects, this is not always possible. In a larger development environment, core (company) framework code doesn't always move as fast as other projects, and upping versions of IoC containers, serialization libraries, or other libs is not always feasible.
It will also be nice to add a reference to all projects and/or all test projects. Usually I find having to add the service library twice, especially to the parent/test project.
hometoast • April 7th, 2011
I love how simple NuGet is. I'd prefer it to stay simple and have one version of a package per solution. If I needed finer grain control over which assemblies get which versions of which packages, I'd use a different tool (custom build and deployment scripts).
kamranayub • April 7th, 2011
I agree with all the dependency management comments; solution-level and project-level should both be supported. For those that aren't sure why you'd need different versions, sometimes you have multi-targeted apps in a solution and they can't work with the same versions. Ideally, they would, but sometimes legacy apps just aren't so nice :)
More importantly, and totally unrelated to dependencies, I'd really like to see better "help" management in NuGet. Unless you know the library, the Nuget manager just doesn't make it easy to figure out what you just installed, how you use it, and what it added to your project. Sometimes the "More Information" link doesn't cut it, because it goes to a generic project homepage instead of the documentation for Nuget installs.
This is made worse during upgrades... what the hell did they change, why is my code broken, I saw a note about "during an upgrade blah blah blah" but when I go back to the package manager I don't see the note again...
It's not necessarily the package creator's fault; I'd like to see better integration for external documentation WITHIN Nuget. A package creator can make the More Information link go to a Nuget help page but at least giving them the option to include install/upgrade notes during installation would be awesome. I admit I don't know a lot about Nuget package making... is it possible to provide this sort of thing and creators just don't do it?
Kyle West • April 7th, 2011
Our solution has a couple "core" libraries, a test class library, two web applications and two console applications.
I've seen plenty of other solutions though with a couple "core" libraries and a single web application/or windows application.
I think it is fairly common to have console applications within the solution too. Hope that helps.
Kyle
Rob Reynolds • April 7th, 2011
As @betty described: "Fervent coders" update all package - http://nuget.org/List/Packages/NuGetPackageUpdater
Based on this: https://gist.github.com/747529
Andy Alm • April 8th, 2011
I work for a largish company, and for us, we have two different types of source trees. We have our application source trees, which typically have one "blessed" solution that contains the application specific projects. Then we have our "shared code" source tree(s), which just consist of a bunch of .csproj files that produce assemblies that are consumed by 2 or more applications. For the application source trees, managing package dependencies at the solution level works best, because we want the whole application to be on the same version of everything. While an application source tree might technically have more than one app in it (e.g. a console app), it can still be viewed as one cohesive unit.
However, for our "shared code" source trees, solutions are irrelevent. They can be sliced and diced however one wants, and managing packages at the solution level makes no sense there at all. We have instances of projects in these tree's that intentionally use different versions of packages as well.
I hate to say it, but basically we need the flexibility for managing at both the project level, and the application (solution) level.
Robert • April 8th, 2011
Please lease don't over complicate NuGet for features that only 1% of the people may someday need. In EVERY single project I've ever seen (and as a consultant for 15 years..I've seen so many) cases where a solution contains multiple project, there's only one main project and there's NO NEED to have multiple version of some library within the same solution. Just keep it simple for goodness' sakes!!!
haacked • April 8th, 2011
Hi @Robert et al, we're not trying to overcomplicate NuGet, but looking at possible simplifications.
We already support multiple versions of a package in the same solution today, and that's the thing we're thinking of changing. For example:
Solution has Project A and Project B
Install Log4Net 1.0 in Project A.
Install Log4Net 1.1 in Project B.
You now have both Log4Net 1.0 and 1.1 installed in your solution.
1.0 in Project A, and 1.1 in Project B.
What we're thinking about doing is making it so that you can't get into this situation.
Thus the change we're considering is:
Solution has Project A and Project B
Install Log4Net 1.0 in Project A.
Install Log4Net 1.1 in Project B.
Now both Projects have Log4Net 1.1 installed.
However, this has big implications. What if you really wanted different versions? The change we're considering is an all or nothing change. It's a lot of work to try and support both models moving forward. So we want to know how many people we will piss off if we go with this new behavior. :)
Rocky Lhotka • April 8th, 2011
One thing about "versions" are platforms.
I tend to have solutions with .NET, SL, and WP7 projects - so while I might use the same "version" of a package - the actual DLLs are often targeted at these different platforms.
I still do want the versions kept in sync - but the .NET project gets the .NET version, the SL project gets the SL version, etc.
troll • April 8th, 2011
:-)
[NullReferenceException: Object reference not set to an instance of an object.]
ASP._Page_Views_Answer_Results_cshtml.Execute() in
d:\websites\survey.haacked.com\Views\Answer\Results.cshtml:22
Wesley Tansey • April 8th, 2011
When working at a hedge fund, I used to keep my trading models, utilities, and core libs all in one big project. It just made it easier to prototype things and go, since 90% of projects were dumped anyway. There were issues sometimes with the R COM interface libraries being buggy for some calls in newer versions, but older ones didn't have the features I needed in the other projects. Once the direction and process became more solidified, I cleaned everything up: separate solutions and actually removed the R COM dependencies -- I just write scripts and run R programmatically now.
I wouldn't mind if VS asked me to upgrade the older versions, though.
jitendra • April 10th, 2011
Seems you are fully dipped in nuget these days :)
Jim Geurts • April 10th, 2011
For all of the solutions I have worked on (past & present), I want every project to use the same version of their shared dependencies.
Rush • April 10th, 2011
I would like packages updated across all projects in a solution. It's a pain to go through each project and update all packages individually. For some solutions we are doing continuous integration and during the build process it pushes nuget package(s). These packages could get updated quite a bit and are used in many projects in many solutions. I wish there was an easier way to update.
JM • April 12th, 2011
We are really looking for better team development support. For example: If I use nuGet to add a package to my project, and then check it in, when the guy down the hall from me gets latest, he doesn't get the binaries that I added to the project (unless I put them in source control, and I don't want to do that).
Getting the dev environment configured properly when joining an existing project has always been a real headache -- we use internal wiki, word of mouth, documents (install this, install that, etc).
What I would really love is a solution where a I can open the project from source control, and it "just works" -- no dependency setup.
Steve Sheldon • April 13th, 2011
We tried NuGet in a multi .sln, multi .csproj structure and it really started to fall apart fast. Updates attach only affect projects, not solutions, etc. I can confirm the first posters experience is correct. This was with v1.1, haven't checked if this still happens with v1.2.
We considered using it with a local repository to manage shared libraries used by various feature teams. It didn't help version management though, actually made it worse, and all the libraries were strewn throughout the TFS structure.
NuGet seems to work for demos and small dev projects, but not for larger endeavors.
I looked into this problem and came across Maven, which I think offers a better solution. There you define your dependencies, and it's actually a build step to grab them if they aren't already there. This way these dependencies are in a single location, a local repository perhaps, or your TFS build repository, etc.
Alberto Acosta • April 20th, 2011
Hi
When you work for a bank / insurances or another kind of secure environment you may have a strong proxy in the middle and every web request needs to be authenticated by user and password (Every tine you create a new web request the app you ask for user and password)
So can you fix that please? so buz user can use Nuget and webpi
I can help you to test that. thanks
Great job, keep up.
Coward • April 25th, 2011
1. It would be nice to have a package shared across multiple projects in a single package ie. "Add Library Package Reference" at the solution level.
2. Nuget at the moment seems to have some network reliability issues. After doing a "Add Library Package Reference" the 2nd time if I try to "Add Library Package Reference" then I keep getting the error message
The package source named 'Nuget official package source [https://go.microsoft.com/fwlink/?LinkID=206669]' is either invalid or not available and thus is currently unreachable.
Aeronaves • January 18th, 2012
I've seen so many) cases where a solution contains multiple project, there's only one main project and there's NO NEED to have multiple version of some library within the same solution.