I have a VS Project/Solution (.NET 6.0) that contains a ton of core functionality. WinForms, Classes, etc.
My intention is to copy/duplicate this project and customize it for each individual application (if you are curious, this is a project interacting with collaborative robots. While the core of the project will be similar across multiple robots, each individual robot will need its own tweaking (GUI, functionality, etc). I would like to keep these as individual projects and not just add new robots to the base project. I want to keep it to one project per robot. I have my reasons, from licensing to support.
My question is: what is the best practice way to copy/duplicate a project and rename it? These are the goals:
Keep the Base/Ref project intact so it can be used as a basis for new projects.
Be able to push each 'new' project to a new location/repo in GitHub.
Any thoughts are greatly appreciated!
Related
What is the preferred solution for Exrin project layout when adding a database?
The sample Tesla app had a separate project for the Services and another separate app for the Repository. With the removal of both of those projects in the latest template, it makes the most sense for it to go within the Logic project, but I'm curious if the author had a different preferred implementation.
The Tesla Sample project is designed for a very large app, and Service and Repository don't need to be separated out into a separate project, they can all be referenced directly in the logic app, as per this diagram.
This is the project setup, I now recommend for most projects.
We are thinking of making a distinct collection for code that is shared between our software products. We would then have a collection for the software projects. This would be done for organizational purposes. Would it be possible for a solution to reference c# projects that are in two different collections?
A solution can have files from anywhere, since they need to be mapped to a loal disk for Visual Studio to open them, but when spreading the code over multiple collections Source Control integration will break. Team Explorer requires all code to come from the same collection, and it favors solutions where all code is from a single team project, in those cases the other features will work best.
Other features in VSTS and TFS will be harder to use when your work is spread across multiple projects and/or collections. Test Plans, Agile tools, Team capacity and a few other items are purely scoped to the Project level. working in multiple projects at the same time will make it much harder for a team to use the tools properly. Many TFS consultants implement a "One project to rule them all" strategy because of these reasons. Putting all code and all work in one teamproject.
The XAML and 2015 build engine can only access sources from a single Project Collection at a time. So while it's possible to setup a number of local workspaces that each map to different team projects and/or project collections, this is not available when using the standard build servers that ship with TFS. Other build tools, such as Team City can be linked to multiple Source Control providers at the same time.
Now that it's possible to have multiple Git Repositories under the same Team Project, that approach makes even more sense.
Other things that will be harder may include branching structures, it will be very hard to manage the different versions of your code when they're spread across collections, since Labels and Branches can't cross collections and are hard to maintain when working in multiple projects.
A better solution for you would probably be to have your shared code in a separate team project or project collection, but not include it directly in your other projects in the form of Visual Studio Projects. Instead, have your shared projects stored as NuGet packages, either on a private NuGet feed or on a VSTS account with Package Management enabled.
That way your other projects will build faster (which can be significant when setup correctly), will use the binary versions of your shared libraries and have less unwieldy solutions.
One disadvantage of putting all code in a single team project or project collection is that it's harder to maintain the security. Project Collections for a natural boundary inside TFS, one that's harder to accidentally misconfigure or to break out from.
As #jessehouwing said solutions can have files from multiple collections. Each collection has a local workspace from where you attach project/files to your solution.
Where I disagree is that this is actually a good idea. There is no problem having 10+ collections, each for specific purpose.
For example 1 for generic projects that nobody will update unless necessary. One to store scripts. Basically think of it as library bookshelf. All similar stuff to some degree should be kept close.
Another plus is a security since one team can have access to some collections but not other. It is an obvious plus.
As to time difference, does really 1-2 sec make difference to anybody. Add one more agent and you will save time because locally building makes no difference.
As to Labels specific purpose strategy helps to overcome those problems.
i am a good but not so advanced .NET Developer. This is more of a Expert to juniors knowledge transfer request.
I was thinking, in Visual Studio you can Add projects inside a solution. Of-course these projects will carry different namespace.
My question is
Why to build a project inside a solution
When it is good\useful to build multiple project inside a solution.
I suppose you mean more than one project in a solution, right?
We use it mainly from a library perspective. You receive more than one assembly and in this way you can share or exchange only parts of you application. This is for example helpful if you have a bug in your application which touches only a part of your app. In this case you can fix and exchange only the bad assembly instead of the whole app.
It allows you to separate parts of an application. Your GUI, business logic, and data access can all be separate.
In addition, projects within a solution can reference each other with "project references". This ensures they all build with the same configuration: all Debug or all Release. Also, a projects can build when the projects they reference change.
We are using Team System 2010 and trying to adopt Scrum by using the template "Scrum for Team System". In TFS, we have many team projects that span across the single development team. To simplify, I'll explain it like this: We have 2 Team Projects that are web sites. We have 5 more Team Projects are 5 web control libraries used in those 2 web sites. As 1 Development Team, we have 1 Scrum master and 1 Product Owner over those 7 different Team Projects.
Anyone else in this configuration?
How do I bring all this work together? We need to manage releases over all those projects. Our Sprint planning meeting will deal with all those projects, so at the end of meeting, we'll have post-it notes (Product Backlog Items) that could deal with just a web site project or a control library that needs to be implemented in either of the sites.
Do I need to create another Team Project just to create work item artifacts and generate my reports (Burndown chart, etc)?
You can't have hierarchy between Team Project, this feature doesn't exist and there's a reason for that.
You made a mistake that everybody make the first time using TFS: too many Team Projects.
Lot of people do unconsciously one Team Project per Visual Studio Solution.
If you have a development team that works on a family of applications/products that share the same release cycle (or close one) then use just one Team Project.
The only advantage you have using many Team Project is a different process template can be used for each and you can upgrade your Work Item Type (WIT) definitions independently (this advantage by the way most of the time a living hell because you have to keep in sync the WIT across all Team Projects).
Otherwise you only have inconvenient (more WIT definition, more WIQ, more branches, more reports, more administration).
To implement a notion of hierarchy (whatever the hierarchy you want), you have to rely on the Area Path of the Work Items. Then your queries and reports will be able to be scoped at will.
By the way, any reason for you to not use the Microsoft's Scrum Process Template ?
I am wondering what is the best way to use workspaces in visual studio. We have 150+ webservices that are all part of the same team project $/MyTeamProject without being related at all. The reason for them all being part of the same team project as they are all maintained by the same group of people within our organization.
Each webservice has the following structure
$/MyTeamProject/WebService1
$/MyTeamProject/WebService1/Main
$/MyTeamProject/WebService1/Release/1.0
$/MyTeamProject/WebService1/Release/1.1
$/MyTeamProject/WebService2
$/MyTeamProject/WebService2/Main
... etc.
I am wondering what is the proper way to use workspaces with this setup as currently there is only mapping for the teamproject so all my webservices are part of the same workspace. Should I create mapping for the main branch and for each release branch as a separate workspace or should I map each webservice to its own workspace such as $/MyTeamProject/WebService1?
Any help would be appreciated.
I can't put each of the webservices as its own teamproject as the tfs is being shared between several groups with the same magnitude of projects and therefore we are limited by our own teamproject for all of the webservices.
You said that the webservices was not related at all. I then assume that they are released separately.
I can't see any reason to use multiple workspaces in your scenario.
I suggest that you remove the mapping from the top level project "MyTeamProject". Then you have flexibility to map the subfolders to whatever local folder you want.
If you have one workspace per webservice then you will get 150*#releases workspaces. This will get really hard to manage for build versions, labelling etc. Fewer workspaces will mean less builds to manage.
I would recommend having a workspace per release. Generally you would probably only be working on one release at a time and this will allow you to manage all code for a single release effectively. Also you can then map your workspaces on the client into a more logical structure as you allude to in the question.
For example
\Projects\MyTeamProject\Main\WebService1
\Projects\MyTeamProject\Main\WebService2 ...
\Projects\MyTeamProject\Release1.0\WebService1
\Projects\MyTeamProject\Release1.0\WebService2 ...
\Projects\MyTeamProject\Release1.1\WebService1
\Projects\MyTeamProject\Release1.1\WebService2 ...
etc