I have a solution which contains a number of 2 windows console projects, 1 website project and 20 class libraries.
I want TFS 2013 to push to the drop folder only the windows console and website projects to the drop folder.
I am looking for a folder structure similar to below.
DropFolder
- App1
- App2
- Website1
How is the best way to configure TFS to allow this?
Thanks
UPDATE
I have ended up using the nuget package http://www.nuget.org/packages/PublishedApplications for all the projects that I want to be published. This copies the projects into a _PublishedApplications folder. So that I have a folder structure like this
DropFolder
_PublishedApplications
- App1
- App2
_PublishedWebsites
- Website1
The default template has Solution Specific Build Outputs property under Process tab Advanced section.
Alternatively you can let MSBuild control your build flow.
Update:
The ultimate solution seems implementing NuGet's
PublishedApplications
I've used PublishedApplications NuGet package as well, but have encountered an issue. If referenced libraries had Content marked as Copy Always all content would be copied to the root folder and not hierarchically. For example if you have following projects and structure (some files omitted for brevity):
PublishLib
test
TextFile1.txt (marked as Content/CopyAlways)
TestPublishTargetApp - references PublishLib
targets
Microsoft.Application.targets
When team build is done this is the content of _PublishedApplications\TestPublishTargetApp folder:
PublishLib.dll
TestPublishTargetApp.exe
TestPublishTargetApp.exe.config
TestPublishTargetApp.pdb
TextFile1.txt
And what I expected was:
test\TextFile1.txt
PublishLib.dll
TestPublishTargetApp.exe
TestPublishTargetApp.exe.config
TestPublishTargetApp.pdb
After fiddling around a bit with Microsoft.Application.targets I was able to get what I wanted by changing last <Copy SourceFiles (original commented out):
<!--<Copy SourceFiles="#(_SourceItemsToCopyToOutputDirectoryAlways)"
DestinationFolder="$(ExeProjectOutputDir)"
SkipUnchangedFiles="false"
Retries="$(CopyRetryCount)"
RetryDelayMilliseconds="$(CopyRetryDelayMilliseconds)"/>-->
<Copy SourceFiles="#(_SourceItemsToCopyToOutputDirectoryAlways)"
DestinationFiles = "#(_SourceItemsToCopyToOutputDirectoryAlways->'$(ExeProjectOutputDir)\%(TargetPath)')"
SkipUnchangedFiles="false"
Retries="$(CopyRetryCount)"
RetryDelayMilliseconds="$(CopyRetryDelayMilliseconds)"/>
I am not sure if this is useful to anyone else, but for me this was essential change, plus PublishedApplications NuGet package was not changed since 2014 (seems like abandoned project).
Related
We have a very large solution (some 300+) projects and we are trying to build it via MSBuild on TFS2010.
We can build it via MSBuild on all out development machines, and are in the process of adopting TFS.
The structure of our code is like so:
bin\Client
bin\Server
Framework\ClientFramework.csproj
Modules\Module1\Project1
Modules\Module2\Project2
etc.
Each project has a relative OutputPath which builds the code to the bin Client or Server directory. So for example, Project1.csproj has an OutputPath of "..\..\bin\Client".
We seem to be having a problem that in TFS MSBuild the OutDir is set to a Fixed Path:
C:\Builds\MyProject\Binaries\
So things are getting confusing when resolving the relative OutputPath on top of the OutDir
ClientFramework goes to C:\Builds\MyProject\Binaries\..\bin\Client
Project1 goes to C:\Builds\MyProject\Binaries\..\..\bin\Client
etc.
We also have some Post build events that copy some 3rd Party dll's to the bin folders, these paths cannot be resolved properly either.
I think the solution we are after is to build everything to our existing bin\Client, bin\Server structure and then move the Folders from bin to Binaries.
Any ideas on how to accomplish this or how we should be working, are appreciated, but updating our existing projects might prove problematic, as it all works with VS, developer command line builds and with CC.net.
Since this is first link that pops up with a Google search of "TFS OutDir", I must provide a newer solution. I spent an entire day playing around with OutDir, OutputPath, and overriding them with TeamBuildOutDir. A better solution is to set the MSBuild property GenerateProjectSpecificOutputFolder. It comes with .NET 4.5. More info here: http://blog.codeassassin.com/2012/05/10/override-the-tfs-team-build-outdir-property-net-4-5/
I found the answer on MSDN : http://msdn.microsoft.com/en-us/library/ff977206.aspx
We have installers referencing a wixlib file to get some common functionality. The wixlib is built in another solution then moved to a folder within that solution. When we try to build the installers with a TFS build, we get an error from light.exe:
light.exe: The system cannot find the file '..\..\..\Core\Common\assemblies\v1.0\Common.Wix.wixlib' with type 'Source'.
Our regular projects can reference \assembiles\v1.0, since we have some other common assemblies stored there. How do we get WiX to recognize this location during build?
You are referencing wixlib directly. So as far as I understand the TFS build process, it should be added to TFS project of your solution. TFS project shouldn't be dependent on the output of another non-dependent solution. It is at least bad practice. And in any case you can't guarantee this output would be generated before your project build on server.
As far as I remember, TFS build creates separate folder for each build and gets sources there. So your solutions are no longer on the same folder hierarchy level.
One more point in favor of explicitly copying wixlibs into your installer project: versioning - in this case any bugs made in the common library will not immediately break all projects that reference it. And you can gradually upgrade and test every project. Can you imagine auomatically downloading new version of any 3rd party dll on every build? Any change in that dll will immediately break your application even if changes are not critical to you.
Since the shared component and the active solution are in two separate projects in TFS, the workspace must be setup so that the relative paths for references remain intact. The easiest way to do this is to set your Build Agent Folder structure in Workspace in your TFS Build to have $(SourceDir) represent your root. However, don't change your Source Control Folder - that stays the same.
For example, say you have the following structure:
-TFS
|-SharedComponents
||-MyComponents
|-ProjectArea
||-MyProject
You would want to have the following two items in the build Workspace:
Source Control Folder Build Agent Folder
---------------------------------------------------------------------------------
$/ProjectArea/MyProject $(SourceDir)\ProjectArea\MyProject
$/SharedComponents/MyComponents $(SourceDir)\SharedComponents\MyComponents
This mimics the structure in TFS in your build folder, thus allowing all relative paths to remain intact.
One more note about this configuration: Since you have the shared components in another location, you may want to create a solution folder in MyProject and add the components that you are using to it. This will ensure they get pulled automatically when anyone loads your project from TFS - they won't have to go back and pull down the share components folder separately after discovering a build error.
The default configuration of the Team Build Number Format is:
$(BuildDefinitionName)_$(Date:yyyyMMdd)$(Rev:.r)
It drops all output to \\foo\bar\MyBuildDef_20111031.1 Great stuff so far!
The small problem is that it drops all binaries in that directory without a good indication of the dependencies of the binaries.
How can you modify this property, or otherwise, to have the solution's binaries dropped in their respective project directories?
In the case above, I had expected the MVC website (complete with its bin directory) to be dropped. Instead, we got that PLUS the extra drop of the binaries in the root.
In other words: TFS, please stop dropping all binaries in the root; it looks messy, and it's confusing on which files belong/associated with what.
How can this be achieved with Team Build 2010?
This blog post should help you out: http://blogs.msdn.com/b/willbar/archive/2011/02/05/splitting-team-build-outputs-into-folders.aspx
Essentially, you create a new 'Platform' for each project. Team Build will put each platform in a different directory by default, so you get a different directory for each of your projects.
Build configuration dialog:
Drop folder output:
Unfortunately I have not found a good way to do this yet, though it has been a while since I tried to find a better solution then what I settled on.
Current have solutions for each desktop application, and one with all the websites. I then followed the instructions here to make each solution output into a separate folder.
I've got a solution with Silverlight projects, a couple Web applications and some Windows service and their small Winforms test applications.
When I build it using TFS it puts all binary files in the Binaries folder. It also creates a _PublishedWebsites folder where it puts the web applications ready for deployment.
What I would like is for a few of the projects to have their ouput in a separate directory in the Binaries folder. I want the files that I would normally find in the bin\Release folder to be there.
I looked long and hard and could only find scarce documentation on how to achieve that and only for TFS 2008. There's a good article there link text and another entry for VS 2010 there link text. However, none of these work :-(
It seems that the build ignores the <OutputPath> property. I tried fiddling with the <AfterBuild> property but unfortunately if I use the $(OutDir) property I get ALL the files in the Binaries directory and not only the ones that just got compiled.
At the moment I'm setting up a separate build that only has the projects I'm interested in that get compiled but I would really like to have all the files needed for the release built all at once.
EDIT: I didn't make it clear enough but I'm using the latest version of TFS (TFS 2010 RTM). I set up <OutputPathDir> on the project level as explained in the links that I provided.
Cheers.
In your build definition (.proj) file, check that
<Project>
<PropertyGroup>
<CustomizableOutDir>true</CustomizableOutDir>
</PropertyGroup>
</Project>
Also, you may run into some problems if you're trying to compile what was once a "website" project type (created from File->New->Website->ASP.NET Webiste). They seem to override the output directory every time. We had to convert some of those to class libraries instead.
I've a Solution structure as below :
Solution 1 (Solution1.sln)
Project 1
Project 2
Project 3
I created a Team Build definition working with Solution1.sln.
My problem is that compiled binaries are stored into a single flat output folder : BuildName\Release
But I want to keep my project structure :
BuildName\Project 1\Release
BuildName\Project 2\Release
BuildName\Project 3\Release
See Preserving Output Directory Structures in Orcas Team Build. It's pretty irritating that this is neccesary, and it's a per-project tweak, but it can be made to work.
The default for Team Build is as you've seen - binaries in one folder, web sites each in a folder structure of their own; one per configuration being built. If you're just getting started with TFS, I suggest you try to use the default. You're more familiar with separate folders, but almost everything you read about Team Build will use a single output folder.
Other than familiarity, is there a reason you want separate folders?