One of the first things you figure out when working with Git is that like other source control providers, you want an easy way to exclude files from ending up on your source control to save yourself uploading items such as binaries and local user files (here’s looking at you Resharper!). By adding a .gitignore file to your repository you easily make this possible (if you’re using Windows, feel free to take a look at my post on creating these files successfully in Windows). The problem you have next is when you add a gitignore rule that’s a little too aggressive and your new project files fail to be picked up by Git, but you’re not quite sure which rule is the cause – this post shows you how you can troubleshoot these issues.

Nuget has become such a valuable part of the .Net ecosystem it's any wonder how we got the job done with 3rd party packages without it. When working on projects in a team many developers turn on Nuget Package Restore to save them having to check their packages into Source Control. This allows them to have their packages download whenever a new developer goes to build. It’s also quite popular with project teams that have Continuous Integration setup. I recommend against Nuget Package Restore, as I’m simply not a fan.

When you go to create a mobile app for each major platform you quickly realise that it’s a mind boggling task with many languages and tools out there to learn along the way. A number of products have arrived over the last few years that enable you the freedom of only having to care about one language and toolset, with the dream being that they take care of the rest. Does this type of approach work? DXTREME does a pretty good job of making the answer to this question Yes.

Geeky salesman have spent decades selling us a pipedream of the end of “Tree based communication”. To date not much has changed and I’m not holding my breath. In the mean time, what do we do with all this paper? If like me you are dabbling with ways to get your code to convert the physical to the digital, I’ve got news for you: Smarter people have already solved the problem for you and it’s simply a matter of plug and play.

When it comes to reviewing visitor site usage, server bandwidth usage, or forensic security investigations; IIS log files often hold the answers. Although as I'm sure you’re more than aware, gigantic text files can be hard to view let alone pull intelligence from. Investigating a website attack can be really daunting when looking at log files as an information source. In my previous post I covered a tool to help with Windows Security Logs. Lucky for us it’s just as awesome when dealing with huge IIS logs.

When bad things happen to either your website or your server you’re usually faced with a situation that either makes or breaks you. Much like having a good backup and restore plan, being able to filter and scan log files for what you need to help draw conclusions on how a situation occurred or by whom it was conducted, is an important part of your security plan. However if you have a heavily traffic’d website, network share or part of your file system and you’re doing a lot of logging, you probably have files the size of the moon to wade through, so making sense of them can be a nightmare.

Microsoft developers hear a lot about tools that will make them write faster, more efficient, more refactored, more unit tested code all the time. People don’t often talk of tools that help you to visualise your project’s growing code smell though – among other reasons, everyone’s inner sense of pride may be a behind this, however unless you or your employer has forked out the $11,879 odd dollars for Visual Studio Ultimate Edition you don’t have much to go on without more than the basic reporting on Cylcomatic Complexity, Dependency Depth and Class coupling reports that come in the pro and premium editions. These don’t really help you pin point any of your architectural problems that well – something  where NDepend proves itself to be a diamond in the rough.