I have a vs.net 2012 asp.net c# solution which builds fine. However when I try to Build this trough an automatic build in TFS 2012 it ends with this error:
The message is sort of clear , dlls are not visible for the buildcontroller. The question is what is the path/location the put these dlls in?
The path/location of the dll's doesn't matter as long as
they're added to source control
the folder they're in is mapped in the build definition workspace
the relative path between the project and the dll is not different on the build server
The easiest method is to include them in a subfolder of your solution folder.
A better method is to use NuGet packages with restore on build enabled.
Related
Currently through Azure Devops, I'm setting up a .Net Desktop type with pipe-line that includes assembly libraries. In my understanding this should've work if the scenario was TFS is on-premise and I can just install any 3rd party non-nuget libraries in that server and make the build work. Right now I was able to make this work by literally copying the .dlls but I felt its more of a hack than actually letting the build know that I'm referencing assembly / non-nuget package libraries.
I'm pretty sure i've missed something, is there a way to properly set this up?
Even though it's not a recommend way, but you could check in these libraries/dlls in source control. TFS could download them from server to your build agent and refer them.
First, make sure your local build is successful and if just the TFS build is failing then it is usually due to dll reference path issue. Make sure that the Dll is referenced as a relative path in the project file (.csproj).
To add a relative reference in a separate directory, such as C:\tfs_get\Sources\assembly\abc.dll, do the following:
Add the reference in Visual Studio by right clicking the project in Solution Explorer and selecting Add Reference.
Find the *.csproj where this reference exist and open it in a text editor. Lets say your .csproj location is c:\tfs_get\sources\myfolder\myproject\myproj.csproj
Edit the < HintPath > to be equal to
..\\..\assembly\abc.dll
This build will work properly with the assumption that the folders ( assembly, myfolder) under the sources folder exist in TFS.
Update
Have a folder named "libs", or "libraries", for example, that contains all the assemblies required by your projects to compile and run.
Reference these assembly by right click the reference folder of project and browser to these assemblies files.
For build, in Source Settings (XAML, Build Agent Folder)/Repository, keep the similar structure.
More details please take a look at this similar question : How to properly check in DLLs/assemblies to TFS/Visual Studio Team Services (was VSO)
I have a solution file created with Visual Studio 2013. In it, I have a WCF project which contains some classes, and a Web Application project that calls some functions from WCF file. The web Application is able to reach it from codebehind of .aspx pages.
I have no issue building and compiling the WCF project. However, Visual Studio is unable to identify their classes.
In Web Application project, It underlines the using statement of the WCF class library in red, shows "Type or namespace could not be found" error. It takes the class from the file created by WCF automatically by Visual Studio.
WCF project is doing the same inside too. The two classes are in the same namespace, in fact, literally in same file together. Yet they can't see each other.
Long story short: I have 2 different projects in the same solution, they work and compile very well, but Visual Studio is unable to identify some of the classes in intellisense, even suggests to create new class. What would cause this?
EDIT: I removed the project from TFS, and the classes are colored properly, and so is the intellisense. Perhaps some files are locked as checked in, and causes trouble?
Usually we do not suggest adding the BIN and the OBJ folders to source control, but do add the 3rd party dll's or using nuget package to handle them. Basically all that you need as input for your application is in source control, but the output of you application (the created dll's, pdb's etc) should not be included.
If you insist on this, first please double check you have add all related dlls in source control(check in them).
Then if your local build is successful and just the TFS build is failing
then it is usually due to dll reference path issue. Make sure that the
Dll is referenced as a relative path in the project file (.csproj).
Also give a try with adding the dll files into the bin folder where the builds located in TFS server. That .dll needs to be on whatever machine(build server) is running the build and the build definition needs to be pointing at that location.
Please take a look at this similar question: Namespace could not be found - building using TFS
I unticked readonly option from my .sln file.
I opened my .sln file with notepad and removed all the "GlobalSection" properties. (Related with TFS)
This solved the problem.
I am trying to build a project in Visual Studio 2013. There are no errors with the project but it will not build. There are several other projects in the solution and they are all building and push the DLL to the bin/Debug location just fine. This particular project suddenly does not. Any ideas? I have set Copy Local to true and verified the path for which it is supposed to push the DLL and it is bin\Debug.
Double check the following:
Open the Configuration Manager for the solution, verify that "Build" is checked off for the configuration currently being used.
BuildAction property is set to "Compile" for the source code file(s) in the project (look in the properties window when you have the source file selected in the Solution Explorer)
We have some assemblies that are not referenced by our solution directly but are required for other libraries we are using.
I noticed in VS 2010 you can add a deployable assemblies folder and that would cause the files in it to get copied to the bin while building, it seems this was removed in 2012 as all of the Microsoft stuff is available in nuget now.
What is the best way to achieve this same effect, can I just add a folder to my project and add an after build copy task to copy all of that into the bin or is there a better way to go about this.
Currently the dlls are sitting in the project root and have their build action set to content which I gather makes them get copied to the bin, however I'd like to make it a bit simpler and not have to rely on having to set things as content.
What you're doing already isn't a terrible way of handling things, to be honest, and the way we've always done so here in my day job is simply to add the assemblies into our solution as references; that does mean that they pollute Intellisense, however.
Alternatively, Phil Haack blogged that you can create a folder called _bin_deployableAssemblies and put your files in there; Visual Studio 2010 will automagically copy those into your bin folder as a part of its default build action.
This doesn't work with TFS msbuild scripts, apparently, so The Dev Stop guys blogged about how to get that to work with TFS, using a customised Target in your msbuild script.
If _bin_deployableAssemblies is no longer working in Visual Studio 2012, I would guess you could add a build action to your project file, based on the TFS build action from The Dev Stop?
I have a Website Project in Visual Studio 2010 along with a Class Library Project. When I try to build the Solution from Visual Studio 2010 it builds successfully but fails in TFS 2010 Build. I have some custom .dll files added to website and it throws error in my class that following method is undefined. The same thing builds 100% ok in VS 2010. Earlier I had a different project structure but since then I even changed the project and file structure following this article on MSDN for TFS 2010 Version control.
The Build fails and it drops a log file in the drop folder.
EDIT
Some of the errors in the log files are related like this.
error BC30451: 'AutoCompleteExtender' is not declared. It may be inaccessible due to its protection level.
error BC30002: Type 'IFileNameGenerator' is not defined.
These errors don't show up in VS2010.
This problem could occur when you are referencing a DLL from your solution that is not installed on the server or is somewhere in your project structure but not included in your TFS source control.
If you look at your build summary in TFS you have a 'View Log' option that shows more details. You can also specify a log verbosity in your buil;d definition template. Increasing this could give you some hints.
Read the log file. Searching for :error usually helps
Had the same problem with a contract in a nuget package. Turns out it was a bad merge. Compare the csproj/vbproj files and see if there are any differences in package versions