I have a Visual Studio Solution having 3 projects in it. Same solution is having a folder in which I added existing projects which belong to other TFS Team Project.
TeamPrj1
|- Solution1
|- External Reference(folder)
|- PrjA (added as existing project)
|- Prj1
|- Prj2
TeamPrj2
|- SolutionA
|- PrjA
I want to have a TFS Build for my Solution1. The problem I am facing is that the solution is not compiling on the TFS Build Server as it cannot find the reference of the PrjA. I know there is some tweak to be done in the workspace mapping and I went through different forum and blogpost too but still doesn't work. Some say to add the PrjA dll as a file reference but I dont want to go that route as what if something changes in PrjA than the Sol1 needs to be re-reference the latest dll. Having added as reference, it automatically gets the latest everytime Solution1 is opened from TFS.
Currently below is my workspace mapping.
Active $/TeamPrj1/Main/Solution1
$(SourceDir)
Active $/TeamPrjA/Main/SolutionA
$(SouceDir)\Main\
Since the solution needs to reference the other project using a relative path, you need to make sure that the Workspace mapping for the Build Definition actually results in the same file structure as on your local workspace.
Judging from your folder names, you should use the following mapping:
Active | $/TeamProj1/Main/Solution1 | $(Sourcedir)\Solution1
Active | $/TeamProjA/Main/SolutionA | $(Sourcedir)\SolutionA
But I cannot be sure of the exact target paths until we know the relative path defined to PrjA.csproj in Solution1.sln.
You will probably need to update the path to the solution in the Process Tab of the Build Definition editor as well.
If you have a Visual Studio project, for example a team project containing shared library code that is used by multiple team projects,
You can either manage the project within the owning team’s project or
you can create a separate team project specifically for the shared
project.
If you choose the latter approach and use a common shared project,
the folder structure in Microsoft Visual Studio Team Foundation
Server (TFS) source control looks like
For more info see the following:
Chapter 6 – Managing Source Control Dependencies in Visual Studio Team System
I guess the best option is to have a enterprise NuGet server and publish packages this NuGet site internally.
For visual studio solutions under different Team Projects, they can easily NuGet for referencing. The TFS Automated build can also easily restore NuGet packages for any solution.
You can also have the automated builds to drop a NuGet package to NuGet server for the assemblies/exe's which are common across multiple TeamProject and Team Collections also. (xcopy command in build template).
The biggest benefit of using this approach: Everything is automated. No need to do any manual merge and checkin. Can be used across multiple TeamProject & TeamCollections. If a parent common dll changes, the automated build for it can push it to NuGet server. Next time all other project using the common dll via NuGet will have always the latest one as on the Build Server it will always download the latest from NuGet (assumption that you keep the version # same).
Related
In TFS 2015 I have a Team Project with multiple solutions. The only way i can get the individual solutions to build correctly is to have a mapping for the Entire Team Project, so if i've got 5 builds set up, each of the build directories contains a copy of everything in the team project, which takes up a fair chunk of disk space
If i supply a mapping for just the solution i want, then it fails.
In this instance the solution is very simple. It's just a solution that contains the domain model, with Entity Framework as the only external dependency. The build fails because it can't find the EF assemblies. The Ef packages are being retrieved from Nuget, but they are't being copied into the Bin folder (The bin folder is empty).
Any ideas? Please let me know if you need more info
Sounds like a NuGet issue more than TFS. Is your packages folder checked into source control? If so, then the associated binaries have probably been excluded by TFS and so it think it has them but actually doesn't. Delete the packages folder from TFS and ensure the build definition is set to clean (or manually delete the sources directory on the agent(s)) and then see my answer here for a good setup (Note the link to the NuGet website, worth a read) :
Visual Studio 2015 loses Nuget packages on new installations
We have 1 Team Project with multiple solutions too so it's definitely not a limitation, just something muddled somewhere.
Background
Currently I have many C# projects in many TFS team projects.
Several C# projects reference C# projects in different team projects. I do this by referencing the output dll in the Bin/Release folder of the other C# project.
As long as we checkout & build the solutions in the team projects in the correct order everything works fine on all dev's machines.
We're moving to Visual Studio Online and I'm playing around with automated builds.
Problem
The problem I'm having is that it can't find the dlls to reference, even after the project that would output them (to \Bin\Release) has ran.
I've disabled parallel builds (to ensure the referenced projects get built first) and this seems to be the case based on the build logs. The issue is that the projects that depend on these can't find the dlls and as a result I get "the type or namespace could not be found" errors everywhere.
What's the easiest way of resolving this?
Note that I've read several posts/tutorials etc. about this but all seem to involve changing the source control structure, or fiddling about with workspaces etc. I want something where I can keep the simple workspace mapping on the dev's machines where we map "$\" to "C:\TFS\". I don't want to have to remember to periodically merge in changes from a shared library, or maintain lots of folder mappings within a workspace (on dev machines).
Open your process template xaml (usually DefaultTemplate.11.1.xaml or TfvcTemplate.12.xaml with XML editor, not the designer). Look for mtbwa:MSBuild on Run MSBuild for Project activity. Remove the OutDir attribute, save and check-in. This will force MSBuild to use the default OutDir for each project.
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.
I have an TFS server installation that through time has gone through upgrades from TFS 2005 to TFS 2008 and then to TFS 2010.
During the lifetime of the installation a lot of projects have been created and different project templates have been used. MSF Agile 4.0, 4.1, 4.2 and 5.0. and a few MSF CMMI ones.
What I would like to do is "replace" the project template used for all these projects to use a new one common one: Microsoft Visual Studio Scrum 1.0.
I am aware that TFS project templates are used as templates for creating new projects and cannot modify the tfs projects definitions after creation.
Uptil now only the version control and build server part of TFS have been used and there are no existing work item types.
Additionally all projects and build scripts are depending on the source code paths stay the same.
As I see it I have the following options:
Create new TFS projects using the correct project template and then move/branch the source code to the new project.
All code is moved to a temporary team project.
The old project is deleted
New project with the original name and correct process template is created
Code is moved to the new team project
Temporary team project is deleted
All the build definitions needs to be to recreated which is not an option.
The source code move/branch will "mess up" the versioning history
By messing up the versioning history I mean that when you move source code it will behind the scenes do a delete + source rename on the original location and the history will still be located in the old project. This will make searching in the history difficult and if I actually delete the old project I will loose all the history before the source code move.
This is really not an option for me since there is years of code change history that is needed to for supporting the different applications being built.
Use the TFS migration tools to migrate to another TFS project
This has the same downsides as the first solution
Replace/import work item types, install new reports, create new SharePoint sites
For each tfs project
Delete existing work item definitions using "witadmin deletewitd"
Import each work item definition from the new process template using "witadmin importwitd"
Import work item categories using "witadmin importcategories"
Delete old reports in project folder in report server
Upload the report definitions from the new process template
Modify data sources used for the reports using the report manager to point to the correct shared data sources (TfsReportDS and TfsOlapReportsDS)
Modify the report parameter ExplicitProject default value to "" (empty string) and disable prompt user option.
Export the documents in the old SharePoint site using stsadm
Delete the old SharePoint site
Recreate the sharepoint site using the TFS2010 Agile Dashboard site template
Activate site feature "Team Foundation Server Scrum dashboard"
In TFS Project Settings -> Project Portal Settings: Enable "team project portal" and ensure the url is correct. Enable "reports and dashboards refer to data for this team project"
And finally..
Process the Warehouse
Process the Analysis Database
Even though that this involves a lot of small steps this looks more appealing because
this option will not force me to move the source code and my existing build definitions will be intact.
My question:
Are there other ways to achieve the replacement of work item types that I haven't mentioned?
And/or am I missing any steps in last solution?
Given that you aren't using any existing work item types, your final proposal looks like the best option.
After deleting the old reports and exporting the SharePoint documents (you could also use Windows Explorer instead of stsadm), there are actually two commands in 'tfpt' that will help you. This will reduce it from 14 steps down to 5 or 6 steps.
tfpt addprojectreports Add or overwrite reports for an existing team project
tfpt addprojectportal Add or move portal for an existing team project
tfpt addprojectreports /collection:http://yourtfs:8080/tfs/YourCollection /teamproject:"Your Team Project" /processtemplate:"Microsoft Visual Studio Scrum 1.0" /verbose
tfpt addprojectreports /collection:http://yourtfs:8080/tfs/YourCollection /teamproject:"Your Team Project" /processtemplate:"Microsoft Visual Studio Scrum 1.0" /verbose
Your first option is IMHO your best shot.
You can branch the sources from the old team project to the new team project. With TFS 2010 you can see the history also from the branched location. So you don't loose functionality in here.
The Build is just an msbuild file which is stored in source control. The only thing you have to do is actually copy the build definitions. You can do that either manually, or you can create a little app that does that for you.
We are using TFS 2008 for Web App dev. The WebApp is a large project, so we do not want every developer to see all the source code, which means lots of libraries or subapps need to be referenced.If I put all the libraries and subapps in one VS2008 Project or VS2008 Team Project, all the source codes will be exposed to each person.
Do I have to make the WebApp reference other Team Project to solve this problem? What is the best way doing so?
Consider each isolated section to be a project (in both the physical and management sense) as independent. Ship release from those shared components/projects and deliver them as binaries to be pulled into the others. You can use a the output from trunk or release branch builds of the shared components to deliver new "releases".
This affords you the option of full branching, work item, reporting etc for each logical project in your organization.
If you let someone be a contributor/developer on a project, then that individual has access to the entire project. If you want to keep someone out of the certain files, then that will need to be under its own TFS project. You would then reference the output assemblies from the parent project in the child project.