Firstly, I'm new to VSTS and Git, so apologies if my terminology gets muddled!
PROBLEM
My situation is that I have a VS/C# Project (called "PluginBase") that is, essentially, "starting template" code for a plugin. Historically, I've would just copy that PluginBase project code every time I wanted to create a new "tailored/derived" build for a particular customer.
What I would like to be able to do is, as and when bug fixes are resolved and features are added to the PluginBase project, I'd like the option to migrate these changes to one or more of the "tailored/derived" builds. Likewise, if the bug was first found while developing a "tailored/derived" build, I'd like to migrate that back to the PluginBase plugin.
IDEAS
From my research, I've come across a few "possible" ways of achieving my goal, but I'm not sure which (if any) of these approaches are suitable.
Branches
Seems the common approach, perhaps the "best", but...
Means all code must be in the same repository? (otherwise can't "cherry pick" across) - which I'd prefer to avoid as this may not always be possible
Git Submodules
Seems more intended when projects are sharing a common "library" (not deriving from same code-base)
Also not sure Visual Studio fully supports this feature
Cherry Pick
Doesn't seem possible to do this from one repository to another?
Git Patch
Doesn't seem Visual Studio supports this feature yet?
So, if anyone has any advice, guidance or new suggestions for approaches I could (or should) be using, I'd really appreciate your input.
Many thanks! :)
Git Branches are definitely the way to go. The code indeed has to be in the same repository, git stores change sets and in order for a change set to be applied git has to know what happened since the code-paths split or it can not replace the correct lines of code.
Make a branch for each time you roll out a version to a customer, you can then cherry-pick across the different branches.
Related
First of all, thanks very much for having me in this community! :D
Secondly, let's go straight to the issue!
Today, I'm the unique responsible for a bunch of projects, and after some time, we decided to delegate these projects to other employees, because many times the code modification isn't needed to be made by me, the technician can do it easily. For today, each code modification is delegated to me, so in that way, its easy to control the Projects.
Then if we start working with more people, it will be more difficult to control these projects. Then I wondered (haha) that why don't use Git as our project controller?
I started deveolping an application that uses LibGit2Sharp (which is great!) for controlling the projects, but then I realized that I'll have to create tons of projects for controlling each one. And each projects is more like a configuration file, not development. It would be great if all these projects could be controlled in the same project (as a submodule, for example). I started looking for what submodules gives me and I don't think is the same as I need.
The project structure would be like this:
/Master Project
/.git
/MySoftwareV1
/Customer1
/.git
ConfigFile1.cfg
ConfigFile2.cfg
ConfigFile3.cfg
/Customer2
...
/Customer3
...
/Customer4
...
/MySoftwareV2
/Customer5
/.git
ConfigFile1.cfg
ConfigFile2.cfg
ConfigFile3.cfg
/Customer6
...
/Customer7
...
/Customer8
...
Is it possible to implement?
In this case, my application will control the submodules for the users check-out/in.
If you guys need more information, please don't hesitate to tell me!
Thanks in advance!
Best Regards
I would keep it simple, use a single Git repository without fancy stuff like submodules and instead mirror the project structure as a file folder hierarchy.
If you want to have more control on what the technicians do, you could let each one of them work on their own branch, so they can't damage someone else's work. It would be your (or your LibGit2Sharp-based application's) task to review their changes and to merge them to the master branch.
Since Git keeps track of the whole change history, you can always undo unwanted changes.
We have two projects written with c# on Visiual Studio, let's name them A and B. Both of these can be used as seperate products. Bu B can be integrated to A or to other products as a module. We were using SVN but now we are switching to Git with VSTS(azure devops).
We mostly develop B project while we develop A project, in the same solution.
Is there any way to set these repos seperately and commit changes of both projects in same branch with out switching solutions?
What is the right strategy we should use to manage this situation?
We solve this using git submodules. A submodule is a separate git repository inside another git repository. You commit separately in both repositorys, and the parent repository "remembers" which commit of the submodule repository it currently points to.
You can find plenty of documentation about submodules, e.g. in the pro git book. There are some pitfalls, but if you once get the workflow, it's a good approach for your problem.
Git Subtrees might be an alternative.
As an alternative to the submodules approach, you might want to consider a monorepo approach; in other words, keeping both projects in the same git repository.
There is nothing in Git (or Visual Studio, for that matter) that requires you to use the repository's root folder as your working directory when working with the code in the repo, so your current developer workflow within each individual project could probably work just fine. You also get the benefit that working on B and A in the same solution will feel very natural.
Depending on your team structure, etc, there are of course drawbacks as well (for example, without good discipline it can be cumbersome to be very many people working in the same repository), so don't see this as a "silver bullet" - see it as one of many possible solutions to your problem; evaluate them and pick one based on what seems like it would work for you (and switch again if it didn't work out).
My team has a fairly large set of desktop applications with many shared libraries between them all in one common solution file in our repository. We'd like to use semantic versioning for a number of reasons, chief of which is to make it easier for our users to install updates. However, given the number of assemblies we're dealing with, we're finding it pretty tedious updating AssemblyInfo files for each one, especially if it's for a library that's a dependency for multiple applications.
I was wondering if there's an easy way to use git tags or some kind of external tool to tell the build server that, for example, XYZ has a bug fix and its patch number needs to be updated.
Use GitVersion : https://gitversion.readthedocs.io/en/latest/
It will do automatically the semantic versionning based on the last tag and git history.
You could use GitVersionTask if you use msbuild or (better) use it with build tools like fake or cake.net
Edit: you now have also alternatives easier to use : https://www.nuget.org/packages/Nerdbank.GitVersioning/, https://www.nuget.org/packages/GitInfo/,. ..
We are working on an enterprise level .net project, where-in we have a huge code base. We have our own different small frameworks implemented in the project.
While working, many a times it happens that I want to see a particular module's (or it's framework's) class hierarchy at a glance, which seems difficult. I have to drill down in different class files to see the relationships. Which is little difficult to do and takes time.
One way is that, I can create a dummy class.diagram file and drag drop particular class files to check the relationships. But it doesn't work that well.
Is there some other practice being used which I am not aware of ?
One thing I know of is Visual Studio 2013 Ultimate edition has Architecture tab (I know 2010 and 2012 also have it, but never used in them), that can be used to generate dependency graph of all projects in a particular solution. That can be used to generate dependencies within the projects.
I have seen it shows dependencies to the class levels.
You can take help of this Channel9 link to know more about it.
I've used .NET Reflector (with various plugins) in the same context.
There's a huge amount of plugins available at https://reflectoraddins.codeplex.com/ that ease the task even further.
On the "free" side, you'll probably want to give the following combo a try:
ILSpy (http://ilspy.net/) + AssemblyVisualizer (http://denismarkelov.github.io/AssemblyVisualizer/)
Note: all of the above is used to view the assembly's hierachy, not from a source point of view.
Good day experts!
I am about to start a new project and I would like to have a build script for my code. It will be a .NET project developed with VS2010.
Unfortunatelly, I have no idea how to start. What should the build script do? What are the best practices? How should I configure the projects/solutions?
Is there a how to guide for this? I was thinking about using msbuild.
Thanks
Depending on how big your product will be I would suggest using a Version Control System like TFS and when having that in place you could/should also use a build engine like TeamBuild. May look like overkill but my bet is that it is even easier than trying to figure out how MSBuild works...
Some good practices:
Aim for a "one click build" approach. Try to put all your projects for an app under a single solution. That way, you can build the whole stuff with a single command. Plus, with projects like SharePoint ones, you can create all packages during build (this requires customizing the .csproj files, but it's worthy), I have to try it but this may work
<PostBuildEventDependsOn>
$(PostBuildEventDependsOn);
CreatePackage;
</PostBuildEventDependsOn>
This also helps you in searching across "Entire Solution", so all devs can be in sync without ambiguities.
Make sure to have some good naming convention. For ex. a solution like MyApp containing projects like MyApp.Model, MyApp.View and MyApp.Presenter if you are following an MVP pattern, etc.
Which brings us to another point: aim for a layered organization of your code. A project for utilities, another for your business model, another for presenters, yet another for your UI, etc. That facilitates testing, reusability, etc.
Either case, just try with different approaches and evaluate by yourself pros and cons.