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.
Related
I have a small solution containing three Visual Studio projects. I'm working in Visual Studio 2015 using TFS 2015.
I have implemented a gated check in, but for some reason the solution will not build on the TFS server. I'm referencing only 1 nuget package - Entity Framework. I am not checking my package folder into TFS, but my packages.config files are being included.
I have previously set up a different project on the same server using the same build definition and it works fine.
In order to restore packages prior to build, you will need to run the following command as part of your build process.
nuget.exe restore path\to\solution.sln
One way to do that is to add another project that is responsible for building your solutions and making sure that the packages get restored prior to your solutions being built.
Following write-up walks you through getting that set up: nuget docs
I managed to get it working, but I tripped into the fix and don't know what exactly solved the problem. This is the first time I've really had to handle TFS builds.
I know I only had one build definition defined and it was intended for a different solution - of which this code was also a part. I think when I was checking in this solution it was actually trying to build the other.
Apparently, I can't have my nuget packages set up different ways for code that is in two different solutions. Anyway, that's my best guess.
I am hoping for a little advice.
I am checking in my project (asp.net mvc 5) to source control (TFS) and when a fellow colleague tries to pull it down, most of the references are not being added to his project.
How can I insure that all the references to get added?
Generally, best practice is to use NuGet.
At least for packages that are not internal you must use NuGet. Let's say for EF, BundleTransformer & so on.
For that you must enable NuGet package restore and fetch all you need from NuGet Feed. More here: http://docs.nuget.org/consume/package-restore/msbuild-integrated
For internal dll's you can create an internal NuGet feed: https://docs.nuget.org/create/hosting-your-own-nuget-feeds and get packages from there or copy them in your project.
Don't forget to include the files into project if you copy them "by hand" and i think this is a good start.
There are other best practices like not referencing anything from GAC anymore and move all the dll's/dependencies/referencing to NuGet or to create a raw "Library/Vendor" folder in your project and copy all the necessary DLLs there (problem here is that you check in all the dll's to source control), but you will be sure that everyone will get exact the same version/reference & so on because the files are stored there (physically).
What are the references to?
There are a few different things to bear in mind:
References to other projects within the solution should just work, if they don't make sure that the referred to projects are building
References to things like nunit are best managed through nuget so you add them using it and then when your colleague checks out he only has to restore the nuget packages and it all works
References to things that aren't in nuget, you can either put them into nuget or I prefer to create a lib folder and put them into there. To get them actually checked in as dll's are normally excluded, add the folder and dll's and then use the source control explorer to find the folder, right click and choose "Add items to folder" and use that to add the dll's and files that you need. If you then reference the dll's in the lib folder they will be checked out and should resolve correctly for the other user.
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).
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.
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.