Item 445 of 498 Previous | Next

48
Vote

Add 1st class support for assembly platform (x86, x64, ARM, Any CPU)

description

I have a number of 3rd party assemblies that I would like to use nuget with but they have native platform dependencies. Currently the only solution is to create multiple packages specifying the platform in the name, or, not use the lib directory and work some PowerShell magic so the package can contain multiple assemblies with different platform targets. "Multiple packages" is not an actual workaround since I wouldn't be able to take a dependency on a platform-specific package from an "Any CPU" package.

I would like nuget to support multiple assemblies from the lib folder based on the project's current platform target. For example, something like this would work:

lib\{framework name}{version}\{platform}
lib\.NetFramework 2.0\x86\
lib\.NetFramework 2.0\x64\

One approach that may work with nuget is to specify the MSBUILD $(Platform) variable in the project's reference hint path. For example:

<Reference Include="sbclient, Version=6.6.0.0, Culture=neutral, PublicKeyToken=371d4a7d6f5d7853">
<HintPath>..\lib\.NetFramework 2.0\sbclient\$(Platform)\sbclient.dll</HintPath>
</Reference>

No files are attached

comments

tusbar wrote May 2 at 5:16 AM

@dotnetjunky, I misread your question :

You're probably aware that some packages contain native DLLs within the `content` directory (often within content/lib, e.g http://nuget.org/packages/Sendgrid).

We sort of follow the same practice for our internal package repository and we find ourselves having to create a nuget package for each platform.

tusbar wrote May 1 at 8:14 AM

@dotnetjunky I do not have any specific examples.

I just repeated the whole directory structure of a nuget package within the platform dependent folders.

dotnetjunky wrote Apr 30 at 9:13 PM

@tusbar: Why do you think it's better to have lib/content/tools inside 'x86' and 'x64'? Can you list out the reasons?

JeffHandley wrote Mar 16 at 9:20 PM

Related to other target framework work items that have been cut from 1.8 and moved to 1.9.

mistachkin wrote Mar 12 at 7:13 AM

Also, it would be very nice to have an option (bool perhaps?) for either copying the platform specific files to the output directory (e.g. "bin\Debug") or to platform specific sub-directories of the output directory (e.g. "bin\Debug\x86" and "bin\Debug\x64"), based on the value of the option.

JeffHandley wrote Mar 8 at 8:58 PM

Related to http://nuget.codeplex.com/workitem/221

TripleEmcoder wrote Jan 3 at 9:02 PM

Sorry, I wasn't clear enough. Of course I know why we need platform-specific lib folders. I was asking about content as in "content" folder: x86\content vs. x86\lib - from @tusbar's post.

WayneBrantley wrote Jan 3 at 6:07 PM

Not my case, but first paragraph above shows use case?

TripleEmcoder wrote Jan 3 at 4:41 PM

@tusbar What would be the use case for platform-specific content?

WayneBrantley wrote Jan 3 at 2:50 PM

Maybe at the same time, support for release/debug builds could be put in.
http://nuget.codeplex.com/discussions/284030

mistachkin wrote Sep 29 2011 at 2:28 AM

This is also a blocker for System.Data.SQLite right now.

takekazuomi wrote Jul 14 2011 at 2:49 AM

What about native code library in nuget package ?

tusbar wrote Jul 2 2011 at 2:34 PM

I don't think that the `platform` folders should be inside the `lib` directory but there should be a nuget directory tree for each platform:

lib\ # <== shared between platforms
x86\lib\ # <== x86 specific, etc.
x86\content\
x64\lib\
x64\content\
x64\tools\
etc..

otac0n wrote Jun 7 2011 at 8:24 PM

This is a blocker for IronJS right now.

Sign in to add a comment or to set email notifications