Consider the process when creating a new Team Project.
There's a convention to be followed: Team Projects need to have a directory structure like this:
MyTeamProject
-Dev
-Dev
-Main
-Docs
-Source
-Release
How can this directory structure/layout be automated, or otherwise taken out of the initial developer's hands? Are there any built in configuration spots in TFS 2010 to help achieve this?
There is a mix of training and convention involved here outside of TFS, but the idea is to set all the developers up for success.
You can use a batch file to create and checkin all these directories.
As stated in Team Foundation server project template you can create a batch file that first creates a team project and then add all the folders to version control
Related
I have a console application that I am building on a on-premises tfs 2015 with a Visual Studio Build. What I want to achieve is:
If the application is executed on a dev machine during normal development there will be a simple message "Hello Developer" and if it was deployed in a qa environment and the tester runs it from there it should print "Hello Tester". Just a simple demo.
So I think I need an App.config to be able to store a configuration that will than be changed during the build process. I was confident that this is a no brainer as I found a lot of websites describing something like this but it turns out, that they all are not revealing the interesting bits like
How does the App.config needs to look like?
How is the variable used in C# code?
What are the needed settings in the Release Management Client?
What are the needed settings in the on-premises TFS Build Definition?
or were out-dated (TFS 2013 (1), RM Client 2013 (2)) or were using Visual Studio Online/ Team Services or were using custom tasks.
Can someone explain me, how to achieve the described scenario "Hello Developer"/ "Hello Tester"?
Thanks a lot!
We use MSDeploy for this type of setup. You can extend MSBuild by adding an Import line in your csproj file to a new .targets file in your project. Reference the MSDeploy task and use that to create a MSDeploy package for your console app. Finally create Parameterization files to define the config section you want to transform and SetParameters files for each environment with the appropriate message.
This blog post is for a database project but the basics steps are the same.
Within RM you would use MSDeploy to deploy the package with the appropriate SetParmeter file against the target server via a PowerShell command.
Have you tried with SlowCheetah?
This package allows you to automatically transform your app.config (or
any file) when you press F5 in Visual Studio. You can have different
transformations based on the build configuration. This will enable you
to easily have different app settings, connection strings, etc for
Debug versus Release. If you want to transform other files you can do
that too.
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.
I've just setup a TFS (2012) server and now I'm trying to build the complete code (written in .NET 4.0 in VS 2010) via the TFS Build server. But in my solutions I have also a WCF RIA project which contains linked files because they are used somewhere else also and there is no possibility to add a reference to a general .NET binary in WCF/Silverlight.
Everything builds without any problem on my development machine but when I check it all in, create a standard build definition and run that build definition I get the following problem. The linked files have usings (UsingNamespace for example) to other projects that are also build by us and build before the WCF/Silverlight but the following error pops up while building through TFS Build server:
The type or namespace 'UsingNamespace' could not be found (are you
missing a using directive or an assembly reference?)'
Is there any solution for this problem that I looked over?
EDIT 1
Just tried to set the Copy to Output Directory propertie of the linked files to Copy Always but this still gives me the same error as I was expecting. The problem is that the linked file is placed somewhere that it can use the usings but the WCF RIA service cannot access/find that using.
EDIT 2
Just tried out my local test TFS where I can do what I want and there I made a build definition with just the solutions needed to make that the project with the linked files builds. This worked without any problem. Then I tried the same on our TFS server with a new build definition that has the same solutions as on my test TFS and here it did not work. The only difference that I know for sure is that my test TFS is TFS 2012 Update 1 and that my production TFS does not have the update 1 yet. I'll try to install it next week.
EDIT 3
I've just updated our production TFS to Update 1 but it is still not working with my temporary build definition which only contains the projects that are needed to build the silverlight application with the linked files. The 2 workspaces are the same on both server and the projects to build are also the same.
You need to specify the workspace information in the Build Definition for the build to use. The workspaces are what the build process copies from source control to the build server. If you don't have everything in the build server's workspace, it can't build properly.
The Source Control Folder in the workspace tab is the location of the files you need from TFS. The Build Agent Folder is a relative path from the build server's pre-defined base location. You'll usually use $(SourceDir)\Folder to specify the "Folder" that your build process needs.
This sounds like an $(Outdir) problem. A build definition in TFS automatically overrides the Bin folder. All Binaries are redirected to the bin folder upon compile. Sounds to me that you are using a mixture of project references and file references. The file references are probably what is causing your build failures.
Example if you compile in the same build the following solutions
Solution1.sln (TFS Build Pass)
project1.csproj
project2.csproj (references project 1)
Solution2.sln (TFS Build Failure)
project3.csproj (references binary output of project 1)
Expectations from TFS out of the box without customizing your workflow is that this simple build will fail. The reason is that in your development box all projects produce output to one destination while in a tfs build your projects will build to $(Outdir).
Some Things to try
Simple (best practice in my view)
Create 1 solution and use project references instead of file references.
Complex
Build using MSBuild project files
Modify your windows workflow to not override the $(Outdir)
Copy the binaries after a build is complete.
Best practice on Automating Builds
Build from command line
Build from cmd a NON vs2010 command line.
C:\Windows\Microsoft.NET\Framework\v4.0.30319\msbuild.exe FullpathtoSolutionFile.sln
Cheers!
Apparently there was just missing the WCF RIA services V1.0 SP2 on the TFS server. If that was installed the problem was solved.
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
I want to use the same targets defined in an external file in multiple build definitions. This external target file should be stored on the source control.
The bootstrap phase explained in TFSBuild.proj and Importing External Targets does not seem to allow downloading the same file for multiple build definition as the build file is always named TFSBuild.proj and consequently sits in a separate folder for each build definition.
The question was somewhat aked in a comment of the previouly mentionned thread but it seems motre appropriate to create a new thread.
Quoting that comment by David Keaveny:
Is it possible to get TFS to download
from other folder paths during
bootstrap? I have a Common.targets
file that contains all the custom
tasks that my TFSBuild.proj should be
executing, but given that I several
build definitions (one folder per
definition), it sits in a separate
folder at the same level as the build
definitions. Without it, of course,
the builds fail immediately. – David
Keaveny Aug 17 '10 at 23:58
I'm not sure if there is an easy way to do this. You could have a master copy of the targets file, and branch that in to each of your build definition folders. When you update the targets file you'd need to remember to merge it to all of the folders. You could probably write a script that automates the merging, the script should be able to work out what the branching relationships are using tf branches and then iterate around them and call tf merge then tf checkin. This feels like a lot of work though.
You could just install the target on your build server(s). We have a number of custom targets that we use and we manage them as if they were a product, they have their own area for source control and are versioned independently of the software they are used to build. We package them using wix and once they have been tested they are installed on all of the build machines. This seems to work for us and it means we can control the rollout of new targets files, and the targets install is just part of a build server basline build.
I'd be very interested if someone has an easier way of managing this though.