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.
Related
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.
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.
Background
Currently I have many C# projects in many TFS team projects.
Several C# projects reference C# projects in different team projects. I do this by referencing the output dll in the Bin/Release folder of the other C# project.
As long as we checkout & build the solutions in the team projects in the correct order everything works fine on all dev's machines.
We're moving to Visual Studio Online and I'm playing around with automated builds.
Problem
The problem I'm having is that it can't find the dlls to reference, even after the project that would output them (to \Bin\Release) has ran.
I've disabled parallel builds (to ensure the referenced projects get built first) and this seems to be the case based on the build logs. The issue is that the projects that depend on these can't find the dlls and as a result I get "the type or namespace could not be found" errors everywhere.
What's the easiest way of resolving this?
Note that I've read several posts/tutorials etc. about this but all seem to involve changing the source control structure, or fiddling about with workspaces etc. I want something where I can keep the simple workspace mapping on the dev's machines where we map "$\" to "C:\TFS\". I don't want to have to remember to periodically merge in changes from a shared library, or maintain lots of folder mappings within a workspace (on dev machines).
Open your process template xaml (usually DefaultTemplate.11.1.xaml or TfvcTemplate.12.xaml with XML editor, not the designer). Look for mtbwa:MSBuild on Run MSBuild for Project activity. Remove the OutDir attribute, save and check-in. This will force MSBuild to use the default OutDir for each project.
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.
We are using TFS 2008 for Web App dev. The WebApp is a large project, so we do not want every developer to see all the source code, which means lots of libraries or subapps need to be referenced.If I put all the libraries and subapps in one VS2008 Project or VS2008 Team Project, all the source codes will be exposed to each person.
Do I have to make the WebApp reference other Team Project to solve this problem? What is the best way doing so?
Consider each isolated section to be a project (in both the physical and management sense) as independent. Ship release from those shared components/projects and deliver them as binaries to be pulled into the others. You can use a the output from trunk or release branch builds of the shared components to deliver new "releases".
This affords you the option of full branching, work item, reporting etc for each logical project in your organization.
If you let someone be a contributor/developer on a project, then that individual has access to the entire project. If you want to keep someone out of the certain files, then that will need to be under its own TFS project. You would then reference the output assemblies from the parent project in the child project.