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.
Related
I am trying build automation for a project developed using legacy language called Team Developer 6. where each file needs to be compiled as an exe. also need to do some filter activity before building exes. there are 300 exes.
this process I could do in simple .Net utility which does the filtering and invokes Team Developer compiler for required files.
Is it possible to put this in to TFS build work flow? what is the best approach for this?
Write an MSBuild project that invokes the necessary commands for the tooling you require and check it in. In the TFS build definition, make use of the default template (at first) and set the MSBuild project file you created as the 'project to build'.
This way you can test your build process locally with MSBuild on the command line, and determine which command line switches you might need. You can set command line switches into the build definition, or if you need some further control you can modify the default template to inject the command line switches directly into the MSBuild activity.
I recommend this way, as then you won't have to create any customized workflow, and can avoid having to go down the road of using custom workflow activities in TFS (which is absolutely supported, but in my opinion a bit difficult to diagnose/debug/maintain/upgrade).
You would ideally want to use an InvokeProcess activity to call an executable which does the filtering and invoking. An alternative but more complex approach would be to create a custom activity, but that requires installation of binaries on the build servers.
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.
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.
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.
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).