I have decided to start using Team City as my continuous integration software and I am having some problems how I should handle my project references as the assemblies my projects depends upon are located at different locations in my developer solutions and the solutions in team city (I am using the vs2008 solution files option for the builds in team city). The problem is that the projects builds in development and fails in team city.
How should I handle the different project references in the project files?
ex. My MVC app references a common util assembly I use in other projects as well. In my developer solution I add this project to the solution but I do not want this in team city build so I have a different solution file there.
It sounds like you should split your code up into multiple solutions. When projects in one solution need to access binaries from projects in another solution, then they should not add those foreign projects into the solution. Instead of using project refrences, use file references.
This means that you need to deploy the results of completed builds to some common location, posisbly a share.
See patterns & practices: Visual Studio 2005 Team System Guidance. It's for TFS and 2005, butthe general concepts apply to many other source control systems.
Related
I have my own TFS (visual studio online) and work TFS. In my TFS located my own projects and, in particular, the project with useful utilities. I want to connect it to the work TFS solution, but keep getting an error, which essentially boils down to the fact that you can not connect a project in more than one TFS. Can I achieve the desired result?
No you cannot use multiple Team Foundation Server instances at one time. When you switch a project, you switch to the TFS server that it's stored in.
The recommended way to share utility code like you're talking about is by sharing only the binaries. This can be done using NuGet. You can setup your own NuGet repository and then let your utility project publish to your NuGet server. Other projects can include your NuGet packages just as you use external packages.
You can find a great overview of what NuGet can do here.
In every tutorial and HowTo site (like here) about WiX I read I should add reference to my other project, but when I select Add Reference I have nothing on Project list in Project tab. I try this on Visual Studio 2012, earlier with WiX 3.7 and now on 3.8.
If there is solution simply not using "Add Reference" function how can I build this other way? I'm a beginner so I don't really know how to use WiX without this feature, if I published my C# application in Publish Wizard I should add all produced files to Component Group with every file in <Component> tag?
It could be this simple...
In Visual Studio, Add Reference's Project tab only lists projects in the same solution. You just need to Add Project to the solution and go back to the Add Reference's dialog.
A solution is just a set of zero or more projects that can be built together. You can have a project in more than one solution. The only limitation is that if project B references project A (B is downstream of A), A should be in every solution that contains B. If the universe of projects is small, it is typical to have only one solution for them all. On the other hand, if one developer works only on upstream projects, that developer might find it easier to work with a solution that doesn't have downstream projects.
Setup projects tend to be downstream but note that they probably don't depend on library test projects.
[Stream is not the best technical term. The universe of connected projects is a directed acyclic graph.]
I'm new package management systems so I'm trying to understand where they are useful and where they are not.
My office has several Visual Studio helper projects that we use in various solutions. Right now we just reference the helper project within the product solution. Is there a benefit in using NuGet to package these helper projects? At most, we have 5 to 10 developers on our team at any one time.
It depends on how often your common projects change, whether you need to keep more then one versions of the project for other or not. For me I have found the following:
Pros:
If you need keep more than one version of common project, it's make
your life much more easy.
It supports same libraries for different frameworks in one package.
Your product solutions have less projects, so VisualStudio and Resharper works faster.
It disciplines your team to write unit-tests, because test common project by unit-tests much more easy then functionally in an end product.
Cons:
If you need often update your common projects, it can be annoying.
But you can setup CI to do it for you.
There are a number of other questions related to this topic:
Whats a good standard code layout for a php application (deleted)
How to structure a java application, in other words: where do I put my classes?
Recommended Source Control Directory Structure?
Structure of Projects in Version Control
I could not find any specific to VSTF, which has some capabilities like Team Build, integrated Unit Testing, etc. I'm wondering if these capabilities lead to a slightly different source layout recommendation.
Please post example of high level directory structures that you have had good luck with an explain why you like them. I'll let people vote on a "best" approach and I'll award the answer in a few days.
Here is one that I like:
Private; all of the current system deliverables
Documentation; a rollup of all the documentation across the solutions that make up the product, output would be MSDN style documentation from Sandcastle
Common; Visual Studio SLN that contains all the projects that are common across all the other solutions.
Tools; Visual Studio SLN that contains all the projects whose output is a tool. Example might be a console app that performs a set of administrative task on the larger system
Developer; each developer has their own folder which they can use for storing whatever they want
Specific Developer (1..n); this contains any build settings, scripts, and tools that this specific developer chooses to store in the source control system (they can do whatever they want here)
Specific Deliverable Solution (1..n); Visual Studio SLN that contains all the projects for a specific major deliverable
Common; solution folder that contains Visual Studio Projects that are shared within the current solution
UI; solution folder that contains Visual Studio Projects that define user experience
DataLayer; solution folder that contains Visual Studio Projects that define a data access layer
Services; solution folder that contains Visual Studio Projects that define web services
Tools; solution folder that contains Visual Studio Projects that define tools specific to this deliverable (executable utilities)
Tests; solution folder that contains Visual Studio Projects that contain unit tests
Public; all of the external dependencies associated with the system (eg. 3rd party libraries)
Vendor; dependencies provided by a specific vendor
Build; Visual Studio SLN that contains code associated with the build of the project, in our case mostly custom MSBuild tasks and Powershell scripts
Target; each successful build of the product as well as point releases
Debug; all of the debug builds that are output from weekly builds and continuous integration. Developers do not manually manage this directory
Build Number; a directory that corresponds with the current build number
Solution Output; a directory that contains all the build output for each of the projects in a given solution
Release; all of the release builds that are output manually when a milestone is reached
Build Number; a directory that corresponds with the current build number
Solution Output; a directory that contains all the build output for each of the projects in a given solution
Note: All solutions will have a Tests folder and unit test projects.
A few thoughts:
Very few files in the root of the tree. On a large team, set permissions so that no one can add new files to the root of the tree, without some kind of authorization.
The default workspace will contain:
Tools contains all executable code required to build & run unit tests, including your custom tools and scripts (perhaps assuming that Visual Studio and PowerShell are already installed on the machine).
ReferencedAssemblies has things you pick up from somewhere else, including things you buy or download and things someone on the team wrote but isn't part of this project.
If available, source code should be in here, too, so you can service it yourself. (If not available, you're taking a big riks.)
Source - all the source code, including project files.
Documents - items that are not used as part of the build, but are necessary for the proper functioning of the development effort.
Binaries - bits that have been shipped to customers, including .PDBs and other artifacts necessary for servicing. (On small projects, I fork the sources for each release, but normally a tag/label is a better choice.)
Elsewhere (e.g. $/personal) have a place for each person to do with as they please ($/personal/USERNAME). For example, my side projects go here.
In Eclipse, I have a workspace that contains all of my projects. Each project builds and compiles separately. A project does not interact with another project.
How does this relate to Visual Studio and Projects/Solutions there?
A VS project is it's own entity. It will build and compile by itself. A Solution is just a way to contain multiple projects. The projects don't necessarily need the other projects to compile (though, they can depend on the other projects).
This just lets you conceptually group projects together into one Big Project. For instance, you can have a separate testing project. It depends on the code from the actual project, and should be kept together with the actual project, but it does not need to be in the same exe/dll.
Each VS project builds a single EXE or DLL. The solution is just a collection of related projects.
So VS project:Eclipse project::VS solution:Eclipse workspace.
Another way to look at it is, a solution is a container for projects. For most of my work , I create each tier as a project within a solution so my tree looks like:
My Web App or Win App
Presentation Layer
files...
Business Layer
files...
Data Access
files
Your mileage may vary
#Thomas Owens:
Yes, some (most?) people using Eclipse have more than one workspace. It's what surprised me the most when I first started using Eclipse, so I'm replying here to make this comment more visible.
The thing that may be throwing you off is the following:
In VS2003, everything had a Project file and a Solution file. If you had a Solution with one Project, you could open the Solution and see the one Project. If you opened the Project, it would try and create a new Solution file to contain the Project. But web projects and Winform projects all had Projects and Solutions.
In VS2005 this changed a bit - by default now, Web projects no longer had Project files. They had received feedback from some web developers that didn't like Project files - their take was that if a file is in the directory, it's part of the app. After VS2005 shipped, they got more feedback from developers who did like the Project file notion, so they patched it back in. This is "Web Site" versus "Web Application" in VS2005 (and I can't remember which is which now).
In addition, in VS2005, if you have a Solution open with only one Project, you won't see in the Solution Explorer that there's even a Solution at all, you'll only see the Project (as if it was not in a Solution). Only after adding the second Project will you see that there's a Solution containing them both.
So basically you were on the right track - Solutions and Projects work the same in Visual Studio as they did in Eclipse, it's just some quirks that make things confusing.
A Solution has 0 or many Projects...
There are way too many kinds of web projects in Visual Studio 2008. There are Web Site Projects vs. Web Application Projects and they limit you in different ways. It's a good example of Microsoft providing too many choices instead of focusing on one strong solution. Even within the Web site Project option, there are at least 3 different ways to compile your application.
I found that not always seeing the solution in the Solution Explorer to be irritating. There is a setting in Options->Projects and Solutions->General called "Always Show Solution" which was handy.