I work at a startup. Recently, we planned to build up a workspace so that our team can work together efficiently by sharing and we can have multiple projects inside our workspace.
We are integrating a number of 3rdparty libraries[with code] in our cross platform workspace. Wondering if we could get some existing project workspace which already has large number of 3rdparty libraries and useful code snippets integrated.
We found Boost and GraphicsMagick to be very good for our purpose though.
You might want to look into using tools to autogenerate your workspace/solution files so that you can load them up in your IDE and have the proper linker and include paths already set.
At my company, we started using CMake, which can generate solution files for Microsoft Visual Studio, Eclipse with CDT, KDevelop3, code::blocks, and a variety Makefiles.
An alternative is Scons which can perform the same tasks, but I do not know what kind of files they generate other than Visual Studio .sln files.
Makes it less painful when you have to start changing software versions, and you do not have to share a workspace configuration that could be dependent on set paths on a user's machine.
Related
I would like to convert omake projects (clearcase) to msbuild (TFS). Please let me know whether any tool is available for the conversion. I would appricate if you have give me an example
omake project is a Rational® ClearCase® utility to build, maintain, update, and regenerate groups of programs. It includes many of the configuration management facilities provided by the clearmake utility.
omake is intended for use in dynamic views. You can use omake in a snapshot view, but none of the features that distinguish it from ordinary make programs (build avoidance, build auditing, derived object sharing, and so on) works in snapshot views
I don't think TFS would offer workspaces running like a dynamic view, or orffering similar clearmake-like features like DO and winkins.
So there isn't any conversion possible to my knowledge: those projects becomes simple make/Makefile projects once migrated in their new TFS referential.
Regarding the more general issue of converting a Makefile to a .sln file, that old question mentioned the Makefile Project Wizard, also mentioned in this thread and in this page:
If you have a project that you build from the command line with a makefile, then the Visual Studio development environment will not recognize your project.
To open and build your project using Visual Studio, first create an empty project containing the appropriate build settings using the Makefile Project Wizard.
You can then use this project to build your project from the Visual Studio development environment.
The XCode documentation on the concepts of Targets and Projects are helpful, but still I am not certain on the best practices to use in my situation.
I have an existing codebase (used for Windows as well as iOS) in a single SVN repository, which has just been refactored from one single test application into a central library and an application. The idea is more applications will use this central library over time.
An XCode project maps one set of source files to one or more targets, so I could have a single project for my whole codebase and one target for the library and one for each app. However each app will obviously have its own code, so it seems a bit clunky to throw all the source into a single project this way.
Alternatively I could have a workspace with multiple projects, each having a single target. This is much more how I have things set up for the Windows build, where a Visual Studio solution corresponds to the Xcode workspace, and a VC++ project would map neatly against how XCode projects are organised.
But are there 'normal' / expected ways to do things in this kind of situation, some unofficial standards I should try to follow so other developers don't get confused?
Targets nowadays are used to build dependencies and separate builds within a project. You'll see it being used mainly for unit testing. Occasionally, you might have different binaries available to different processors or operating systems, but this is a rarity in today's app store world.
Generally, you'd have one project for each executable. This allows it to be worked on independently and compiled separately without interfering with each other.
You can include projects within projects, which allows you to work on them independently and set up dependencies for them. You can set up a project to build a sub-project and deposit it's executable in a location for your project to link to.
I would say for your situation, make a library project with executable and testing targets. Then include that project in other projects and you can link to or move the files to your other project's location. Here's the gist of how to do it.
I know you don't mention them, but workspaces were basically added to allow you to have multiple projects open in a single window. You can have all your test applications and reference code available without them compiling in the background as well. I find it super handy.
The key difference is that each target is in exactly one project, but one project can be a part of many workspaces. This lets you have projects Lib, AppA, and AppB, and then WorkspaceA = [AppA, Lib] and WorkspaceB = [AppB, Lib], so that developers working on AppA don't have to load stuff related to AppB. As a general recommendation it's a good idea to create projects for things that you might want to share independently.
When I share code between one or more projects (be it Xcode or another IDE), I typically compile the shared parts into a binary and then link it to the code specific projects.
In your setup, something like an Xcode project just to compile a dylib from shared C++ files, and then a main Xcode project that links with this dylib.
At my work we are just starting to use TFS with our team of 4 developers, and are at the same time transitioning from single developer projects to team projects. We are mostly using the default settings in TFS
I was the first to push up a simple Silverlight MVVM project consisting of a solution with a Silverlight and a web project.
When my team-mate pulled down my code and tried to compile, he was faced with many missing references (.dlls), Expression blend SDK, Ria Services toolkit, Telerik controls, simple mvvm toolkit, silverlight toolkit, etc.
What do we need to do, to add projects to TFS that have everything needed to be compile it when the next developer pulls it down?
There isn't a really good way to do this all automatically. What you'd generally do this this:
in your branch create a bin folder next to your src folder.
in the bin folder create folders for each component you're relying on
in each folder place the setup or a link to the setup
in each folder place the binary files you're using in your solution
in each folder place a readme with any manual steps that must be completed
if wanted you can create a powershell script or batch file which installs all required components. It isn't too hard to detect whether or not an application is already installed using powershell and wmi
Now you'll have to fix a few things in your solution:
make sure your references don't point to the GAC, but that they point to the assemblies inside the bin folder of your branch
make sure all the paths are relative to the solution. Any c:... paths will not carry over from one system to another
I found that the easiest way to do this is to unload the project in Visual Studio and then edit it. You can then quickly add hintpath="..\..\..\bin\component attributes to each reference. There are a few blog on this subject which provide different solutions which all solve this same issue.
This setup allows you to at least get the latest version of any solution and build it without having to install any tools. If some of your components rely on visual studio add-ins, then the designers for these tools usually won't work, but at least you're able to build them.
An often used alternative is to create a Virtual Machine base image for your project and install all the required components onto it. Then copy the image to each developers workstation and sysprep it to ensure they all have a unique name and identifiers. When the project needs to update its dependencies, let one developer create a new clean machine and re-distribute that to all team members.
If you're using Windows Server Virtualization or VMWare, it's quite easy to create differencing disks and allow developers to access these images remotely.
Another approach would be to use NuGet and script NuGet using a powershell script for your solution. This will work for most cases, but products like Expression Blend still need to be installed separately.
TFS 2008 and Common Libraries
I have created a Team Project called "Common Library" that will host code used in numerous different Team Projects throughout TFS. For sake of argument, lets say we have 2 distinct Librarys under the "Common Library" Team Projects, MailProject and LoggingProject. Other projects throughout TFS will be using the binary representation of these projects via branching and not the actual source code.
What is the best way to set up the folder structure for this Team Project? Do I add the project to the "Common Library" and simply "include" the bin/release folder as part of the project?
I have seen some examples of people creating a seperate "Deploy" folder. I assume this is synonamous with the bin/release folder?
We do not want the source code available in other solutions.
Currently, each project has the dll included in the project. Using a mailing module as an example, many projects need the ability to mail. The common module is very stable and mostly static.
However, what if there is a change in the mail module. It seems there would be a better way, than to check out each project and update the dll. Is it possible to allow TFS to grab the latest mail module any time a 'get latest' is called? Either explicitly or implicitly.
Unless you really require the source code for the libraries to be available in the other solutions my advice would be to include the binaries for the libraries in the projects that would use them not really having any explicit link between the two in TFS. Custom labelling of the library builds could be helpful to easily return and rebuild any chosen version of the shared libraries.
If the shared libraries require different versions for different projects then the obvious solution would to create a separate branch for every version of the libraries that need to be customised to a particular project.
TFS does not have a concept similar to SVN's 'externals' though - so if you include a branch from the shared libraries in a project and than branch that project it is very difficult to propagate changes correctly.
I suppose you could also use the Get task in the build and get the latest version of DDLs into the current project from another one, but verify if you can point of Workspace of another project (I have not tired it and MSDN is somewhat vague here). You might need to have a separate workspace for the shared project.
Yet another alternative would be to publish the DLLs for common components to a known location on every build of the shared libs and for individual builds to get whatever version is available from that common location (network share) even via the Copy task. This is simplistic and may cause problems with versioning of the common components but should work well enough in simple case.
We Have a large VS solution using project references which is build by TFS Build like so:
Solution
- Project 1
- Project 2
- Project ...
- Project N
Because the solution is too large we have several smaller solutions which we use day to day:
SubSolution
- Project 1
- Project 19
The problem is that developers working on SubSolution find that it is not building because the project references could not be found, so they change the projects to use file references.
This then goes on to break the TFS Build which cannot find these file references because they have not been built yet (Even though the projects are in the same solution). Is there a way around this tug of war between the two types of references. What is the correct way of splitting out your solutions?
What is the correct way of splitting out your solutions?
Check out this chapter from the TFS guide by the Patterns & Practices team:
Chapter 3 - Structuring Projects and Solutions in Source Control
Pay special attention to this note to the "Partitioned Solution" scenario (which I believe you're actually trying to implement):
Unlike previous versions of Visual Studio, Visual Studio 2005 relies upon MSBuild. It is now possible to create solution structures that do not include all referenced projects and still build without errors. As long as the master solution has been built first, generating the binary output from each project, MSBuild is able to follow project references outside the bounds of your solution and build successfully. This only works if you use project references, not file references. You can successfully build solutions created this way from the Visual Studio build command line and from the IDE, but not with Team Build by default. In order to build successfully with Team Build use the master solution that includes all of the projects and dependencies.
Regardless of how you organise your build, developers should understand how references work, and be aware when they make changes to references that they shouldn't check those changes in unless they intended to make a change to the build process.
On the subject of organising your builds - as Dmytrol says, project references should work between solutions (As long as the target is already built, however that's also the case for file references anyway).
My advice would be to group your projects into small workable solutions and use project references within those solutions. Your main solution file / build can use project references too, however if you find project references between the smaller solutions too difficult to maintain you can use file references instead, and control the build order through project dependencies or the project build order (accessible within Visual Studio by right-clicking on a project in your solution).