We Have a large VS solution using project references which is build by TFS Build like so:
Solution
- Project 1
- Project 2
- Project ...
- Project N
Because the solution is too large we have several smaller solutions which we use day to day:
SubSolution
- Project 1
- Project 19
The problem is that developers working on SubSolution find that it is not building because the project references could not be found, so they change the projects to use file references.
This then goes on to break the TFS Build which cannot find these file references because they have not been built yet (Even though the projects are in the same solution). Is there a way around this tug of war between the two types of references. What is the correct way of splitting out your solutions?
What is the correct way of splitting out your solutions?
Check out this chapter from the TFS guide by the Patterns & Practices team:
Chapter 3 - Structuring Projects and Solutions in Source Control
Pay special attention to this note to the "Partitioned Solution" scenario (which I believe you're actually trying to implement):
Unlike previous versions of Visual Studio, Visual Studio 2005 relies upon MSBuild. It is now possible to create solution structures that do not include all referenced projects and still build without errors. As long as the master solution has been built first, generating the binary output from each project, MSBuild is able to follow project references outside the bounds of your solution and build successfully. This only works if you use project references, not file references. You can successfully build solutions created this way from the Visual Studio build command line and from the IDE, but not with Team Build by default. In order to build successfully with Team Build use the master solution that includes all of the projects and dependencies.
Regardless of how you organise your build, developers should understand how references work, and be aware when they make changes to references that they shouldn't check those changes in unless they intended to make a change to the build process.
On the subject of organising your builds - as Dmytrol says, project references should work between solutions (As long as the target is already built, however that's also the case for file references anyway).
My advice would be to group your projects into small workable solutions and use project references within those solutions. Your main solution file / build can use project references too, however if you find project references between the smaller solutions too difficult to maintain you can use file references instead, and control the build order through project dependencies or the project build order (accessible within Visual Studio by right-clicking on a project in your solution).
Related
I'm struggling to get Azure Devops Server 2019 (on prem) to build a complicated project setup of mine.
I have multiple solutions that build various BizTalk apps. Some of these solutions references some of the projects in other solutions/repos. This works fine in Visual Studio (providing everybody names their repos as the default, which they do).
To automate this build, I've created a multi-stage build pipeline that builds each solution in order.
Whilst solution 1 will build successfully, when it comes to solution 2, the msbuild tasks will not reference the outputs for the projects that have been included as a project reference in the solution.
This seems to be because these referenced projects aren't marked for build - because they wouldn't be able to build themselves without them in turn referencing their other projects in the main solutions etc.
Bundling everything into one big super solution file is not feasible.
I'm wanting msbuild to /reference the projects that have already been built in the previous step, as per being included as project references. But msbuild is a complicated beast and I cannot figure out a way of achieving this.
Is what I'm trying to achieve even possible? Can anybody point me in the right direction?
TFS / msbuild, building project references
This is a known issue about project reference in different Repos, but unfortunately it doesn't have a best answer. Because the best solution is always to have a single repository.
Git thinks of files as the content of the whole repository, not as a collection of files. Therefore this is quite hard to do. As workaround, you can consider to use Git Submodules or Git Subtree:
Check the details info from here:
Git and Visual Studio project references
Besides, the solution we are using now is to put the shared code in the NuGet package. Then, you can use the package from any repository, and you don't have to perform any unstable git settings and keep access control as they should be.
Hope this helps.
It seems that msbuild was changed to only reference project references, and that you can revert that to reference all references by setting the property OnlyReferenceAndBuildProjectsEnabledInSolutionConfiguration to true when running msbuild.
Source: https://stackoverflow.com/a/25144169
Have confirmed this works.
I've finally revisited this and done some more experimentation.
The only way, that I can see, to get TFS/msbuild to /reference other projects outputs is to mark them in the solution build configuration to build.
Now if you do this in Visual Studio and try and build a solution that has projects from another solution then the build will fail if the previous solution hasn't been fully built yet (as the other chained dependencies won't have been built). This makes sense.
But with TFS/msbuild, the build will succeed. From what I can tell there is some magic going on that ensures the dependencies across all solutions are somehow resolved. This might be luck, it might be specific behaviour (it's working for me so far).
The problem of course is that it's incompatible with Visual Studio. So I have an extra "Build" definition setup in each Solution file that has all the projects set to build.
This seems the easiest way to manage lots of interrelated solutions without having one big one.
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.
Using TFS 2010 I need to build a solution that depends on a couple of other solutions held in different team projects. I'm editing my build definition and I create a list of "Projects to Build'. When it comes to build the parent solution I get an error because it's unable to reference assemblies created by the other solutions. So I go back to edit build definition and add /p:ReferencePath="c:\builds\3\referencedproject\binaries\" to the "MSBuild Arguments" Build process parameters.
Problem is, I don't want to hard code the c:\build\3. I guess there may be a $() property I can use in its place - can anyone please advise?
The other problem I have is that the 'Main' project and the two other projects that it references live at the same level in the source code. As far as I can tell, I have to set the source control folder to be the level above this - which happens to be the root. This means that TFS Build does a get of all the projects on the root - which includes dozens of projects that are not required for my build. It's not a critical issue since it makes no attempt to compile these non-related projects but it does increase the time for the build cycle to complete. Is this only way to avoid this to "group" the projects that are required for my build into a different TFS source folder?
For the references issue there are a few options. The most common one taking an explicit dependency on a specific version by checking in the binary to TFS.
For example, if you have Team Project A that has a dependency on Team Project B, I would assume they are setup as separate projects because they evolve differently, probably have different teams working on them, and have different release cycles. The common approach to managing this dependency is to checkin B.dll into Team Project A (usually in a lib folder specifically for this purpose), then use a file reference from within Project A's solution/projects to the dll in the lib folder.
This approach lets the Project A team explicitly choose which version of B.dll they wish to depend on, and make an explicit decision to adopt newer versions of B.dll on their own timetable.
For the other question of how to have a build definition download only select source code paths, you can specify multiple lines in the Workspace mapping screen when setting up a build definition. For example you could have the following:
$\ProjectA -> $(SourceDir)\ProjectA
$\ProjectB -> $(SourceDir)\ProjectB
This would download Project A + B but not C.
I'll start with problem 2 as this should be easiest to solve.
You have 2 options both involve changing the workspace mapping of your Build Definition.
You don't have to map at the folder "above", you can map individual folders so if your source looks like this.
$/TP/SolutionA
$/TP/Folder1/SolutionB
$/TP/Folder1/SolutionC
$/TP/Folder2/SolutionD
and you only want to include SolutionA and SolutionC in your build, you could set the workspace up as follows.
This will get just the code you need and preserve the relative paths between them.
Another option is to use cloaking, you map the "Root" folder and then cloak any folders you want the build to ignore.
Both of these methods will restrict the amount of source being downloaded when the build runs, and also prevent "continuous" builds from starting when checkins occur in the folders that haven't been mapped / Cloaked.
Problem number 1.
As Dylan suggests, probably the best thing to do is to use Binary References between solutions. Especially solutions in seperate team projects.
Check out my answer to this question for a full description.
TFS 2008 and Common Libraries
I have created a Team Project called "Common Library" that will host code used in numerous different Team Projects throughout TFS. For sake of argument, lets say we have 2 distinct Librarys under the "Common Library" Team Projects, MailProject and LoggingProject. Other projects throughout TFS will be using the binary representation of these projects via branching and not the actual source code.
What is the best way to set up the folder structure for this Team Project? Do I add the project to the "Common Library" and simply "include" the bin/release folder as part of the project?
I have seen some examples of people creating a seperate "Deploy" folder. I assume this is synonamous with the bin/release folder?
We do not want the source code available in other solutions.
Currently, each project has the dll included in the project. Using a mailing module as an example, many projects need the ability to mail. The common module is very stable and mostly static.
However, what if there is a change in the mail module. It seems there would be a better way, than to check out each project and update the dll. Is it possible to allow TFS to grab the latest mail module any time a 'get latest' is called? Either explicitly or implicitly.
Unless you really require the source code for the libraries to be available in the other solutions my advice would be to include the binaries for the libraries in the projects that would use them not really having any explicit link between the two in TFS. Custom labelling of the library builds could be helpful to easily return and rebuild any chosen version of the shared libraries.
If the shared libraries require different versions for different projects then the obvious solution would to create a separate branch for every version of the libraries that need to be customised to a particular project.
TFS does not have a concept similar to SVN's 'externals' though - so if you include a branch from the shared libraries in a project and than branch that project it is very difficult to propagate changes correctly.
I suppose you could also use the Get task in the build and get the latest version of DDLs into the current project from another one, but verify if you can point of Workspace of another project (I have not tired it and MSDN is somewhat vague here). You might need to have a separate workspace for the shared project.
Yet another alternative would be to publish the DLLs for common components to a known location on every build of the shared libs and for individual builds to get whatever version is available from that common location (network share) even via the Copy task. This is simplistic and may cause problems with versioning of the common components but should work well enough in simple case.
I'm noticing some solutions in Team Foundation Server 2008 won't build completely. As in, some number of the projects in the solution succeed but then one fails. The particular failing project says I’m missing an assembly reference. But I'm not - the project has the reference. It builds fine on my PC. I'm looking at the .csproj file that the build agent pulled down and it has the reference, too (it's line-for-line identical to the project I'm building).
The reference in question is to another project in the solution. At first I thought it wasn't building projects in the right order but the build log is telling me that it did (i.e., the project which the reference is in reference to built successfully). So my guess is that somehow on this project (and I’d say about 10-20% of the projects I’m having it build are failing) it’s looking at the wrong folder for assemblies, but I have no idea.
Has anyone ever seen this before?
I did have one Solution which was building things in the wrong order and some Googling seemed to indicate that this was an occasional side-effect of converting a VS2003 SLN file to a VS2008 SLN file (and it was happening in Visual Studio as well), so in that case I made a new SLN from scratch, checked that in "on top" of the problematic one, and it worked fine. But I tried that in the problem above and it didn’t make a difference.
I've seen it on multicore machines where the project dependencies haven't been setup correctly, meaning that tfs starts a project compiling before it's dependencies are finished compiling.
At first I thought it wasn't building projects in the right order but the build log is telling me that it did (i.e., the project which the reference is in reference to built successfully).
Define "built successfully." In particular, make sure the CoreCompile target was invoked and ran to completion. I've seen cases where a different target on the referenced project was built, but that target was insufficient to generate the output the dependent project needed. For example, a web project that includes a Silverlight control will call the GetXapOutputFile target on the Silverlight project -- which is fine & dandy, but it's no replacement for CoreCompile.
If this clue isn't enough to resolve your issue, you should probably post a link to the log and/or the msbuild makefiles.