Our first step is a MsBuild for our .sln file. We pass in our platform and config and everything is built correctly.
Next we want to NuGet pack all the files for Octopus Deploy to use. In this step we specify all of our .csproj files (not sure why, everything is already built)
The package that is created contains 2 folders, Content which contains all the files needed minus bin and the Lib folder which contains only the projects compiled dlls. It's not including any of the other dlls referenced in the project.
It sounds like it might be easier for you to use Octopack to handle the creation of the NuGet packages to be deployed.
Step 1. Install the Octopack NuGet package into the projects that are your deployable applications.
Install-Package OctoPack
Step 2. Ensure you have a build step before the main compilation that will install any referenced NuGet packages.
Step 3. Install the TeamCity plugin for Octopus deploy from the downloads page and restart the TeamCity server service
Step 4. You'll now see additional options in your MSBuild runner configuration and if you check the following box in your build configurations, it will produce a NuGet package for you which should have everything required for a successful deployment.
As a small tip, I publish the package straight to Octopus by referencing the output package (rather than waiting for it to be attached as an artifact at the end of the build and thus requiring two build configurations)
Hope this helps
If NuGet pack is not packaging your application as you expected from your project file, you have to create a NuGet spec file and specify how things should be packaged. For a web application that is as simple as creating a simple .spec file and putting it into your web application directory, but for other projects that can be a little more complicated. Check out the Nuspec Reference to see how to add your content and dependencies. https://docs.nuget.org/create/nuspec-reference
Related
I have a PS1 script that I use in all my projects to sign the assemblies. Until now I copied this file over to all my projects. Now I wanted to create a nuget package with the PS1 file.
I created a nuspec file and put the file in "content". Unfortunately nothing happened. Then I tried to put it in lib. Still noting happened. When I restore the package in my project no files where created in this project.
When I analyst the nupkg file with my 7-Zip the file looks OK. The ps1 file was in content, lib respectively.
I didn't found anything to this topic online. Can someone explain to me, how to create such a NuGet-Package?
When a project using packages.config installs a NuGet package, the package's tools\install.ps1 script will run. However, this no longer happens when the project using the package uses PackageReference (such as SDK style projects, used by .NET Core).
Similarly, the files in the content folder of the nupkg are copied into the project on install, but only when the project uses packages.config. PackageReference projects use the contentFiles folder in the nupkg, however the behaviour is different. Those files are copied only on build, not install, for .NET Framework projects and on publish for .NET Core projects. Probably not what you want for signing assemblies.
The feature you probably want to use is including MSBuild props and targets in your package. Note that the props and targets file names must match the package id exactly for NuGet to use them. You probably want to use afterTargets="build" at a guess.
How to author nuget packages required for a .net application in a Wix Setup? At present, we have 100 projects, each using different sets of nuget packages. And, we are manually adding a component for each assembly required for the application. This is very cumbersome, because each time we update a nuget package, we must update the .wxs file too.
Is there a standard way to automate this process of including nuget packages in wix setup? Or is there a workaround ?
There's a way to do this, you can call the wix harvester (heat) on your project's target directory and it will include everything in there. That command can also take an XSLT filter which ignores certain files if needed. You can call this command as a pre-build event in your setup project, or as a post-build in your actual project.
Here is a guide that shows the details: http://ahordijk.wordpress.com/2013/03/26/automatically-add-references-and-content-to-the-wix-installer/
I followed this blog post and I expected Nuget to just work. It obviously has not. I get errors on all of my third party dll's that I expect NuGet to update automatically:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\WebApplications\
Microsoft.WebApplication.targets (182): Could not copy the file "bin\AutoMapper.dll"
because it was not found.
I have set everything up correctly and I have ensured that the solution has Package restore enabled. If I delete a package locally and build, NuGet restores that package for me.
I am not sure why it is not fuctioning on the build server though.
Any Suggestions?
Try to add NugetRestore Activity to the TFS workfolw
Note:
For Team Foundation Build 2013 on-premises and Visual Studio Team Services (formerly Team Foundation Service), the default Build Process Templates already implement the NuGet Package Restore workflow without any special configuration.
I came across a similar error for log4net nuget package and I solved it in a different way. May be this will be useful to someone some day.
The error from TFS Team Build 2015
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\WebApplications\
Microsoft.WebApplication.targets (182): Could not copy the file "bin\Log4net.dll"
because it was not found.
Cause
The path to the nuget package in the .csproj file for referencing the package in the project cannot be found
Resolution
Edit the .csproj file of the project that has the error.
Look for the node ItemGroupin the .csproj file
You will see the HintPath pointing to a folder, most like the folder contain the name of solution as where it will file the DLL.
Replace the HintPath with <HintPath>..\..\Assemblies\3rd party\log4net\1.2.10.0\2.0\log4net.dll</HintPath>
You nuget package library may not be log4net but a different library. A very easy way would be to be edit the .csproj file of a project in the solution that contains the same nuget package library, copy the reference of the nuget in the ItemGroup and replace in the project that has the error. The reference should start contain ...\Assemblies\3rd party\ ... instead of a physical file location on your machine
I two computers, one with internet connection and the other one without.
I want to install a Nuget package (Nuget.server) with all its dependencies on the offline computer.
Unfortunately it is not possible just to download the package itself and I have to download all dependencies manually and there are dozens of them.
How can I create a package on the computer with internet connection that contains all dependencies?
Thanks.
I just went through the pain of this and wanted to find a solution using only the NuGet CLI. Turns out it's pretty simple really:
> nuget.exe install <PACKAGENAME> -OutputDirectory <OUTPUTDIR>
The key is the -OutputDirectory switch which makes the CLI install the specified package into a directory that doesn't have a project file in it. Running this command will download the package and all of its dependencies into the output directory, with each package put into a separate sub-folder. You can then grab all of the .nupkg from the output directory and do whatever you need to do with them.
Update: As Igand points out in the comments, the -OutputDirectory switch is not actually required. If omitted nuget.exe will just download into the current folder. Still best to not download it into a folder with a project file in it (unless that is what you're after).
I had a similar need, so I created NuSave.
Cache a single NuGet package with dependencies
nusave cache package "Newtonsoft.Json#12.0.3" --targetFrameworks ".NETStandard#1.0,.NETStandard#1.3" --cacheDir "C:\path\to\my-local-feed"
Cache multiple NuGet packages from a .csproj file
nusave cache csproj "C:\path\to\project.csproj" --cacheDir "C:\path\to\my-local-feed"
Cache multiple NuGet packages from an .sln file
nusave cache sln "C:\path\to\solution.sln" --cacheDir "C:\path\to\my-local-feed"
Restore & build a solution offline using my local cache
cd C:\path\to\my-solution
dotnet restore --packages C:\path\to\my-local-feed
dotnet build --no-restore
On the computer with internet access the NuGet packages (.nupkg) should be in the local machine cache. On Windows this is in the directory similar to:
C:\Users\YourUsername\.nuget\packages
So you should be able to copy the .nupkg files from there to the computer without internet access. I would create a directory on that computer and setup a new package source pointing to that directory. Alternatively you could copy the .nupkg files to the local machine cache, just be aware there is a limit of 200 NuGet packages in the cache. Then you can create a package source pointing to the cache.
Use the dotnet restore command with the --packages flag, which will download the packages to a specified directory.
dotnet restore --packages <TargetDirectory> <ProjectPath>
Ref: dotnet restore
Specifies the directory for restored packages.
A little late to the discussion here but I just ran into the same issue. I work with a medium size software development shop that works offline. Many new NuGet packages have very large dependency trees. Trying to walk the tree manually and download all required packages was very cumbersome. In the end, I wrote the NuGet Dependency Downloader. With it you give a package ID, optionally a version, and choose if you want to allow pre-release packages. After you click "Start" it will pull down the listed package and any dependencies it needs to run. As an example, when I put in "Microsoft.AspNet.Mvc" and selected "pre-release", this tool brought down 158 packages for MVC 6.0 RC1. Hopefully this will help those working in an offline environment.
https://github.com/StuffOfInterest/NuGetDependencyDownloader
In your csproj file:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies>
<PropertyGroup>
Or dotnet publish with all assemblies references.
I have recently started to build manifest files for the ETL packages by navigating to the project properties and setting the Create Deployment Utility to true. I was using batch files before this to deploy the packages, but can't run them anymore because I don't have enough permissions on the server after a new system roll-out.
The problem is that in some cases, I only need to deploy a couple of ETL packages instead of all of the packages under the project. When the project is built, the manifest file lists all the packages under the project that may or may not be required for deployment.
Is there any way for me to only include a couple of ETL packages in the manifest file instead of every package under the project?
According to MSDN, the possible option seems to be adding the necessary packages that should be deployed to a different SSIS project and use the deployment utility on that project.
Redeployment of Packages
Quote from MSDN:
After you finish updating the packages, you rebuild the project, copy the deployment folder to the target computer, and then rerun the Package Installation Wizard.
If you update only a few packages in the project, you may not want to redeploy the entire project. To deploy only a few packages, you can create a new Integration Services project, add the updated packages to the new project, and then build and deploy the project. Package configurations are automatically copied with the package when you add the package to a different project.