12

Closed

Enable filtering by framework on list-package/GUI

description

SPEC: http://nupack.codeplex.com/wikipage?title=Target%20Framework%20Support

Allow the filtering of packages by framework (top level) on list-package/create package reference GUI. Ideally this will filter down by default to the framework you're currently listing (so if you have a ASP.Net project then it should filter out Silverlight packages and other packages but leave .Net specific packages). The image I have included is what happens when you try and add a package that doesn't sync up to the framework (I was trying to add a MonoDroid framework package to a WP7 project - unfortunately this won't happen when packages simply use the /lib/*.dll package structure.

ChrisNTR

file attachments

Closed Jun 25, 2012 at 5:20 PM by howarddierking
fx targeting within package layouts is fixed. There's another issue tracking the CPU architecture definition at http://nuget.codeplex.com/workitem/679

comments

Haacked wrote Oct 14, 2010 at 11:36 PM

I've been having some discussions on this. Right now, we're leaning towards making this solely a filtering feature and wouldn't block you from installing a package from another framework. The reason is we think most developers know what they're doing if they turn off the filter and we shouldn't block them. They may have a good reason. Or, maybe they removed the project type.

Here's the preliminary spec. No promises for v1, but I know of someone who's prototyping it already. :)
http://nupack.codeplex.com/wikipage?title=Target%20Framework%20Support

runxc1 wrote Oct 15, 2010 at 3:45 PM

I agree with Haacked I would like full control when applying packages. I think that all packages should report what framework version they target as I can see multiple nupacks for the same library just targeting .Net 2.0/4.0/Silverlight etc.

Grauenwolf wrote Oct 18, 2010 at 11:57 PM

Please make sure you consider more than just the framework version. Many of the third-party libraries I use also have the requirement that they only against x86 builds because of COM or p/invoke calls.

Sign in to add a comment