Deploy Custom Build Activity to clients - tfs

When creating Custom Build Activities for TFS 2010/2012 it results in assembly (dll) files which can be used in build definitions.
When developing locally you place the assembly in the GAC or Visual Studio probing folder. For the build controller you place the assembly in source control (TFS) and tell the controller where to look.
All fine and working nicely.
The thing is that other developers (quite a lot) on other machines will need this assembly also when starting new builds. How do you deploy new versions of this assembly?

Assemblies are retrieved from TFS source control location defined for controller to tmp folder for Visual Studio and loaded into scope when opening build definition for edit (and probably when you open queue dialog).
You need assemblies in GAC (or VS private assemblies folder) if you are editing template itself, adding xaml template to activity project allows you to bypass GAC but will mess up namespace imports in xaml resulting in errors in tfs.
Another caveat is that if your activity assembly is using another library assembly this 2nd dll may not be picked up correctly - workaround is to add a fake empty activity to library.

Related

ASP.net 5 wwwroot source control (TFS) ignore compiled TS Files

I have my grunt file building the TS files and placing them in to the wwwroot folder. TFS/VS Keeps thinking that they are new files and adding them to the pending changes.
How do I make is so this is not happen. I only want the TS file in source control.
Update:
I have tried using .tfignore file
# Ignore all files in the wwwroot sub-folder
\wwwroot\
TL;DR
If you want to do front-end dev in Visual Studio 2015, don't use the ASP.NET 5 project template. Use the ASP.NET 4.5.2 Empty Web Project template. NPM, Bower, Gulp, Task Runner all work there too. Just add the appropriate config files through the New Item dialog (NPM Configuration File, Bower Configuration File, etc.).
Though ASP.NET 5 was released with Visual Studio, it is still very much beta. That doesn't only apply to the server-side features. The VS project type is also not ready for prime-time. The project properties are very limited in the UI. You can't choose to exclude items from the project. package.config exclusions don't appear to affect anything. VS doesn't behave with TFS on these projects and performs a TFS ADD on any generated file. This means that if I don't manually fiddle with TFS changes, eventually gulp builds will fail because it will want to make changes which TFS will block (e.g. delete when there is already a pending change).
All in all, the ASP.NET 5 project type is not full baked just yet. Fortunately, the only thing it really provides over the 4.5.2 project (that I've noticed) for the front-end developer is the Dependencies node in the project tree. That has some utility, but is not worth the cost currently. Instead, I installed the Visual Studio Command Line extension, which makes it convenient to run bower and npm commands as needed. I had to do this anyway for tsd (TypeScript definitions) since it doesn't have a GUI, intellisense, or bindings for its config file.
Add a .tfignore file. Details here: https://msdn.microsoft.com/en-us/library/ms245454.aspx#tfignore
You are using a Web Site project type and not Web Application.
Web site is only provided for legacy support and does not support features added to visual studio after... Well.. For a very long time > 5 years. Web site projects are inherently greedy with files and this is by design and can't be changed.
You should upgrade your project to a web application by creating a blank web application and doing the core files into your website and then opening it in vs. You will see that it has no files and you need to manually tell it which files to load.
This was a bug in the asp.net core tooling/TFS souce control interaction and has been fixed in VS 2015 Update 3, where the .tfignore file instructions should now be honoured:
https://github.com/aspnet/Tooling/issues/18

TFS custom build process activity assemblies per branch

What do I do if I want one TFS 2012 build controller to have access to two versions of the same custom build process assembly (one for each of my branches)?
I have one build process template per branch, and one build definition per branch. Each branch has it's own custom build process assembly, but they all have the same assembly name and namespace (e.g. Company.Build.Activities.dll). (I realize I could make all of this go away by having different names for each branch's assembly, e.g. Company.Build.Activities.Dev.dll and Company.Build.Activities.Com.dll)
My build controller points to one location for "Version control path to custom assemblies" ($/Build/ForTFS). I tried putting the two assemblies under different subfolders, but the build process causes an error:
TF215097: An error occurred while initializing a build for build definition \Company\Dev_BuildDef:
Exception Message: Cannot set unknown member 'Company.Build.Activities.LastActivity.CustomFolderPath'. (type XamlObjectWriterException)
It seems that it's using the wrong copy of the assembly (CustomFolderPath is only defined in one assembly, not the other).
I think I could resolve this if I could specify the path or required assembly version in the template xaml, but I am not sure I can do that. I have read posts that suggest that you can add a reference to the specific assembly version in the Visual Studio project you are using to edit the template. But that didn't seem to work for me, and how would the build process definition know about that project's references... it only points to the template file itself, not the project.
Any suggestions? Am I approaching this wrong?
You cant have different assemblies loaded between different branches. You would need to run different controllers and use separate folders.

How do I modify a VS Build Workflow if VS can't find any custom DLLs it uses?

I'm using TFS Server 2010.
In my source I have a folder called BuildProcessTemplates. This has a child folder called Custom Assemblies.
Now, when the build runs, it happily loads the DLLs in the Custom Assemblies folder and does its thing.
I need to modify the .xaml file that defines the workflow of the build. If I double click on the .xaml file VS tries to open it but throws an error saying it can't find certain types that I know are defined in the DLL that is in the Custom Assemblies folder.
The workflow is told where to find these types when the build runs by Build Controller as it is defined as a property in the TFS Admin Console.
So, how on earth do I get VS to open my .xaml file properly? How do I let it know where to look for the DLL? I've tried moving all of the files in Custom Assemblies in to the same folder as the .xaml file, but that didn't help.
Clearly I'm missing something; I just don't have a clue what it might be.
You normally create a C# Project (Unit Test is easiest because it is pretty bare).
When you have you project you then need to:
Add the XAML as a File,
Add the Custom Activities DLL's as references.
Add the relevant TeamFoundation* references from the GAC (make sure the TFS version matches - 2010 = v10, 2012 = v11).
Also, I always open our TFS "Build Project" with VS version that matches our TFS Version, I find it keeps the number of problems down.
There's a great series of posts from Ewald Hofman here, that go through the process - I find it a bit dated, and that the Wrox Professional TFS 2012 book does a better job of explaining it, if you can get a copy.

TeamCity Build Web Solution with Multiple Projects ASP.NET MVC

I have what I believe is a really common scenario with an ASP.NET MVC 3 solution. It has a WEB project and a DAL class library. I have the all my data access in the class library, which is required to be built before the web project.
When I rebuild my solution in standard Visual Studio I have no issues. But lets say I make a data change (for example to the database) and check in the DBML (LINQ to SQL) file and the corresponding reference files from the WEB Project.
What I'm seeing is TeamCity not cleaning/rebuilding the class library DLL at all. Below is my solution configuration. How can I force TeamCity to rebuild each project as it doesn't seem to be doing such. I have to actually check in the bin/debug DLL locally in order for TeamCity to successfully build. I feel that should not be the case. Do I need to setup a build step for each project...?
How can I force TeamCity to rebuild each project as it doesn't seem to be doing such.
I think the surest way to do this is to enforce a clean checkout of the source tree prior to each build. (see also: nuke it from orbit.)
You can have TeamCity do this for you by enabling the Clean all files before build option on Version Control Settings -> Checkout Settings. This option deletes the entire checkout directory and does a full, clean checkout of all the sources prior to the build. The TeamCity 'Clean Checkout' documentation has more info.
Sounds like your build configuration (in Visual Studio) is messed up.
First off, make sure your DAL reference is a project reference, not a file reference.
The easiest way to correct this is to remove the reference and re-add it. While adding, ensure you are looking at the projects tab. This should reset the project dependencies.
To ensure that the MVC project depends on the DAL project, right-click on the MVC project and select Project Dependencies... from the context menu. The DAL project should be checked.

TFSBuildServiceHost start error referencing Elmah SQLite.dll

Installed the TFS 2010 build service and when trying to start the tfsbuildservicehost I get the following errror (this is on a Windows Server 2008, patched and updated, and we are not using SQLite). This is happening twice for the build controller, the build agent and the build service.
TFSBuildServiceHost
Service 'MVC Build Agent' had an
exception: Exception Message: Problem
with loading custom assemblies: API
restriction: The assembly
'file:///C:\Users\Administrator\AppData\Local\Temp\BuildAgent\1\Utilities\Elmah\lib\x64\System.Data.SQLite.DLL'
has already loaded from a different
location. It cannot be loaded from a
new location within the same
appdomain. (type Exception)
I have had similar problem:)
Go to your controller definition in tfs and in build controller properties and set version control path to custom assemblies and add there location to your
"Elmah\lib\x64\System.Data.SQLite.DLL" from your tfs project.
in format of :
$/Elmah/lib
this should solve your problem
I don't know what the 'MVC Build Agent' is, but it's not a component of Team Foundation Server. Sounds like you have a custom assembly that's failing to load. Check the build controller properties to see where it's looking for its custom assemblies. You'll need to either (a) check-in the dependencies required by this custom assembly, or (b) change/remove the custom assembly path for the build controller so it no longer tries to load it.

Resources