Comments

Post a Comment

Popular posts from this blog

This is a small tip that I'm mainly publishing as a reminder to myself, but it could come in handy for someone else.

Background processing tasks in ASP.NET are hard. At any time IIS could decide to recycle the application lifecycle. The usual solution is to farm out these tasks to a (Azure) queue and let some other machine (for example an Azure worker role) process that queue.

However, with ASP.NET 4.5.2 Microsoft introduced the QueueBackgroundWorkItem method. This makes it possible to create small background processing tasks within the application lifecycle context.

See the following (extremely simple) example:

Caveats:A task started this way will only delay the recycling of the app pool for 30 seconds. So you need to complete your work within those 30 seconds. If not, the task will be killed.You need ASP.NET 4.5.2.
See for more detail the following links:

When working with Git my normal workflow was to create my feature/bugfix in a branch. When I'm ready to integrate it, I rebase the branch and merge it into master. This ensures that the master branch has a linear history.

This gives you a clean history which is easy to bisect.
However, when reading the help for git merge I came across the --no-ff parameter. It says:Create a merge commit even when the merge resolves as a fast-forward.
I decided to use it for my 0.2 version of my software. This created the following graph in gitk:
This code was first rebased, then merged with git merge --no-ff. An explicit merge commit is now created (where the tag 0.2 points to). Because the branch was already rebased, this merge commit does not contain a diff - it only exists to merge the two branches together.

This gives you several advantages on top of the advantages you have using git rebase:You can see the name of the branch you merged back into master.The name is part of the commit message of…

Since quite some time now it is possible to create a new project in Team Foundation Service (the cloud variant, not to be confused with Team Foundation Server) using Git for your version control. Since I'm an avid Git user I decided to see how the newly released Git tooling would work within Visual Studio and how easy it would be to migrate a project I've hosted on Github to Team Foundation Service.

I cloned my repository that I'm currently hosting on Github. This project already contains a MSBuild file for building the entire project. It also contains some unittests, written using NUnit. First of all you create a new project in your Team Foundation Service. This is simply an empty project, you only indicate that you want to use Git.