I am using VSTS vNext build system to build a C# solution.
Below you can see the settings for the NuGet Packager. The path to nuspec files is set to reference the .csproj files.
However this includes all .csproj files; I need to exclude test projects. Ignoring 'Core.Test.csproj' but still packaging 'Core.csproj'.
I have tried '*.csproj;-:!*test.csproj' and other combinations but have had no luck figuring this out! Does anyone know how the pattern matching works for vNext build?
**\*.csproj;-:**\*test.csproj should do it (no exclaimation point needed). If not, we may have a bug, and you should file it on GitHub.
The latest version (2.x) of the NuGet task in VSTS and TFS 2018 uses a different pattern for excluding packages. Now you use ! instead of -:.
So **\*.csproj;-:**\*.Test.csproj changes to **\*.csproj;!**\*.Test.csproj.
Full pattern matching documentation can be found here.
Related
I'd like to be able to automatically update the assembly version off all changed projects on a TFS check-in. We'd like to do this as part of our gated check-in so that developers don't have to remember to manually update those numbers on every check-in.
My current approach would be to:
Determine what projects contains changes on check-in
Check out the AssemblyInfo.cs in each project with changes
Increment the version number in each AssemblyInfo.cs file
Begin build process
I assume there is a way to accomplish this using a combination of PowerShell and customizing the TFS build template, but have little familiarity with either. Any help on the matter would be greatly appreciated.
Use the script located here as a pre-build script in your build template.
The script will change all AssemblyInfo.cs files that are found with the build number.
How to update assembly version of your projects using PowerShell scripts. A very good guide.
The answer is bit late but you can find a good guide here , Have a look into that
I've been resorting to manually modifying my .nuspec files every time I update packages. Is there an automatic way of doing this? I'd rather not have to create an additional build step that compares both files and syncs them.
I believe MyGet does this OOB, but unfortunately I can't use MyGet for this specific package.
(FWIW, I'm using VS2015 and Xamarin Studio)
Just call the nuget pack against the csproj instead of nuspec, for example:
nuget pack X.csproj
In addition, you'll have to remove the dependencies from the nuspec, otherwise nuget will get it from there instead of from packages.config.
BTW, check the created nupkg. It may have unwanted files added to it, like, for instance, txt files, if you happen to have any in your project.
If that's the case, you'll have to invoke nuget pack with the -Exclude parameter:
nuget pack X.csproj -Exclude **.txt
I ended up creating a quick C# script (LINQPad rules) that syncs .config and .nuspec using XDocument, NuGet.Core and LINQ. If anyone's interested, I'll post it as a gist.
I'd like to check in assemblies to TFS source control after successful project build on TeamCity. Are there any elegant and easy way to do that?
I can create a command line step and run tf.exe with parameters, but then I need to provide credentials to connect to TFS, map the directories and finally do the check in.
The second option is to set up the powershell step, and use one of the cmdlets, but this requires installation of cmdlets on the build machine which I don't want to do.
Have you got any experience in such case? Maybe I can use the credentials used by TeamCity to get the sources, and do not map the directories but use the downloaded structure / sources?
This answers your question but it is not normally a good idea to commit binaries to your source control. You have a couple of choices.
Create a nuget package manually:Nuget Packages can be stored in a
shared folder. You can manually create a package in 5 minutes.
If your other projects are built using teamcity, check out artifact
dependencies in teamcity.
TF.exe commandline tool is the best feasible option for this scenario.
I have a solution that contains shared projects with nuget package restore.
I have a second solution that references projects from the first solution.
I am trying to set up TFS to build the second solution, but it doesn't find references for the projects in shared solution because the packages folder for the first solution is in a different location than that of the second solution. I've included the first solution in the build, but now the build configuration doesn't exist in that solution.
First of all, it sounds as if the shared projects could be packaged themselves and as such be shared across these two solutions.
However, if you really don't want to do that, you might try the use the following NuGet commandline parameters and tweak the nuget.targets file in such way that they both point to the same package install directory. (note: you'll have to manually update the project references as well to point to the new packages location)
nuget.exe install -o "d:\some\dir"
You can simply modify the element in the nuget.targets file, or add this element in the csproj file's PropertyGroup with your own custom value.
<PropertyGroup>
<PackageOutputDir>d:\some\dir</PackageOutputDir>
</PropertyGroup>
One last remark: the output location path has to be the same on the client development machine as on the TFS build agents or it won't work.
NuGet newbie question-
I saw repositories.config being added in NuGet packages folder.
Can anyone please guide me what is the purpose of this file?
Thank you!
It's a file that's mostly a NuGet implementation detail, and should not be dealt with directly (it may go away or change in the future).
But for reference, it contains a list of paths that point to all the packages.config in the solution. Typically there is one per project that uses NuGet.
David Ebbo's answer is from 2011, and the official advice keeps changing between versions.
Here's where we stand in 2015, for NuGet 2.7+ with the 'Automatic Package Restore' (recommended) workflow
I'm paraphrasing, but basically the advice is:
Remove packages/repositories.config from source control. We'll re-generate it anyway.
...unless it somehow breaks on your machine. Then do add it to source control.
This hint comes from the section on ignoring files in git:
# Ignore NuGet Packages
*.nupkg
# Ignore the packages folder
**/packages/*
And the important part:
[...]
# Uncomment if necessary however generally it will be regenerated when needed
#!**/packages/repositories.config
You need to include the repositories.config file in your source repository if you are following the Automatic Package Restore work flow.
Have a look on http://docs.nuget.org/docs/workflows/using-nuget-without-committing-packages where it specifically mentions this point.