I have a C# DLL that in turn calls a C library. How do I package these libraries in a NuGet package?
For example, I have two DLLs MyCSharp.dll and MyC.dll
How do I package both these DLLs so that when I add the NuGet package to a Windows Universal/UWP project, MyCSharp.dll is able to call MyC.dll successfully?
I tried adding copying the MyC.dll to the same folder as MyCSharp.dll during install time, but this doesn't help.
I was able to get this working by placing my MyC.dll & MyC.winmd libraries in the build folder of the NuGet package. See http://blogs.msdn.com/b/mim/archive/2013/09/02/packaging-a-windows-store-apps-component-with-nuget-part-2.aspx for very elaborate write up on packaging WinRT components with NuGet.
Related
I'm having a problem with NuGet producing different output folders when run locally to the version on my build server.
When I build my PCL project locally (using nuget 2.8.6), the folder structure within the nuget package is:
lib
- portable-net45 win wpa81 wp80 MonoAndroid10 xamarinios10 MonoTouch10
- HC.Common.dll
However when I build it on our build server (TeamCity, nuget 2.8.2) I get the following folders:
lib
- portable-Profile259
- HC.Common.dll
How can I ensure that both builds output consistent folder structures? It makes switching between the "published" version and my test versions quite tricky as the reference paths do not match between versions.
Is there a way to force nuget to use the short "Profile259" name?
NuGet will normally replace the PCL profile with the individual target frameworks if it can determine them.
On your build server it looks like you do not have the the PCL profile xml files installed so NuGet is not converting the directory. So I am assuming you are using NuGet pack YourProject.csproj. If you used NuGet pack YourNuGet.nuspec the directories in the .nupkg would be the same on both machines.
I do not know of any NuGet package that uses a PCL directory of the form portable-Profile78 and I am surprised this works but it seems to. All NuGet packages with PCLs have directories of the form:
portable-net45+win+wpa81+wp80+MonoAndroid10+xamarinios10+MonoTouch10
So to make them consistent on both machines you will need to either install the PCL profiles on the build server or use NuGet pack YourNuSpec.nuspec so that the directories are not renamed by NuGet.exe.
Is it true that for every dependency that a package has on some other library, that those libraries need to be resolved and installed as well?
For example, I created a package which uses NLog, Postsharp and WindowsAzure.Storage:
Do clients of my package now have to install these packages as well? Why is it not possible to include these dependency DLLs within the package?
When a consumer installs your nuget package, nuget will automatically resolve and install the dependent packages as well.
It is possible to include the dlls within the package but it is not recommended. Because one way or another they will have to have references to the dlls they need to use your package( in this case NLog, PostSharp and WindowsAzure.Storage). Its better that the consumer have controll over what libraries are installed.
Another benefit of having dependencies via nuget is that the consumer may decide to install a newer version of WindowsAzure.Storage library which he can do easily when you don't have the dll injected into the package. Otherwise you can get into some messy assemblies runtime errors.
You control what your package contains via nuspec file used to build the nuget package.
I've created a NuGet package that contains some custom MSBuild tasks named MyCompany.MSBuild. These tasks have a dependency on Newtonsoft.Json. This means that after my package is installed in a project, Newtonsoft.Json.dll will have to be in the same directory as MyCompany.MSBuild.dll.
I could easily accomplish this by bundling my own copy of Newtonsoft.Json.dll in my package, but I wonder if there's a better way that means I won't have to update my package whenever a new version of Newtonsoft.Json comes out.
If I declare Newtonsoft.Json as a dependency, NuGet will install that package into the project when somebody installs my package, which isn't what I want to have happen.
How can I specify a dependency in my package without having NuGet install it and add project references? Additionally, how can I copy that package's assembly to my own package's folder after it is installed?
A package with a "hidden" dependency is something absolutely undesiderable in my opinion...
I know it's not a real answer but... Have you considered to use JavascriptSerializer instead of Newtonsoft.Json? It's a bit slower but your package will be absolutely self-contained: less pain for you and for your users.
I have been using NuGet to manage my internally created assemblies for a few months, and it's working very well. I recently 'discovered' portable class libraries, which has also been great - until it's time to install the packages.
Say I have a PCL that targets .NET 4.5, SL5 and .NET for Windows Store Apps. I run nuget spec to create the .nuspec file, edit the values, package it up, and add the .nupkg to our internal feed. If I open the .nupkg file in the Package Explorer, I see one content folder under lib called portable-win+net45+sl50.
When I try to install the package from any compatible project in another solution, I get the following message:
"'Project.PCL' could not be installed because it is not compatible with any project in the solution. The package doesn't target any framework."
If I manually create the .nupkg in the Package Explorer, updating the version number, adding a lib folder for each targeted framework (not a portable folder) and added the Project.PCL.dll to each folder, I can add the package to the compatible projects in the solution. But to do this process every time I want to update a PCl is somewhat tedious (I had been creating a little .cmd file in the project root folder to quickly package and deploy).
Do other people have this problem? How can I package PCL's in the same way as other types of projects?
Note - I'm using VS 2012 Ultimate and NuGet 2.2
It sounds like maybe nuget spec doesn't work for Portable Class Libraries - that's worth starting a thread or filing an issue on the NuGet site.
However, you can also create a .nuspec file from NuGet Package Explorer. Just create the package as you already did, but then choose "Save Metadata As..." to save it as a .nuspec. Afterwards you may need to edit the source paths in the nuspec file manually, but you should be able to automate the creation of the package.
For me nuget spec and nuget pack worked fine with a portable project while creating the package and installing it on a compatible project.
Do you want to check if you have the latest nuget.exe (2.2), it can be downloaded from http://nuget.org/nuget.exe or can be updated by running nuget update -self
I understand how to build dll nuget package
I would like to build a JavaScript nuget package of my own. I would like to learn how jQuery nuget package being constructed/installed by nuget.
How do I know how jQuery (or similar nuget package) nuget package being constructed? Especially I would like to know how these *.js being copied/ installed to specific folder (scripts) of a ASP.net MVC project
Thanks
NuGet uses a convention-over-configuration approach. This is what makes it easy to inject some files (images, code, javascript, etc) into a specific folder of a target Visual Studio project.
You can simply open a .nupkg file with any zip-utility (e.g. 7zip) and extract the archive to see its contents.
A NuGet package can have 3 folders: lib, content & tools.
Anything in the content folder will be injected into the target project using the same relative path to the project root as to the content folder of the nuget package.
More info here: http://docs.nuget.org/docs/creating-packages/package-conventions
Also with respect to how jQuery or other similar Javascript libraries are packaged, here are some pointers.
The list of public jQuery/jQuery plugins that have been "NuGetified" can be see here http://nuget.org/packages?q=jquery The jQuery NuGet package page http://nuget.org/packages/jQuery has a note saying that it is maintained by the NuGet Community Packages project.
If you go to the CodePlex project at http://nugetpackages.codeplex.com/ and browse the source code, you'll find it contains a couple of sub projects. These are NuGet package projects for the respective open source (mainly Javascript) projects.
You will notice that they simply include the relevant pure Javascript packages, e.g. jquery-1.8.3.js, jquery-1.8.3.min.js, etc. in the Content/Scripts path.