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.
Related
I have spent the last week trying to get my TFS Branch / VSO / Azure Release Branch Continous Deployment setup, but have failed miserably. Right now I am just trying to get CD working with out branching, I have it pointed at my solution but I am falling over myself on the obj and bin folder. If I exclude the bin folder from the project it complains because it cant build the project. I can't get tfignore to work, if I change the folder it still tracks the changes.
I have a folder structure of:
\Dev\Web\Umbraco Master Solution\Umbraco.Extensions\bin
\Dev\Web\Umbraco Master Solution\Umbraco.Extensions\obj
\Dev\Web\.tfignore
my tfignore includes the lines:
\Umbraco Master Solution\Umbraco.Extensions\bin
\Umbraco Master Solution\Umbraco.Extensions\obj
I'm not really sure where to go from here.
It is almost always a bad idea to checkin your bin folder. If the build fails when you exclude it, that likely means you have a DLL that is referenced from the bin (also not good). You should use Nuget packages where possible for your dependencies. Its easy to make your own if needed. Or you can place the DLLs you need to reference in a different folder at the root of your solution and referenced those instead.
I am assuming you would like to check-in the Bin of the project you are referencing. when you set up your build, you have to select a configuration to build. Make sure that the configuration you are building has the project you are referencing set to Build.
I agree with chief7 that it's a bad idea to check in your bin folder.
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 am currently working on a project which is included in a versions(svn)repository. Although I'm not sure, I think I might have changed some settings in Xcode, affecting the way the source control saves the build folder in the repository. I was told it is a bad practice to commit the build folder, and asked why have I done that, but I had no answer at the moment. A screen will elucidate this more clear:
Even if I tried to delete (or ignore) those files from the repository, they are still created after I build the project. How should I proceed in order to prevent those build folders appear in versions' project tree?
Adding versioned folder to ignore-pattern does not affect data in SVN
You must ignore and remove folder from SVN, but keep it locally
For CLI it will be svn pe ... in the parent of build folder and svn rm build --keep-local (I don't know XCode GUI's equivalents)
I have two database projects DB_A and DB_B. Project DB_A references DB_B.
I added a database reference by pointing to DB_B.dbschema at
C:\SourceParent\DB Projects\DB_B\sql\debug\DB_B.dbschema
When I build project DB_A on my local machine it works fine.
Now I want to build this on my TFS build server, but I get the following error
File D:\Builds\SourceParent\Build_Name\DB_B\sql\debug\DB_B.dbschema does not exist
I have a build for DB_B on my build server, but it's at a different path (the build definition doesn't necessarily match the project name).
I think I could add a build event in my build definition to copy the .dbschema file to the correct location on the server, but I'd rather not do this. (This would require a special build template for each build definition.)
Is there some way I can make the TFS build point to a different location? Or some other nice way I can accomplish this?
I solved this by creating an environment variable $(DB_SCHEMAS) pointing to a directory on my machine (e.g. C:\dbschemas).
Then I added a post build event in project DB_B to copy DB_B.dbschema to $(DB_SCHEMAS).
I then added a database reference in project DB_A pointing to $(DB_SCHEMAS)\DB_B.dbschema. Note that Visual Studio will add this reference using a relative path. To fix this, I unloaded the project in Solution Explorer, and edited the hint path to use the $(DB_SCHEMAS) environment variable.
Now I just added this environment variable on the TFS server and it will work as expected. Building project DB_B copies its .dbschema file to $(DB_SCHEMAS) (wherever that may be) and then building project DB_A references this scheme.
The only downside is that my teammates all have to add this environment variable on their machines as well, otherwise they can't build locally.