In my TFS 2017, I have two team projects collection. The first collection generate nuget packages in its collection nuget feed. I would can restore this packages from a project's build that is in the second team project collection. Is it possible and how ?
When I restore I have a 401 error and I don't see how to add permissions to restore from other collection projects.
Yes, it is possible. Adding the feed in Nuget.config file like the sample below in the second project and specify the Nuget.config path in your build definition
<packageSources>
<add key="TFSFeed" value="http://tfssetver:8080/tfs/teamprojectCollection/_packaging/TFSFeed/nuget/v3/index.json" />
</packageSources>
Make sure you are running the build agent under the account that can
access the feed.
Related
Hi I want to build my Wix-Project on my TFS-Server.
I checked in a local copy of the wix-binaries - which are looking good.
Now i want to reference my local copy in my wix-v3-project like that:
<PropertyGroup>
<WixToolPath>$(SourceCodeControlRoot)\wix\[[Version]]\</WixToolPath>
<WixTargetsPath>$(WixToolPath)Wix.targets</WixTargetsPath>
<WixTasksPath>$(WixToolPath)wixtasks.dll</WixTasksPath>
</PropertyGroup>
It is described here: Link
But it tells me that - WixToolPath is an unknown node. So how can i reference my local wix toolset? And also what do i need to reference so that it can build only with my local copy on the toolset.
My main target is - to not change the tfs agent - to make wix working.
EDIT:
This is working in v4 - how can i achieve this in v3?
I dont think that's the right way to do this, avoid checking-in the binaries to source control when possible. Here is a list of steps that you can do:
Change the Nuget.config to point to your local Nuget repo. If your TFS agents have internet access and go to the nuget repo, then it can point to the web nuget repo as well.
Check-in the Nuget Config/Nuget.exe file to TFS (you can avoid this step, if you have access to the TFS agents or if you have Nuget on it already).
In your wix solution/project, add the WIX nuget package as a reference and then check-in those changes to TFS.
Within your build script, before you compile the wix project add a step to do the Nuget restore based on the packesg.config/wix solution file.
I have a solution with bunch of C# projects with bunch of tests. Some of these tests require few native dlls (provided by related nuget packages). To address this .testsettings file was created that is copying dlls (that nuget coped to $(OutDir)) to test directory before running tests.
All this works fine on local machine, but when executed under TFS Build 'deployment' section of .testsettings file (or maybe entire file) gets ignored -- these dlls never materialize in test directory (nor there are any entries in the logs about them). .testsettings file is mentioned in related section of TFS build configuration.
Any ideas what could be wrong? (MSVC 2015, TFS 2013)
For TFS 2013, it only has XAML build. For XAML build, the testsetting file couldn't copy the assemblies from Nuget package $(OutDir) to the C:\Builds\...\builddefinition\...\TestSetting(tst)\...\Out folder before tests run.
I suggest that you could upgrade your TFS to TFS 2015 or upper version to use VNext build. And I have already tested that in Vnext build, it works. This is my build definition example: just add 3 steps.
Have you try to see if they are installed on your TFS server?
Did you check on GAC of the TFS server if they are registered?
Bellow is an explanation of how I deal with my dependencies, hope it helps.
This is my HMO about this topic. Must of the time I avoid to give the responsibility to the TFS to restore the NuGet packages in a separate folder.
How I do that?
1- I create a separate folder at the level of my project. (Common)
If you see on the bottom there is a Nuget.config file. Bellow is the configuration it has
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<config>
<add key="repositoryPath" value="$\..\Common\Packages" />
</config>
</configuration>
Now all my Packages are hosted inside Common folder. Now, place all you extra dlls there in a separate folder if you need. If you depend on native dlls that are hosted on the GAC, then you should take a look on the TFS Server if those are installed there.
With that said, I put all my project reference pointing to my Common folder, even my Nuget Repository is getting the files from that location also.
The advantage:
you centralize all your dlls(remember if you depend on a Native dlls, you should install on the TFS the version of the Framework you need in order to run the MSBuild correctly)
all projects point to the same dependencies
you just mantain the Common folder.
Once you check-in a package inside the Common folder, you are guaranteeing that the dependency is also hosted on the TFS, and when the MSBuild runs it can find them.
I used NuGet to add CastleWindsor to a project. Eveything works ok.
When I check it into tfs, I get the following message.
Unable to find version '3.3.3' of package 'Castle.Core'.
Any idea how I can get the build server to get the new version of Castle.Core?
First just as Dave commented, please check if you have add the nuget install task in your build definition and before your build task.
Also make sure you are using the right version of Nuget. For example, if you already use V3.0 and the config file are still point to V2.0. You will get this error.
Moreover, double check if the packages can be restored successfully on you dev PC and build agent manually, you can also compare the nuget.config file on your TFS server and dev PCs to see if there is any difference between them. The nuget.config file locates at "%APPDATA%\NuGet\NuGet.Config".
TFS2012 does not restore the nuget packages automatically, you need to add a build step to call the nuget command to restore the nuget packages. Refer to this link for details: Package Restore with Team Foundation Build.
With TFS 2013 and later, packages are automatically restored by
default during build, provided that you're using a Team Build Template
for Team Foundation Server 2013 or later.
If you're using a previous version of build templates (such as in a
project that's been migrated from earlier versions of TFS), you'll
need to also migrate those build templates to TFS 2013. This
essentially means recreating the custom parts of the Build Templates
using the appropriate template for your source control (TFVC or Git).
For earlier version of TFS, you can simply include a build step to
invoke command-line restore as described earlier.
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.