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.
Related
So a little bit of history; I maintain a svn where, various repositories for applications and shared libraries all sit off root of the server
root
App1 (depends on ORMthing, UIstuff, Common1 )
trunk...
App2 (depends on ORMthing, UIstuff, OtherStuff )
trunk...
ORMthing (dempends on Common1 )
trunk...
UIstuff
trunk...
Originally, when a project depended on another project and made part of another solution, I used relative paths to walk down the folder tree and back up into my desired repository. This worked well enough because I could keep my working copies anywhere as long as they shared a common root path. Unfortunately I would have to go in and change all those relative paths whenever I wanted to create a branch, and some of the people that need to access to these solutions aren't very savvy.
So my solution: Use SVN external properties to nest the solution folder of referenced projects within my solutions. There would still only be one copy on the server, you can pull and update all the files required to build a solution with one SVN checkout, and it is easy to switch a referenced project from the trunk to a branch with one SVN switch command.
However there appears to be a problem when I have a situation like App1 above where it shares a common dependency with one of its other dependencies, ORMthing.
When ORMthing goes to compile, Visual Studio doesn't recognize that although Common1 is already part of the solution, ORMthing expects to find the dll for Common1 where it normally is, relative to ORMthing's project file. However this appears to be a bug the build process. When I look at the path property for ORMthing's reference for Common1 it shows the target path for the project that is owned by the solution and directly referenced by App1.
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 use Team Foundation Server for source control. All of my projects use a structure that have dev, main, and release branches.
For the purposes of this question, I have 2 TFS projects, one is my application and the other is a shared library. The solution file for my application includes the shared library project (even though it is in a separate TFS project) because it makes it easier to debug. So I have a solution in 1 TFS project pointing to a project in another one.
The problem I'm running into relates to branches. What I'd like to do is point to the dev branch version of the shared library when in the dev branch of my application's solution. Similarly I want the main branch version of my solution to point to the shared library in the main branch, etc.
Does anyone have ideas of how to handle this?
I can't tell you if this is the best way, but I'm pretty sure it will work if you don't come up with anything better.
Create a symbolic link between the two directories, and map the project using that.
Add a pre-event MSBuild script to delete and recreate the symbolic link for each build based on the current branch. For example:
rmdir MyProject
mklink /d MyProject c:\dev\Main\MyProject
You'll probably want to put this in a batch file and call that.
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.