This is the extension of the following Stack Overflow question
Scenario:
Visual Studio Solution has projects A, B & C.
Project A is core library used by B & C.
Remote employee has permission to access only project C (which needs project A).
Question:
How can remote employee build and test project C which references project A, while remote employee has permission to access only project C.
Is it necessary to share project A with remote employee or is there any way around.
You can simply remove Project A from the solution. Obviously, the other projects would still need the relevant dlls.
If there is very sensitive information in project A then I have the following suggestion (of course this will depend on your architecture):
Create a public interface for project A, put this in Project D or something.
Make project A use this, then create a mock for the Project A interface and provide this project instead.
This would give all the dependencies necessary, and mean that you don't have to provide the dependant dlls. It is also good practice for unit testing.
In order to solve this, you need to
Move project C out of the solution into a solution of its own.
Change the project reference from C to A to a binary reference so that C references the compiled output of A. In order to do this, place A.dll in a directory under the newly created C-solution. Also add A.dll to source control so that the remote employee can retrieve the solution and A.dll from source control.
If you make changes to A that are required in project C, you need to check out A.dll, substitute it by the new version and check it in again.
Of course this means that the effort is higher if you want to propagate changes made to project A to the newly created C-solution. But it separates the environments cleanly from one another.
This approach also works if you want to follow the excellent suggestion of #pm_2 about extracting the relevant interface of A and provide only a mock version to the remote employee. In this case, you place the interface dll and the mock version to source control.
Related
Scenario. A team has 5 developers and all developers are working independantly on 4 different projects. iOS / OS X. A library has been created which encompasses multiple subclasses, categories and so on for reuse. Each member in this team needs to be able to use this library for each project. The library itself has it's own git repo. When someone makes a change to the library it is handled the same way a standard project is handled and a merge is completed.
Problem I see with this approach...
1. This doesn't seem like common practice for a proper Xcode / Git workflow and I feel a framework or similar would be a better tactic.
2. Although this is great for sharing I can also see this as an issue since one issue with the library will break all existing projects.
3. Adding classes to this library requires each project to be updated to include the new headers.
4. Directory structure can differ on each machine therefore a simple clone of a repo will not work as expected without folder modification.
What is the best way to handle your own library of classes in a Xcode / team environment of multiple users?
If you must have a single library for all this - you can go two ways:
Nobody changes the library, the library is as it is and everyone just pulls it down and then makes changes in their code to make-up for the shortcomings they find in the library.
Everyone changes the library, but the project has A master branch, a stage branch, and a branch for every single project associated with it. Devs change and update their respective project branch, and another person (perhaps one of the project devs maintains the flow from the multipe dev to the single stage to the single master branch). With this approach, it requires much more management but you can slowly improve the main library without potentially breaking other projects as everyone has their own specific know-to-work version of the library in a branch specific to their project, only re-syncing with the master when safe.
Using TFS 2010 I need to build a solution that depends on a couple of other solutions held in different team projects. I'm editing my build definition and I create a list of "Projects to Build'. When it comes to build the parent solution I get an error because it's unable to reference assemblies created by the other solutions. So I go back to edit build definition and add /p:ReferencePath="c:\builds\3\referencedproject\binaries\" to the "MSBuild Arguments" Build process parameters.
Problem is, I don't want to hard code the c:\build\3. I guess there may be a $() property I can use in its place - can anyone please advise?
The other problem I have is that the 'Main' project and the two other projects that it references live at the same level in the source code. As far as I can tell, I have to set the source control folder to be the level above this - which happens to be the root. This means that TFS Build does a get of all the projects on the root - which includes dozens of projects that are not required for my build. It's not a critical issue since it makes no attempt to compile these non-related projects but it does increase the time for the build cycle to complete. Is this only way to avoid this to "group" the projects that are required for my build into a different TFS source folder?
For the references issue there are a few options. The most common one taking an explicit dependency on a specific version by checking in the binary to TFS.
For example, if you have Team Project A that has a dependency on Team Project B, I would assume they are setup as separate projects because they evolve differently, probably have different teams working on them, and have different release cycles. The common approach to managing this dependency is to checkin B.dll into Team Project A (usually in a lib folder specifically for this purpose), then use a file reference from within Project A's solution/projects to the dll in the lib folder.
This approach lets the Project A team explicitly choose which version of B.dll they wish to depend on, and make an explicit decision to adopt newer versions of B.dll on their own timetable.
For the other question of how to have a build definition download only select source code paths, you can specify multiple lines in the Workspace mapping screen when setting up a build definition. For example you could have the following:
$\ProjectA -> $(SourceDir)\ProjectA
$\ProjectB -> $(SourceDir)\ProjectB
This would download Project A + B but not C.
I'll start with problem 2 as this should be easiest to solve.
You have 2 options both involve changing the workspace mapping of your Build Definition.
You don't have to map at the folder "above", you can map individual folders so if your source looks like this.
$/TP/SolutionA
$/TP/Folder1/SolutionB
$/TP/Folder1/SolutionC
$/TP/Folder2/SolutionD
and you only want to include SolutionA and SolutionC in your build, you could set the workspace up as follows.
This will get just the code you need and preserve the relative paths between them.
Another option is to use cloaking, you map the "Root" folder and then cloak any folders you want the build to ignore.
Both of these methods will restrict the amount of source being downloaded when the build runs, and also prevent "continuous" builds from starting when checkins occur in the folders that haven't been mapped / Cloaked.
Problem number 1.
As Dylan suggests, probably the best thing to do is to use Binary References between solutions. Especially solutions in seperate team projects.
Check out my answer to this question for a full description.
I want to move files from Project B to Project A.
There are answers on stackoverflow about Modules, but that also looks like a lot of work to refactor the Project B as a module.
Another way is the manually move the files from Project B to Project A, but there would be sync issues when the files from Project B are updated. Is there an easier solution?
The reason I am doing this is Project B is a checkout system that can be used for various projects.
It sounds like project B really needs to be gemified into a rails engine.
When you say files do you just mean code?
You can create a gem from Project B (and treat it as an external service, if it is set up to act as such), or you actually mount Project B onto Project A. There is a RailsCast on Mountable Engines, or you can check out the official documentation on Engines.
We are moving to TFS 2010 (from PVCS) for source control and work item tracking
As I understand it you should have under source control for each TFS project everything that projects solutions, etc. need to build.
This OK for new .NET solutions/projects, but we have a large collection of legacy Delphi 6 projects with shared source libraries we want to port into TFS for source control and build. It is how we manage multiple TFS projects that want to sare a specific set of source files between them that is my problem here.
Historically with PVCS we have had projects for each solution (say A & B), and a seperate project for common source code (say C). Users would get C then get either A or B (checking out as required) on disk this would maifest as something like this:
$\Projects\C
$\Projects\B
But B & C are seperate PVCS archives.
Now fast forward to life with TFS 2010 as our ALM solution...
If we create a TFS project (1) that contains the source repository for the common code (C), that projecs can obviously access it (lets say the TFS project also contains the solution A) and all is good.
We now create a new TFS project (2) in which to make solution B. Beacuse solution B is wildy different to solution A we had no reason to share TFS project 1's source control so we made a new source repository rather than branching from 1. Now later on we discover a need for solution B to access some common files from C (in 1). Oops!
The question is this; can I perform some source control wizzardry that lets me add a folder in the 2's soruce control that is a (to steal a file system term) symbolic link into 1's source control for the common code C?
Edit
I should point out this is all legacy code and the shared source library (C) is just that shared source it does not build into a library or other binary we could simply add to A or B.
In TFS 2010, as you may know, they introduced the concept of a project collection (PC). Each project collection is an aggregate for team projects (TP). Each PC is stored in a separate database, and the VCS is stored in the database.
This means that there is one VCS repository per PC, not TP. Each TP is (by default) the root folder in each VCS (i.e. TP1 will be at $/Prj1, TP2 might be at 4/Prj2, etc.)
One more point is that you do not want to have one solution per TP. Think of a TP as a suite of products, and a solution as a part of that.
Symbolic links, as per Visual Source Safe, no longer exist in TFS, and I'm not sure you need them. It is not considered a good practice to create a dependency between one solution and the source code of another solution.
What I suggest you do, is have each solution in your codebase depend only on its own code, and on other solutions' binary deliveries.
What will happen is that if Sln_A depends on Common_Sln, you will build Common_Sln, and bring its binaries from the drop location as part of your Get. Then, add the binaries as references.
This will solve your problem, with the added benefit of transforming a tight coupling where a dependency may break your dependent solution's build, into a situation where you do not change or upgrade your dependencies until they are ready and you are ready for them.
Does this help solve your problem? This is how I do this with the projects I consult on.
HTH,
Assaf.
I'm a Fossil (and CVS configuration) novice attempting to create and manage a set of distributed Fossil repositories for a Delphi project.
I have the following directory tree on my development machine:
Projects
Some Project
Delphi Components
LookupListView
Some Client
Some Project For Client
Some Other Project For Client
Source Code
Project Resources
Project Database
I am setting up Fossil version control in order to version and share Projects\Some Client\Some Other Project For Client\Source Code, which contains Delphi 2010 source for a database project.
This project makes use of Projects\Delphi Components\LookupListView which is a Delphi component. I need this code to be included in the versioning system for my project. I will, in theory, need to include it in other Fossil repositories in the future, as well.
If I create my Fossil repository at the Source Code or Some Other Project For Client level, I cannot add any code above that level to my repository. What is the proper way to deal with this? The two solutions that occur to me are
1) Creating a separate repository for LookupListView and make sure that everyone who uses a repository for a project that references it "knows" that they must also get the current version of this project as well. This seems to defeat the purpose of being able to obtain a complete, current version of the project with a single checkout. The problem is magnified because there are other common component dependencies in this project.
2) Establishing my Fossil repository in the Projects directory, so I can check in files from various subfolders. This seems to me to involve an awful lot of extra path-typing when doing adds, and also to impose my directory structure (Some Client\Some Other Project For Client\Source) on the other users of the repository -- in this case, the actual client.
Any suggestions appreciated.
I use Git, but my approach can be applied in your situation.
I have one repository for all my components folder. This gives me an ability to get all of them with only few console commands (in case when I reinstall my OS or go to another computer etc.).
Also I have one repository per each of my projects. If some project uses 3rd party controls I create "components" sub-folder and do symbolic links (junctions) of every components set.
This approach have some disadvantages (when you "go back" in commits history of some project, components can be modified too. And if many projects are using same components this could cause some troubles). But I had no issues yet :)