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.
Related
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/,. ..
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.
Currently working with a client that has a Web Api Project/Framework that they use for multiple clients. 98% of the code is reused, but they copy and paste the repository for each new client. After the copy and paste the only things that really change are Web.Configs and every now and then a couple extensions to the OOTB api. E.g. maybe they standup a custom module to the api api/rockets/ or they extend an existing api and add some new methods & actions.
I can't find any way to pull this off with .net. Currently I'm thinking I could solve this via git with forks, but I was wondering if there was any way to solve this with .net. Is there a way to extend an existing web project?
The git approach is one way of doing it, but I'd probably go for Nuget packages.
Extract everything that will be common to all solutions, even resources and make a package.
Take advantage of package versioning and so on. If you got a bug, fix that in the package and simply run a nuget-update in the project, or even just setup your continuous integration to rebuild and update at any dependencies change.
One option, would be to have a single web project for multiple clients that uses "Areas". That way you could turn on/off each are individually.
You could also put your common business logic into a Nuget package and import it for each customer. But it would be a really bad idea to fork the business logic every time. What would happen if you found a defect? You'd be forced to fix the same problem in N projects.
The approach from this one was really simple. We extracted everything into a common C# Library, converted all of the shared stuff to git submodules. We then used Autofac Multitenant to register some client specific overrides. It was actually really easy.
I am looking at moving our .net(c#) projects from TFS to git. The general consensus in the tema that we do not want to continue with tfs has been reached and we wish to trial git. We currentley do not have that many projects to migrate over but we expect these to grow as our old systems are replaced.
Currently we have a tfs project for all things that we think will be needed by multiple projects, database stuff, 3rd party dll's etc. What is the best way to have a similar structure in git?
The best way I could see is to have a similar thing to our current structure, with a seperate repository for all the common files.
I have read about using submodules but there seems to be a lot of complaints about these. Is it worth trying something like repo or another alternative? Or is there a better way to handle this?
This question is going to be pretty subjective, but IMO I would solve this by having a separate repository for your common stuff.
Another option is to migrate your common stuff to Nuget packages so you can move your common stuff forward without worrying about breaking all your existing projects.
In my experience common projects in an Enterprise environment tend to calcify your ability to respond to change quickly. Instead you spend lot's of time worrying about how changes in your "Core" or "Lib" modules will affect the 80+ projects you have that are using them. Worse, people just start shoving everything into those modules even if it is only pertinent to a few projects simply because it's easy.
I'm looking for multiple inputs on great project organization/structure, preferably especially for complex ASP.NET MVC projects (which will definitely go beyond the couple of folders initially created by the project type).
Project organization also includes topics like naming conventions, lumper/splitter preference on classes, number of actual projects vs. folder structure, one way vs. two way dependencies and so forth. My ultimate goal is to merge these ideas into something I personally consider good for my current complex ASP.NET MVC application and to learn from how others have structured their projects successfully. So if you have good links, pointers to relevant forum/blog entries/articles or personal preferences (maybe on a specific part? E.g. maybe you have a set number of projects which you always use as a base framework?), please let me learn from it!
Thank you!
Start with Billy McCafferty's S#arp Architecture project and go forward from there.
http://code.google.com/p/sharp-architecture/