Assembly references missing errors while building solution on TFS 2013 - tfs

i have a solution which contains 3 projects (DAL,BLL and Utility) and one website.
I tried to build solution locally but it was giving some missing references errors. i added missing dll's and build was success locally.
i checked in whole solution to TFS 2013 server. and tried to build solution on tfs through build definition. Butbuild fails with many errors (missing assembly reference).
in source control i cant see any bin file so that i can add dlls.
What am i missing? how can i add referenced to a project on TFS?

You should not check binaries into any source control system.
If your referenced assemblies are available on Nuget then use nuget to reference them correctly.
If your referenced assemblies are not on Nuget them you should package them as a Nuget package, stick it on a fileshare (or better yet MyGet), and take a reference on that Nuget package.
The question is irrelevant, the answer is nuget 😊

Related

Nuget Restore in MS Build Step

In my asp.net web application, i have solution with 5 projects and nuget.org. In TFS Build Definition,
1) While building the whole solution in Visual Studio Build Task
Nuget packages getting restored.
2) While trying to generate executable files for individual projects in MS Build Task
If I select Restore Nuget packages, It's not finding nuget packages and step getting failed with message - "Process 'NuGet.exe' exited with code '1'."
I have tried many references online and none worked. Any suggestions on how to solve this?
Do i need to make any changes in the nuget.config file to support restoring
packages to individual projects.
Do not directly select Restore Nuget pacakges in MS build task configuration. This option is deprecated. To restore NuGet packages, add a NuGet Installer step before the build.
(Important) This option is deprecated. Make sure to clear this
checkbox and instead use the NuGet Installer build step.
Source Link: MSBuild
Besides, you could also build single project not the entire solution in Visual Studio Build task. Just select the project (.*proj) files instead of .sln file.
Unless you are building a customized MSBuild project file, then we recommend you use the MSBuild step instead of the Visual Studio Build step.
You could also try to build single project using Visual Studio Build task, see if the issue is still exists.
Same problem, downgraded to 4.4.1. it helped

Build failure - Restore package option not working in Visual Studio Team Services (was VS Online)

I am using a TFS Git project in Team Services and while my project compiles locally, I get a build failure when I check in my code to VS online and manually queue the build.
The errors at the moment are only pertaining to enterprise library data access dlls. I am using V6 of the library and this is error I get
The type or namespace name 'Practices' does not exist in the namespace 'Microsoft' (are you missing an assembly reference?)
In my build definition I have checked the box against both Restore Nuget Packages and when that alone did not work, I checked the box against [Clean] as well. I still get that error. My packages.config files are checked in for each of the projects in the solution. I also have the Packages folder checked in but this folder has no dlls. It only has the various .nupkg files and respective .xml files checked in. Is this causing the problem?
Yes, you have to either checkin the DLLs or delete the nupkg files. The build server thinks you already have the packages so its not trying to restore them but the DLLs aren't there to reference.

How to fix namespace issues after TFS check-ins?

In setting up a solution for multiple developers, after checking in then checking out on another system, I consistently get the following error:
The type or namespace name 'OData' does not exist in the namespace
'System.Web.Http' (are you missing an assembly reference?)
Without checking in the bin folder, how can this be resolved on the working dev machine?
I found that the System.Web.Http.OData namespace is from Microsoft.AspNet.WebApi.OData which you can install from NuGet. So, to correct your current issue, right click the MVC project on that machine, select Manage NuGet Package, find Microsoft.AspNet.WebApi.OData to install it.
You can get visual studio to download the Nuget packages when you do a build locally, you can enable this through
Tools > NuGet Package Manager >Package Manager Settings
That way you're packages are not added to TFS and anything that your colleagues add to the solution will be automatically downloaded when you rebuild the code, when you first check out from source control

NuGet adds Packages folder to the solution. Should it be part of Source control?

I am using NuGet to add packages to my solution. NuGet added a Packages folder to my visual studio’s solution root folder. The concerning part is that the “packages” folder is not part of source control. That means the source code comes from TFS, but the project references come from a folder that is fed by external source. People can put malicious code in the packages folder and build the application.
I like to understand how my other colleagues that get the source code from the TFS source control can build the project with packages folder not being part of the source control?
We did have a similar problem where our build server wasn't allowed to have internet connection, so couldn't download packages. We started with creating our own NuGet Source, which was simply a shared folder with all packages copied to it. The visual studio projects would of course use these packages rather than packages hosted on www.nuget.org
I must say that we scrapped this idea because of the overhead of doing it as our package usage increased.
My advise is that if you are worried about packages downloaded at build time, store the packages folder on source control.
NuGet supports automatic package restoration so your colleagues who use this feature will automatically download required packages. There is a policy at nuget.org that prevents user to delete or update exact version of package once it is published so it can support package restore without any interruptions - see this answer for more detail. If you are using other package sources than nuget.org than you should check their package deletion/update policy because it may be different.

Referenced Dll's not found in Team Foundation Service (or: nuget packages not available on other pc)

when I create a build for the Team Foundation Service, I get all kind of reference dll's not found exceptions.
These references are added by nugget packages.
I've added the 'package restore' option on the solution which added 3 files in a .NuGet folder.
EDIT
When i got the solution from TFS on another pc, i got the same errors (missing dll's), so it's not only the TFS build service having problems.
The missing dll's are are missing files from installed nuget packages (some are part of the default VS template, Unity was a package i added later), which (the packages) are added on the first pc, but then are missing on the next pc (that's why i added the 'or' in the title of this question)
How can i get the Nuget added files on pc2 too?
I guess you've found a solution by now. I write this just to provide an answer for this question.
To have NuGet packages automatically downloaded on another PC, you need to enable NuGet package restore on build. You do this in two steps:
Right click the solution and select Enable NuGet Package Restore.
This will add a .nuget solution folder with NuGet.Config, NuGet.exe and NuGet.targets underneath it. These files should actually be checked in to source control, but the binary file is tiny. It will also modify the MSBuild scripts in all projects of the solution to import the NuGet.targets file to hook NuGet into the build process.
In Tools -> Library Package Manager -> Package Manager Settings make sure the option 'Allow NuGet to download missing packages during build' is checked.
This step must be done on all machines.
Now the BuildDependsOn property of all project build scripts should make the RestorePackages target in NuGet.targets kick in and download missing packages before you get build errors for missing references.

Resources