I would like to create a dar file for a .net Project. I don't want to put all dependency to dar package. I have pack all dependency as nuget package and push them to nuget feed on TFS. I would like to use packages from nuget feeds, I don't want to directly put them in dar file. But, I could not find how to put reference for nuget packages which are located in tfs feeds.
Example: published nuget artifacts to tfs feed
In java, You can do same thing with maven/nexus. You can publish packages to nexus and you can use file URI of the packages in deployit-manifest.xml which are in nexus. You don't have to put artifacts directly into dar file. There is an example below.
<file.File name="common">
<targetFileName>common.jar</targetFileName>
<targetPath>/target/path/</targetPath>
<createTargetPath>true</createTargetPath>
<fileUri>maven:com.acme.temp:common:jar:4.0.0</fileUri>
</file.File>
Is there a similar approach nuget/tfs feeds for .net projects.
You can also use an http or https url to fetch the artifact (next to the maven notation):
https://docs.xebialabs.com/xl-deploy/how-to/add-an-externally-stored-artifact-to-a-package.html#use-an-http-or-https-uri
Related
So I have an Azure Artifacts feed. This feed has some packages. One if it is Newtonsoft.Json lets say 10.0.4 version. The feed is set up with an upstream source for Nuget.
When I add this feed to my project, my expectation is that when I want to get NewtonSoft latest, I would be able to get it. However, in Visual Studio or Nuget Restore, it fails to see any other version. The only version it can see is 10.0.4. I am expecting that since I specified an upstream source, it would get the packages from upstream.
I tried unlisting the 10.0.4 version, now it says newton soft is not even found.
What am I missing? What could be going on here?
For me that was a problem with permissions to the Azure Artifacts package repo.
If you are part of a group which has "Reader" access to the Azure Artifacts package repository, your nuget restores or npm installs (for JavaScript packages) WILL NOT be able to add packages to the Azure Artifacts package repository mirror/proxy.
Set the permissions of your teams/people with access to the Azure Artifacts package repository one level higher than "Reader" - set them to "Collaborator":
This is an error that's easy to miss since if you are the Artifacts package repo creator, you won't get any access errors other people might be having because you're the owner of the repo (in the picture below I'm Artur)
Once you've enabled an upstream source, any user connected to your feed can install a package from the remote feed, and your feed will save a copy.
If you add your Artifacts feed in the Package sources in Visual Studio. When you search for package NewtonSoft within your artifact feed in Visual Studio. It is the default behavior that you can only see the saved copy of package NewtonSoft.
To install the NewtonSoft latest, you can search and install it in the nuget.org package source(You need to add nuget.org to Package sources if it is not listed in the package source list )
Or you can use command line to install the NewtonSoft latest by specifying the version parameter. See below:
Install-Package Newtonsoft.Json -Version 12.0.3
You can also directly add NewtonSoft latest version as package dependency to your project by editting .csproj or package.config file. When you restore your packages. if the NewtonSoft latest is not found in your Artifacts feed, it will be downloaded from the upstream source.
I was wondering if there is a way to create one nuget package for multiple version of an assembly (i.e. dll v1.0.0 and dll v1.0.1), so that each version will show in the version drop down option in nuget? Or will I have to create separate packages for each version?(which is what I've have so far)
Thank you
How to set up nuget versions for multiple environment. Guess the nuget versions in your question stands for the package version not the version of nuget.exe such 3.3, 3.5 , 4.0. If it stands for nuget.exe version, have no idea why you need to use different nuget.exe versions for multiple environment.
You could version the packages as you need. A way to cross multiple environments is setting up 3 different NuGet repositories such as:
Development repository: A file share that all developers have read-only access to. The file share has a space for NuGet packages
and one for the matching NuGet symbol packages. Only the build server
(and the build engineers) have write access to this repository.
QA repository: Another file share similar to the Development repository.
Production repository: A private instance of the Klondike NuGet server which serves as the NuGet and symbol server for all NuGet
packages (and their sources) which are allowed to be used in
production builds.
More details please refer this similar question: NuGet Server for multiple enviornments?
I have a Restore Nuget packages build step as part of my vNext (onsite premises TFS 2015) build.
This step allows you to configure Nuget arguments.
Here I have configured the source to pull from a local network share, where we store internal Nuget packages.
-source "\\myNetworkShare\Nuget Packages"
However, we also use public Nuget packages, such as Postsharp, etc.
I want this step to resolve from multiple sources (or at least two).
1 being the internal network share, the other being the public nuget.org server.
How is this possible?
Adding multiple source is supported in one NuGet config file. Specify your custom NuGet feed URL’s and the public Nuget packages server's url in the solution’s nuget.config file.
You need to set up your own nuget server instead of a local network share to hold the packages. Detail ways about this please refer How to host your own NuGet Server and Package Feed
Next, just continue to execute the default NuGet Restore step from build task. Now all packages will be restored and can be continue with the build.
I'm looking for advice on how to have team build 2013 use a pre-compiled common that is not checked in or part of the workspace.
Everything we build is QNX based and we are refactoring out a common set of components to be shared across all projects. I've looked at Go and NuGet but that seems like a lot effort for something like this.
What is the best way to pull a prebuilt common into a TFS Team Build?
So you would nuget "publish" a package.
https://docs.nuget.org/create/creating-and-publishing-a-package
then your build would nuget restore using a packages.config file (aka, NOT a .sln file)
nuget restore [<solution>|<packages.config file>]
https://docs.nuget.org/consume/command-line-reference
What VS (in a .sln file) is auto-voodooing some of this for you.
But using command line nuget (especially for the restore)....is a way to get a package out of nuget if you're build isn't based on .sln file.
Another way to think about it is...when you run "nuget install" or "nuget update", VS is auto-voodooing you a packages.config file. While you might look at the file and find it interesting, you're not consumed on how it works in the background of VS. But if you want to manually pull nuget packages....you will be very interested in how it is created.
What I would do as a test would be:
Create a dummy .sln,csproj file.
Nuget add a few random packages (using "Manage Nuget Packages for this solution).
Take that packages.config that was auto-voodoo created for you.... and move it to a clean directory.
See if you can run nuget.exe restore on it, and get/pull the packages (aka, you're testing that you can do a pull... without a .sln file being involved).
If that works...than it becomes of matter of creating your own nuget repository..creating your own published-package...and repeating #4 above to get that package out.
Make sense?
So I have these files in a clean directory:
.\packages.config
.\.nuget\NuGet.Config
.\.nuget\NuGet.exe
.\.nuget\NuGet.targets
Then I run in the comamand-window:
.\.nuget\nuget.exe restore .\packages.config -PackagesDirectory .\MyPackages
And all the packages listed in "packages.config" will download to : .\MyPackages
Note, if you have a custom nuget repository, that will need to be configured...but cross that bridge when you get there.
Is there any Repository manager that manages the binary dll files and also integrates well with the Jenkins?
Can Nexus be used to manage the dll files as these files are created as a part of Embedded C/C++ Projects and not sure if Nexus Artifact Manager supports/integrates well with such Projects as it mainly supports the Java projects?
Is there a way to automatically manage the upload and download of such project artifacts from Nexus/other artifact managers without the use of POM file?
Suggest in case there are other Artifact Managers that supports binary artifacts.
Artifactory can be used to store any type of binaries.
Starting with Artifactory 4.0, you can create generic repositories which allows uploading packages of any type. You will not need to upload any POM files and Artifactory will not need to calculate any metadata (for example Maven metadata).
To deploy files you can use the REST API or the UI, for example:
curl -uUSER:PASS -T file.dll http://localhost:8081/artifactory/dll-local/path/to/file.dll
If you have a certain layout you would like to use for this repository you can create a custom layout and associate it with the repository. This can be useful for automatic snapshot/integration versions cleanup and other module management tasks.
Disclaimer: I'm affiliated with Artifactory
The Nexus repository manager is java oriented, but can be used to store any files you want. Binaries of all types or even just text configuration files.
To automate the file upload process, you can use maven from command line:
mvn deploy:deploy-file -DgroupId=com.you -DartifactId=file -Dversion=1.0 -Dpackaging=exe -Dfile=c:\out\file.exe -Durl=http://yourserver/nexus/content/repositories/releases -DrepositoryId=releases
Then, to get the file, you should be able to get it directly with the following URL:
wget http://yourserver/nexus/content/repositories/releases/com/you/file/1.0/file-1.0.exe
This is a simple approach to using Nexus as a general artifact repository.
I hope this helps.
The open source version of Nexus (Nexus OSS) is supports many repository formats out of the box including Maven, NuGet, NPM, RubyGems and others. Nexus just runs on Java (e.g. like Jenkins). It is not Java only...
Depending on how you plan to get the DLL files from the repository, different formats might be more or less suited to your usage. You could even use a custom format, but then you rely custom tools.
The scenarios I have seen at many customers are
using a Maven repo and pulling the files in either in a Maven build together with the Maven NAR Plugin (used for native development with C/C++)
using a Maven repo and pulling via plan HTTP GET calls using your scripting language/build tool of choice
using NuGet format and store the DLLs in NuGet packages in the repo and using nuget to retrieve them for the projects
All of these work well.