The folder "Batch" and all of its contents get output to the build directory at build time. "Batch" does not appear to be part of the solution.
The folder "Config" does not get output to the build directory at build time, even though I added it to the solution (I assume it would if I added it at the project level, but I don't necessarily want it to be part of any of the projects).
A few questions:
Why does "Batch" get output when it's not part of the solution at all? I looked at the build template specified in the build definition and don't see it configured here either.
Why does "Config" not get output to the build location even though it's part of the solution? I'd like it to get output to the same location as "Batch" at build time.
Thank you for any help.
If you are using XAML build. First make sure you are not cloaked the config folder in the build definition. Details please refer Work with build workspaces. For vNext build, it's Repository --Mapping -- Cloak.
If the folders are cloaked in the build definition, they will not even get sourced during the build process. Definitely in the build output.
Go through the build logs with more details such as diagnostic mode in XAML, system debug = true in vNext to see if there are some useful info.
Moreover, also try to build the solution locally to see if got the some output.
Related
I want to attach some file as option in TeamCity 8.1 Build Run dialog form.
Before start build this file must be copied into defined place on the Agent side.
Who knows, is it possible? I can't find any plugins for it.
Tnx.
Where does this file normally reside? ie: where would TeamCity get it from?
Where should this file be copied to on the build agent? Can it be placed in the sandbox (work folder) for a given project?
If the file is stored in source control, you can specify a VCS root to get it copied over to the sandbox the same way you specify a VCS root to get the source code you wish to build copied to the sandbox.
For our projects, we regularly specify two VCS roots for a single project: one to copy some scripts and utilities our build requires and one to copy the actual source code that needs to be built.
Hope that helps!
I have recently added a TFS build to our project, and configured it to run the automated tests that are in the project, and for some reason the build is ignoring the tests as if they don't exist!
In order to figure this out I created another solution with only a basic project from the origin code and the test project as well.
I've added these to the TFS and configured an almost equal build to this solution, and guess what? it executed the tests! it's the same tests as the original. just a copy of it.
The main difference between these 2 solutions is that the original code is a big solution with many projects, most of the projects are in some kind of a solution directory (and so does the tests project - it's inside a solution directory as well).
The difference between the TFS build definition is only that the output location of the build is set to single directory (I also tried PerProject and it worked) and in the original code it's defined to "AsConfigured" because we have some build tasks for copying dlls and such.
Has anyone encountered this problem?
Any ideas?
Thanks
TFS will look for the test DLLs in the BINARIES output folder location. You need to configure your 'build tasks for copying DLLs' to ensure your test DLLs are copied to this location.
Test assembly file specification
Specify the binary files that contain the tests that you want to run. Leave the default value (**\**test*.dll) if you want the build agent to search recursively for any .dll files that match *test*.dll in the binaries subdirectory of the build agent's working directory.
TFS2013 — http://msdn.microsoft.com/en-us/library/ms253138.aspx
TFS2012 — http://msdn.microsoft.com/en-us/library/ms253138(v=vs.110).aspx
I'm sure this is a dumb mistake on my part but I can't find the right answer.
I have a project that has a snapshot dependency on another project. For sake of discussion website is dependent on toolkit.
Monitoring the build folder:
c:\programs\Teamcity\buildagent\work
I see the toolkit get built and the folders all exist as expected:
c:\programs\teamcity\buildagent\work\toolkit
Then the website build kicks off and the folder above gets deleted before the website build starts.
This results in the website saying the reference couldn't be found. What setting am I missing?
Using TeamCity 7.1.2, working on getting it upgraded to 8.1 but it requires some internal evaluation first.
Don't think its a version issue. How do both of your builds know where to put the artefacts at . For ex teamcity normally builds stuff at c:\programs\teamcity\buildagent\work****\toolkit , not at c:\programs\teamcity\buildagent\work\toolkit ?
Also, if your targets are dependent upon each other across builds, (1) have you setup any artefact dependencies or (2) any process that does not read of a shared agent workspace ? or (3) forcing both builds to run from the same directory
See if both your builds are running on the same target "folder name". In case they are , deselect any option that "cleans up build targets" before they run.
Also, you might want to check your build files to see if they have any code to clean directories before they start to run
I'm just looking at streamlining the nuget packages that are coming out of my build system and I'm stuck on how to only package the files that are required.
I have several configurations sharing a Root VCS checkout. I have a configuration that runs a debug build with unit tests. I also have a release configuration that does a release build, this configuration then also uses the TeamCity OctoPack plugin to create the nuget packages.
What I want to achieve is the building of nuget packages that don't contain the *.pdb and *.xml documentation files as these aren't required for the release deployment.
I've looked through this page on the OD site:
http://docs.octopusdeploy.com/display/OD/Using+OctoPack
And according to this page OctoPack should only package up the required files by default. I'm not entirely clear on how or what needs to be done to get around this problem as it doesn't appear to be working as described.
It seems that one solution would be to provide a nuspec file for the projects I'm looking to deply but I'm also wondering if there is something I'm missing before I head off down that route.
I also have some MEF plugins that are copied in post build events and these aren't included in the nuget packages when in fact they are needed for the application to run. I think I need to get explicit with a nuspec file but would like to confirm this.
What is the simplest way of achieving what I need?
Assuming you're running the later versions of OctoPack, in your release build you can set a system parameter system.DebugType = None which will get passed to the OctoPack build scripts and prevent the PDB's being created.
This simply overrides the setting defined in your csproj msbuild file (assuming C#), so you can use it wherever you want to prevent PDB's being created at the build configuration level (not just OctoPack). I generally prefer this approach as it prevents side-effects in your build from changes by developers in the project file.
As for the xml files, I haven't actually tried this, but you can try a similar approach and create a system parameter system.DocumentationFile = "" to blank out the output.
If you really want to make sure that the files have been removed there are a couple of ways you can do this. Modify your deployment process to:
Execute your own custom PowerShell script in that removes the files
Include a script module from the Octopus Library to the same. Check out the File System - Clean Directory from the Octopus Library
I have a scenario like that described here.
Unfortunately, the solution doesn't work for me. My build project has a folder named bin where all external DLLs are stored and referenced. The problem I'm having is this: the bin folder is created under the working folder when queueing a build, but it's empty and consequently the build fails.
Any idea why this would happen and how to go about fixing it?
EDIT - Everything is checked into TFS and the build definition workspace is set to two levels above the bin folder. The working folder above refers to the build agent working folder (as opposed to the build definition workspace).
I'm not sure what the linked question has to do with your bin folder problem description.
But if you have stored binary dependencies in your bin folder (bad practice), you just need to make sure that they are checked into TFS, and the build definition workspace mapping includes that bin folder (or one of it's higher level ancestors), and the Get that happens at the start of the build process should download whatever is in TFS to the build agent.
It's important to note that the TFS Build by default doesn't output into the bin/debug folder, but that shouldn't matter for picking up references.