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.
Related
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.
This is a winform application.
All dlls, exe and some other extension files are copied to the StartupProject\bin through the post build events(VS post-build).
On TFS Server, the project has 2 subfolders: bin and src.(bin contains required dlls, but other extensions are missing -.png, .dat, .xslx).
On the server, the post build copied files appear under the StartupProject\bin, but they are not copied to TFSFolder\bin.
How can I force copy all the StartupProj/bin to the TFSFolder\bin?
Team Build use a different directory layouts from Visual Studio builds. All Binaries go in a single folder for any project built, so references are automatically solved and it is easy to copy the DLL to the final Drop folder.
You should use $(OutDir) MSBuild variable to properly reference the binaries directory in VS and TFS builds. See Is there a single MSBuild and TFSBuild variable that will point to where the binaries are? for some details.
If you need to use different scripts for desktop (VS) and server (TFS) builds, use the $(BuildingInsideVisualStudio) variable as explained in TFS 2010 Build Automation and post-build event.
I have a website, a windows service, and some shared class libraries in a single Visual Studio solution. I use Octopack on both the website and windows service, and on my machine these builds work as expected.
When using the TFS Build Server, the website nuget package is generated as expected, but the windows service nuget package contains all files from the website, as well as the service. E.g. it includes the _PublishedWebsites folder as well.
This is because TFS uses a single location to build projects.
What is the best way around this?
I know this question has since been closed, but I cam across this issue and solved it in a different way.
My solution is compromised of a number of websites and windows services and had the same issue of the OctoPack created nuget packages including all the solution assemblies from the 'pooled' output folder when building with Team Build. The reason the nuget packages get all the assemblies is OctoPack uses the outdir msbuild argument as the location to include assemblies from.
The way I got around it was to use the msbuild argument GenerateProjectSpecificOutputFolder=true. This instructs Team build to create a folder for each project in your output folder in the same way Visual Studio uses the bin folders under each project when building locally.
My build definition msbuild arguments looks like:
/p:GenerateProjectSpecificOutputFolder=true;RunOctoPack=true;OctoPackPublishPackageToFileShare=\\<NugetServer>
I currently just push the packages onto a shared folder but the OctoPackPublishPackageToHttp and OctoPackPublishApiKey parameters can also be used.
The benefit of this solution over the one above is you don't need to specify the files to include the nuget package.
Hope this helps someone.
I ended up using this nuget package to ensure the console app built to a seperate directory on the TFS server.
https://nuget.org/packages/PublishedApplications/2.1.0.0
I then had to specify in the nuspec file, which files should be included for the console app. e.g
This works and I can now deploy using Octopus deploy.
The downside of this apporach is that the PublishedApplications build only works on the TFS build server, so I can't build the project locally in release mode. Still looking on how to overcome this.
The packages created by a TFS 2010 Build only contain our Sources, not the binaries. When this is (automatically) deployed to IIS, the site does not run because it is missing DLLs that are created during the build process.
We have a Web Project created in VS2010. If I select "Build Deployment Package" from a right click in VS we get a zip file in the obj\Release\Package folder that contains the fully build site.
However, if ask our TFS build process to create the package by adding "/p:CreatePackageOnPublish=true /p:DeployOnBuild=true" to the MSBuild arguments (as advised in amongst other places here) we get an zip file in _PublishedWebsites\_Package\.zip that only contains the sources.
My best guess is that the CopyAllFilesToSingleFolderForPackage is picking up the files from the wrong place.
I notice a similar issue asked here - TFS 2010 and creating a package - although his workaround in not appropriate in many cases, I'd guess.
My concern is that this is using a built-in, but poorly documented feature of MSBuild/TFS so when it doesn't work you're a little in the wilderness.
It seems that deployOnBuild runs some "package"-like target on each of the projects. If you have built the projects into a separate directory (which the default TFS 2010 build does by default) the packaging won't pick up the compiled files.
One solution is to get rid of the custom output folder for the MSBuild Command within the TFS build workflow. This will cause the compiled files to be located in-situ and be included in the package.
Now the rest of the TFS workflow is require some changes because it'll be expecting to transfer the files from the output directory, and they won't be there.
I need some help to create a msbuild script.
We are using TeamCity 5.1.2, VS2010 (.net 4.0) and TFS in our environment. We have a "SharedLib" folder in tfs where we put those dll's that are used by multiple projects.
What we do is that we have a database project that handles db access and when we build that, a post build event copies the output dll to the SharedLib folder. Our "client" projects reference that dll from the SharedLib folder.
What I want to do is that when I check in files from the database project into tfs, the build is started in teamcity. If the build is successfull, I want to check out the database dll from the SharedLib folder in tfs, update the file with the new version and check in that file to tfs again.
How can I write a msbuild script that does that for me?
You can use the <EXEC $(TF) checkin ... /> command for that.
See http://blogs.msdn.com/b/nikhilsi/archive/2008/06/12/how-to-autoincrement-version-with-each-build-using-team-foundation-server-build-with-a-little-help-from-assemblyinfotask.aspx how you can use it.