We’ve all been guilty of it in our development careers at one time or another. When starting out using a language or framework that you’ve never used before you often have no choice but to. What I’m talking about is the act of “copy paste coding”, and it’s as common in the programming world as chewing gum under seats. When you copy and paste other developer’s code into your application it’s important to fully understand what the code does before you continue; or risk joining the many fools that have gone before you.

When writing testable code your first port of call is often to abstract any dependencies and make them easy to mock. This is the same for any of your codebase that talks to FTP servers. Testing the way your code behaves under real world conditions makes integration tests important regardless of abstraction though. Here’s a simple trick to test FTP code in the wild.

When you include .Net 2.0 mixed mode assemblies in .Net 4.0 or .Net 4.5 projects you often have to add some start up options to your project’s config file to get it all to play nice when your app starts up. This backwards compatibility feature is great as it allow you to use older/non supported projects in your recent work.When when using Visual Studio 2012’s new unit testing tools this magical piece of app.config code doesn’t seem to help though, and the solution is pretty simple.

These days we’re lucky. SSL is becoming pretty pervasive. Facebook uses it. Twitter uses it. Most modern start ups now use it. Sadly there are still other sites or services that you may be accessing on the internet that are still insecure allowing others to listen in on your internet usage, and for these your want an encrypted VPN link to route your traffic through. VPN’s can be expensive though if all you have is a home PC and a laptop on the road – lucky for us this can be a magic combination that is all you need and saves the day.

Today marks the official start to Microsoft’s TechEd Australia Conference on the sunny Queensland Gold Coast. With over 4 days of talks, product launch education, hands-on labs along with device and software manufacturers spruiking their wares, it is sure to be a great week – if you are around shoot me a tweet so that we can try and cross paths during the week.

In the IT industry employees experience a weird phenomenon once they begin to move up the ranks. You often start work in IT because you get to build stuff, monitor things, and watch your creations grow. The weirdest thing about this is that in our industry to step up in your career you often have to actually stop producing things. To move into management put down the tools, and loosen your grip on what you love.

I’ve been a long time supporter of Visual Studio Web Deployment projects. Not because I built ASP.Net websites and wanted to compile them, but more because they held so much unadulterated power from the simplicity of just being an MSBUILD file inside your solution. With the launch of Visual Studio 2012 Microsoft has made the call to no longer support WDP moving forward. This made me sad; but I was just being naive. Visual Studio 2012’s Publishing profiles are even more powerful, and they bring all your old friends along for the ride.

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.

In ASP.net land we are often lead to think the “Microsoft way” when it comes to a lot of things. Running performance tests and benchmarking is one of these tasks where we are often found looking into commercial tooling or products to help us find out how our applications handle load. Meanwhile a lot of web developers on other stacks are doing it with great free tooling. There is nothing stopping us from stealing the best parts from these stacks and bringing them back to the land of ASP.Net.