building a solution in TFS 2017, every time I build a solution using build solution step it gives me an error of third-party dll reference, every time I manually need to put the dlls in the agent/work folders on builds server. is there any workaround to successfully build a solution without putting dlls manually..?
Any help is appreciated.
thanks
Kapil
If the missing dlls come from a nuget package, make sure to add a nuget restore step before the build step.
If the missing files are a third party dll, check whether they are properly checked into source control and they are downloaded as part of the GetSources step of the build. Check for this the Log of the GetSources step whether it includes those dll's. If they are not there and they are properly in source-control, you probably have missed to map the folder they're in, so the Build will not download it as part of the GetSources step.
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 have set up a TeamCity partly. Now it downloads the code from TFS and try to build it using MSBuild which was not successful. I know that I am doing something wrong. I have some library added to my code(An ASP.NET website). I know that it is not a good idea to add dll files to Version Control(TFS), but if I don't check them in, when TeamCity downloads the code, it does not have that libraries so MSBuild cannot successfully build it. I was wondering what would be the best practice to solve that issue?
For dependency management in .net I would recommend that you take a look at the TeamCity built in nuget feeds. You have a possibility to utilize a feed directly from within TeamCity, acting as a server. As you state, commiting dependencies in (any) VCS should really be avoided...
It depends on what type of dlls you're dealing with.
If they are available on NuGet.org, use NuGet and the Package Manager Console to add the references to your solution. Then just put NuGet.exe on your Build Server, and run
NuGet.exe restore YourSolution.sln
As your first build step.
If they are in-house dlls, then you have a few options. The first being, as TeNGiL mentioned, setting up a private NuGet repository, and publishing the in-house dlls, to that feed, and pulling from it within your build server.
The other option is just to create a 'References' directory in source control, which holds dlls, reference them in your solution from the source controlled directory, and then pull them down as part of your Build Configuration. This really isn't as bad as it sounds, within reason, and is a perfectly acceptable interim solution to incorporate until everyone is on board with using a private NuGet feed, or something of that nature.
Open the code in the checkoutdirectory of TeamCIty in visual studio and try and build.I am pretty sure that visual studio will give you the exact error message of what's going wrong.
Missing packages have to be restores. Use a Nuget Installer build step to restore your packages as given in image below.
I installed PostSharp on my project, but everybody has error when get solution, I asked my problem of postsharp technical support he said you must add packages to source control.
Now I am not sure adding packages to source control or no? if I make a mistake again, all of users get error on his project,
I read the number of solutions and test one of them, so I caught error and I can not test they are right, please help me
You have a few options here.
Use NuGet to manage your dependencies. This is by far the easiest option -- you can configure your solution to have NuGet package restore enabled, so when anyone builds your project, if the required dependencies aren't present, they'll be automatically downloaded.
Source control your dependencies in a folder somewhere in your project's structure (like \lib), and then reference those dependencies out of that folder. Ensure that the contents of that folder are in source control.
I have setup a build controller etc and the builds were failing, I have fixed these now and the build failed properly - as in because of an error.
I have fixed the error and checked the code back in but now the code is not being extracted, although sometimes one folder of many is.
I have deleted the code from the build machine and requeued a build but it keeps failing. It complains that it cannot find the solution that I specified as the build solution.
I have checked the check box to build even if nothing has changed.
Have I missed a setting somewhere for extracting the code?
TFS version is 2012 Express
Visual Studio version is 2010 Professional
I had this issue recently with TFS 2012. I think it boils down to this:
In the lastest build definition files, it appears that it performs a Clean task before updating the workspace. This means that if you do something that causes the Clean part of the build to fail, it will never download the new files in order to fix it.
Recently, I was making big changes to my build file and inevitably made a lot of mistakes, I found that if one of these mistakes caused the Clean to break, I had to go onto the Build server and change the file manually to get it working again.
Does this sound like it might be the same issue?
There are several properties in your build definition you can check. I would start with setting the "Clean Workspace" to All to ensure the correct code is being pulled down and built.
There are other checks you can look at as well like the agent set for the build and the "GetVersion" property. Check the below link out. It should be able to help you in more detail.
Define a Build Process that is Based on the Default Template
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