I've created NuGet package containing native x86 binaries. Binaries are copying to bin directory by MSBuild script from this answer.
But this approach does not work with DNX projects (ASP.NET 5 web app for example), because MSBuild script is not installing. So I have FileNotFoundException.
How to make it alive?
Solution for me was to make runtimes\win\native directory in NuGet package structure, as described here: https://docs.nuget.org/Create/uwp-create
In runtime DNX adds this directory to PATH variable, so managed dll can load it.
Related
I want to create a NuGet package that contains only javascript. I have no assembly that needs to be built and included.
So to do this I created an empty solution in vs, and created an empty project. In the project I created a Scripts directory with my javascript files. I have a package.nuspec and a packages.config
When I run "nuget pack" commandline I get an error:
C:\MyProject>nuget
pack
Attempting to build package from 'TestProject.csproj'.
MSBuild auto-detection: using msbuild version '16.1.76.45076' from
'C:\Program Files (x86)\Microsoft Visual
Studio\2019\Enterprise\MSBuild\Current\bin'.
Error NU5012: Unable to find 'C:\MyProject\TestProject.exe'. Make sure the project has been built.
C:\MyProject>
If I try to build the project in visual studio, I get an error...
Program does not contain a static 'Main' method suitable for an entry
point.
...which makes sense because I made this from an empty project.
I am not trying to deploy the assembly, just javascript, can I stop it from trying to build somehow?
Don't use a project. Have have your .nuspec and javascript files in the directory, then run nuget pack. If the nuspec doesn't contain a <files> section, then it will just copy the filesystem structure directly into the nupkg.
Having said that, new ASP.NET Core projects from Microsoft's templates no longer use front end resources (html, javascript, css) from NuGet packages, but rather use either LibMan or npm, to be more in-line with what the non-.NET front-end ecosystem uses. I suggest investigating those technologies and using them if possible.
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.
I am creating a NuGet package, which is a library DLL. I did this successfully.
However I would like to have a .NET exe (and its dependent assemblies) also in the target machine. It is completely OK if the .exe and these dlls are under the solution's package folder.
If it is possible I do not want to create a standard Windows installer and run it silently.
Thanks in advance
You'll have to edit your .nuspec file. You can include a element to include additional files in your package. Look at what else you can do by looking at the specs.
You can run your exe by creating a powershell script during package installation.
Starting from NuGet 2.0 a package can contain a "tools" folder. Here you can put exe, scripts and so on.
http://docs.nuget.org/docs/creating-packages/creating-and-publishing-a-package#Framework_Version_Folder_Structure
Binary under this folder will not be referenced, just copied on the machine.
Hope it helps.
I am looking to build projects on a build server (right now it is just a server but I want to use MSBuild to build projects on there). I want to use PowerShell scripts to get my code from a repository (Doesn't matter what type), put the source into a common directory, put all dependencies into a common directory (similar to how it is build in my workspace on my local machine), build everything and put all the deployable binaries into a bin which I will be moving to the deployment directories using other Powershell scripts.
I assume I am going to have to have MSBuild installed on the server that I will doing all of this on. Do I need to have the .Net framework installed on that server to accomplish this? Do I just need the EXE to have this work? Is there a good way to managed dependencies? Should I have them in a specific folder?
A lot of the core .NET assemblies are stored in the Windows Global Assembly Cache (GAC). You won't have to worry about those. Yes, you'll need the Microsoft .NET Framework installed, in order to compile (build) .NET projects. I believe msbuild.exe is included with the .NET Framework, so you'll find it under a location such as: C:\windows\Microsoft.NET\Framework64\v4.0.30319\msbuild.exe.
Your PowerShell script will have to copy any external dependencies (assemblies (DLLs and EXEs), .NET resource files, image files, external binaries, etc.) to the appropriate target location after compilation, such that the software executes successfully. You'll need to work with your software development team to determine [comprehensively] what those dependencies are.
MsBuild.exe moved, and is now part of Visual Studio as of v2013.
To get the latest version of MsBuild.exe without having to install Visual Studio 2013, download Microsoft Build Tools 2013
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