I am having and issue with TFS 2015 doing a continuous integration build. I have added 3 projects to my Questionnaires solution which are meant to be shared code between other solutions as well. Therefore those projects each have their own folder structures under TFS not under Questionnaires.
When I go to do a checkin, TFS is getting the path wrong to one of the projects and therefore won't build. The path it is looking for is-
C:\Builds\1\Questionnaires\Questionnaires\src\Source2\Questionnaires\Dev\Questionnaires\Questionnaires.sln.metaproj: The project file "C:\Builds\1\Questionnaires\Questionnaires\src\Source2\Questionnaires\Dev\Questionnaires......\Common\Main\Common\Common.Utilities\Common.Utilities.csproj" was not found.
That should be the correct path as that is the way it is in TFS under it's own folder.
Where the code is actually ending up is:
C:\Builds\1\Questionnaires\Questionnaires\src\Source2\Common
the \Main\Common folder is missing.
You need to correct your workspace mapping under the "source settings" tab. This sets the folders that will be downloaded from source control to your build server's working folder for the build.
Related
One of my colleagues has made some changes to a project, named "DB Conversion". There are 2 TFS builds associated with the PharmacyWarehouse project. Here's a picture so you can see what I'm talking about.
A previous TFS Administrator set this configuration up. I inherited it when he left. As you can see PharmacyWarehouse is just a folder. But the 2 builds have a Visual Studio Build step which only looks at the PharmacyWarehouse.sln file in the PharmacyWarehouse folder. I've looked at that .sln file, it only references packages, PharmacyWarehouse and UnitTests folders. I've looked at the .csproj files, they only reference those folders/VS projects.
I've looked at the DBConversion.sln and DBConversion.csproj files in the Projects | "DB Conversion" folder. It only references that folder/VS project. The files my colleague was editing are in the Projects | "DB Conversion" | Models folder.
Why would checking in changes in Projects | "DB Conversion" | Models folder cause the TFS trigger watching the PharmacyWarehouse.sln to fire? Is it because their folders and not TFS Projects?
We're working with TFS 2015
According to the screenshot, you are using TFVC version control.
Open build definition, click the tab Trigger and check the trigger field Path specification and ensure the path is $/Pharmacy Warehouse /DB Conversion
Open build definition, click the tab Get sources and check the field Workspace mappings, ensure the path is $/Pharmacy Warehouse /DB Conversion.
After configuration, if we push the changes to the folder or project DB Conversion, it will trigger this build and only build DB Conversion.
I have an existing TFS server (2012) and am transferring a solution from visual source safe. The solution has about 30 projects and compiles fine locally.
I created a build that is triggered manually. In each project I set the property group to match the build configuration.
When I build, only some of the projects make it to the source folder and I get errors for the ones that are missing.
Is there anything else I can check?
In your build definition, go to the Source Settings page. Make sure that the Source Control Folder is set close enough to the root folder to cover all of the projects needed for the build.
Is there a way to set Source Control Folder path in the build definition in TFS 2013 or TFS 2015 using wildcards?
If you mean the source path is the project path which need to build. As Christian.K mentioned, it's impossible. TFS can't build a few projects at the same time.
If you want to using wildcards in the source control folder path on the Source Settings tab. It's also not support. This one specify the version-control folders that contain the files that your build process requires. You can specify the only folders that contain files that your build process requires to improve performance.
No, it is impossible. This case discusses the same request as yours: Variables in TFS Mappings on Visual Studio Online Team Builds
I just copied my Solution from TFS 2008 to TFS 2012. In TFS 2008 the TFSBuild.proj does the normal solution building, calls installshield projects, dotfuscator projects and dumps the resulting installshield output in the drop folder.
In my Build Definition I set the "Items to Build" to point to the .proj file. The build works, but all I get is one folder with the logs inside. I added the .sln to build (although didn't need to previously) and get the .sln files built but installshield and dotfuscator are not done.
Looking at the .proj log file... None of my "Message" outputs are there. Was there some large change between these two versions that would necessitate a big change in the proj file?
I do not have admin rights to the TFS servers.
thanks
I'm guessing that you are using the "Default" build process template. You need to use the "Upgrade" template if you want to use a TFSbuild.proj file.
Edit your build definition and go to the "Process" tab. There should be an area that shows which template you are using. Click on the "show details" button and choose the "Upgrade Template" from the drop down list.
Now point the build at the folder containing the TFSbuild.proj and save the definition. This should solve the problem.
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.