TFS 2010 Build Server and Microsoft.Practices References - tfs

I am busy trying to configure a build server for TFS2010. My project has references to Microsoft.practices. The build fails because it can't find these references on the build server - because I haven't installed the Microsoft.practices on the build server.
I was wondering if installing it on the build server is the best way to do it, or is there another way to add the 3rd party references when configuring the build server?
I know I can just install it, but I'm looking to follow best practices here.
Regards,
Byron Cobb

I would keep the referenced third party dlls in TFS within your project. Structured similar to:
/ProjectSolution
/ProjectA
/ProjectB
/lib
/3rdPartyLibA
/3rdPartyLibB
Now edit your build definition, in the Workspace tab, in the Working folders section, make a reference to you /lib folder in your project. The build agent will retrieve the 3rd party libs and use it for compilation.

A simple way is to check-in third party assemblies in TFS. You can add an additional folder to your TFS with a fixed relative path to your project. Then add references from there. This way you don't need to install 3rd party assemblies in your build agents. Additionally you don't need to edit your build definition too.

Related

Using TFS to output build definitions bin folder on CI build

I just started using TFS not to long ago and I ran into a slight issue. I have a class library project called EplanInterface.Addin. This class library project is used as a way to load functionality into a 3rd party program through their API. All of this is working fine but the issue comes into play here:
The Issue:
So the problem I am running into is that this Addin library is not referenced by any other projects but still needs to be output to my Drop folder within my TFS build. Typically to load the Addin into the 3rd party program I would copy the debug/release folder to the server and select/load the dll accordingly. My TFS build does not seem to grab the anything from the Addin though?
App.Config
Along with that I am using SlowCheetah to try and transform my app.config file resources correctly. Whatever solution provided I need to also figure out how to select a transform when doing the build configuration and output the dlls with the correct build configuration config file.
Build Definition
My build definition is the basic asp.net template they provide which works great for my web api and MVC projects. I guess I am unsure how to force it to also build the addin / output the dll files for my addin to reference?
Other Info:
TFS Version: 16.122.27102.1
Addin Project .Net Framework 4.5.2
Slow Cheetah Version: 3.2.26
You can simply add another build task to your pipeline to build the specific addin project and then have it output to the artifacts directory (as the default "Build Solution" task should already be doing).
The other option is to edit the solution file in Visual Studio and include the addin as a project dependency. You may still need to manage the binary output though.

Is there any way to include extensions in TFS build?

Nuget restorating is good when using CI in VSTS. However I am using some extensions like SQLite Runtime in my project. Is there any way to include those extension dlls other than referencing them in the project?
Besides referencing them in the project which actually is the most recommended way.
You can also manually install the extension on the build agent. Just like how to use it in your local environment. Make sure the environment on the build agent is as same as your local.
Check the extension and dlls in source control. Even though we do not suggest to manage dlls for source control in TFS.
Some packages (like redis for instance) have a "tools" folder which allows you to pull the "runtime" from nuget.
If your tool is not shipped as a nuget package you'll have either to:
- Include the tool on the source control (not the best thing if you want to keep the repo as small as possible)
- Install the tool on the build machine (only possible if you have your own agents and you're not using the hosted agent)
- Have a script to pull it from the web without relying on nuget (again really depends on the tool and if it has a "run without installation" version)
Hope that helps

Choose what goes to drop folder of TFS build

I have a drop folder created by TFS build which contains all the produced artifacts:
.dll \ .config \ .pdb files from all projects
_PublishedWebsites folder
*.msi files produces by Wix projects
All I really care about is *.msi files as everything I deploy is in them.
How can I specify for the TFS build not to bother with all the other files in the Drop folder?
I know I can customize the build to delete files after the solution build, but maybe there is a clever way of disabling them at all?
Personally I use named platforms such as Application and Setup in my SLNs so that when TFS archives the drop folder one class of files goes into one directory structure and another class of files goes into another. This way it's easy to find the MSI and it's also easy to see what the application code looked like before then. (Perhaps the contents of a web.config or an HTML that was added to the application sln but not the installer sln.
IF you want to suppress the application sln from archiving you have to look at that. It's not an MSI / WiX thing.
If you are using TFS 2013 (or VSO) you can easily have a PowerShell executed post build to do whatever clean up and rearranging you need.
Note: The build used the files in the root to do testing, code analysis, test impact analysis, and other automatic actions. Make sure that you only remove files after all of the checks. A better idea is to leave the files be and just push theb*.msi files to a "/_PublishedApplications/* folder.
There is a PublishedApplication Nuget package that can make this easyer. Take a look...
If you are using TFS 2010/2012 you can use the "TFS Community Build Tools" to call PowerShell and do other things.

How do I copy dll files for a build using team build

I have a bunch of external dlls I use in multiple projects. These dlls are referenced by these projects and everything compiles fine.
Now I am trying to get a Team Foundation Server build going for my projects. When I run the build, it complains that it can't find the needed files. How do I get TFS to find the needed files?
I was thinking I could use the copydirectory windows workflow function in a custom build template but I'm not sure if this is the right way to do things. Also, if I do use copydirectory, how do I reference directories that reside on TFS rather than on the file system? And where do I copy the files to?
Try this:(if using 2010)
At the Workspaces tab you can map the folder that has all the DLLs you want, just make sure you reference the assemblies in your project appropriately.
For instance, if your project is referring to the assemblies one level UP, before the project root folder, you may set the workspace like below:
$\Team Project\src -> $(BuildDirectory)\src
$\Team Project\dlls -> $(BuildDirectory)
Something like that should solve your issue.
There's also a way to do it in VS2010 build: You should add a copy command to the prebuild step for the project (select the project -> Properties -> Build Events).
If you want to use the windows workflow - template method, refer to this guide: http://blogs.msdn.com/b/buckh/archive/2010/01/21/deep-dive-on-windows-workflow-4-0-activities.aspx

Setting up a build definition where the source relies on third party assemblies?

My structure for TFS is such:
{Main TFS Project}
3rd Party Assemblies
Development
Source
Integration
Source
I am using continuous integration for my development build, but currently I have to setup the working folder so that I am pointing to: {Main TFS Project} root folder. This is not ideal, because any check-in to the system kicks off my Development continuous build. I don't want to have the 3rd party assemblies in each branch, because they are shared throughout projects. What are other users doing?
Update
Before I wrote this message I had tried what kroonwijk had suggested, but my build still fails. this is what my work folders section looks like:
In the build definition, you have the ability to specify multiple folders to be downloaded to the build system when the build starts. From http://msdn.microsoft.com/en-us/library/hh190721.aspx:
When you create your build definition, on the Workspace tab, you
specify the folders that contain the files that you want to download
and how these folders should be mapped to local folders on the build
agent.
So just specify your 3rd Party Assemblies folder together with the Subproject folder you want to build in the Workspaces tab of your build definition, and only those folders will be checked and build.

Resources