All posts in Development

DevOps on Windows ToolboxWhile we’re certainly not the first technical folks to publish a list like this, we thought we’d share our DevOps on Windows Toolbox to give you some insight into the tools we use almost everyday. Basically it’s a list of software applications and utilities that we recommend for all you DevOpelers out there. These are just day-to-day tools, not systems that are part of larger solutions, but tools that help you do your job.

Full disclosure: none of these links are affiliate links nor do we have any connection with or are being compensated by any of the vendors here. We simply think these are great tools to use.

.NET Development

  • Visual Studio – This may be obvious, but Visual Studio is a great development environment, and a must have when working with any of the .NET languages (C#, etc.).
  • JetBrains ReSharper – If you’re using Visual Studio, then it’s basically a requirement that you also use the JetBrains ReSharper extension for Visual Studio. This tool gives you a huge productivity boost with Visual Studio and provides great code analysis/inspections, refactoring tools, an interactive unit test runner, and much more.
  • VisualSVN – We’ve talked about the VisualSVN Server before for hosting Subversion, but in terms of Subversion clients, VisualSVN provides great Subversion-Visual Studio integration for interacting with source control. VisualSVN makes it easy to do all of your basic SVN operations without leaving the Visual Studio window.
  • Productivity Power Tools – The 2012 version is linked here, but this Visual Studio extension gives you lots of useful tools within Visual Studio like “Open Command Prompt”, “Edit Project File”, and much more.
  • JetBrains dotPeek – The folks at JetBrains also provide a free .NET decompiler called dotPeek. This is a great, easy to use utility for browsing assemblies for which you don’t have the source code, and if you’re a ReSharper user, it uses many of the same navigation shortcuts for fast and easy browsing.



  • PowerGUI – PowerGUI gives you a handy Visual Studio-esque IDE for your PowerShell development, including a nice debugger.


  • ActivePython – As blasphemous as it may be to recommend another scripting language other than PowerShell for scripting on Windows, Python is a great scripting language to have in your toolbox. Knowing how to use a cross-platform scripting language can be invaluable in a mixed platform environment (like when you have to deal with Linux machines as well as Windows machines). ActivePython provides an easy to install Python distribution for Windows.
  • JetBrains PyCharm – If you couldn’t tell by now, we’re big fans of JetBrains’ products. PyCharm is an easy to use, but powerful Python IDE that includes a debugger, intellisense, and ReSharper-like code analysis. It’s a must have, even for the simplest of your Python scripts.

System Administration

General Utilities

  • CrystalDiskInfo – While you should definitely rely on your system administrators’ expertise and any vendor-provided disk management software when troubleshooting disk hardware issues, CrystalDiskInfo gives you a clean interface for getting diagnostic info about your disk hardware.
  • HeidiSQL – If you need to interact with MySQL databases, either as an administrator or for ad-hoc SQL queries, HeidiSQL gives you a nice “SQL Server Management Studio”-like interface for MySQL.
  • Microsoft Remote Server Administration Tools – Also known as RSAT, this provides you with several utilities used for remotely administering Windows machines. We have an entire article dedicated to it!
  • WinDirStat – WinDirStat provides a great hierarchical view of disk usage along with some neat little visualizations.

SysInternals Suite

As we’ve said before in many other articles, we’re big fans of the SysInternals suite of utilities. They’re invaluable for Windows system administration. There are many tools in the SysInternals Suite, but in particular you should have:

  • PsTools – This core suite includes many miscellaneous utilities for process management, service management, SID translation, and more.
  • Process Explorer – Process Explorer is like a Task Manager on steroids.
  • Process Monitor – This is a great tool for seeing real time operations by running processes on the file system, registry, etc.
  • TcpView – TcpView gives you a nicer interface than netstat for viewing network connections in real time.

Text Editors

Which text editor you use can be a hot button issue for many technologists. While most text editors these days have comparable feature sets, we tend to rely on these:

Miscellaneous Utilities

  • 7-zip – This is purely subjective, but 7-zip “feels” like a more efficient way of creating or working with archives (ZIP files, etc.) versus the built-in Windows Explorer ZIP file support. It supports numerous compression formats and includes a command line interface.
  • Cygwin – Again, this may sound blasphemous on a site that’s supposed to be all about Windows, but one shouldn’t ignore the value one can get from Unix-like utilities, especially for quick/one-off text munging one-liners. There are other ways to get basic Unix commands on Windows, but we like the way Cygwin packages things and provides it’s own nice little terminal.
  • Hoo WinTail – It’s not perfect, but Hoo WinTail is a handy tool for tailing log files (i.e. real time log viewing) on Windows, including support for filtering (inclusion, exclusion, regexes, etc.) and highlighting keywords and/or whole lines.
  • KeePass – KeePass is a great password management tool that we’ve written about before.
  • PicPick – PicPick is a nice screen capture tool that can be configured to intercept your “print screen” button. It comes with handy shape overlays like arrows which can be useful when you need to quickly create images for documentation or communicating with developers on issues with GUI applications.
  • TortoiseSVN – This is the de facto standard Subversion client for Windows. It works as a Windows Explorer extension, giving you a nice lightweight interface, with nice visual cues via Explorer icon overlays, and intuitive dialogs. It also optionally ships with a command line Subversion client for getting down and dirty with the command line.
  • WinMerge – Diff and merge tools can spark holy wars almost as bad as text editor choices, but WinMerge has a simple interface and supports diffing both files and directories.
  • WinSCP – When you need to perform remote file copies with Unix-like systems or systems that only offer SCP or SFTP connection options, WinSCP provides an intuitive interface for doing so.
  • WireShark – WireShark is a powerful tool for doing packet captures and packet analysis. It provides a low level view of the packets going on and off the wire and includes a flexible filter syntax along with a command line interface.

Again, our DevOps on Windows Toolbox here is just a list of utilities that help you perform your day-to-day tasks. Are there any other applications and tools that you absolutely have to have installed to do your day-to-day tasks? Let us know in the comments below!


What happens when you hit the “Start” button or hit F5 in Visual Studio? By default, the configured “StartUp Project” is launched in the debugger. If you never change anything, this will be the first executable project added to the solution. The startup project is highlighted in bold in the solution explorer:


To change the startup project, right-click the project that you’d like to set as the startup project and select “Set as StartUp Project”.

It is also possible to configure your solution to start up multiple projects simultaneously. This can be useful in situations where you have a couple projects in your solution that you want to test in tandem, such as a service and its UI. I am currently working on a visual “tail” UI for viewing log files, and in development it is useful to launch the UI and a program that generates a log file simultaneously. To set multiple startup projects, right-click the solution and select “Set StartUp Projects…” This launches the “StartUp Project” page in the solution’s property pages dialog (you can also get here by selecting “Properties” from the solution context menu). From this screen, select the “Multiple startup projects” radio button (“Single startup project” is selected by default), then use the grid to decide what action should be taken on each project, and in what order. To set a project to launch on startup, change the action to “Start” (note that “Start without debugging” is also an option, this is the equivalent of the default behavior when hitting Ctrl+F5). Use the arrow buttons on the right to change the order in which Visual Studio launches the projects.


Finally, note that this screen also allows you to launch the “current selection” by default. This can also be useful in certain circumstances when you are bouncing between work in multiple executable projects in the same solution.

Hopefully learning to efficiently utilize this rather mundane and unexciting feature of Visual Studio will help you be incrementally more productive!

Present Solutions, Not OptionsThere’s a fine line between catering to the needs of one’s users and/or clients and doing one’s job. Whether you’re building an application or building out a server, as a technologist it is your job, nay, your duty to tell your user/client what they need. Part of your job is solving a business problem or need, so don’t just present your user with options – present them with solutions.

When you’re creating a piece of software, it of course needs to be simple to operate, but it also needs to solve problems. When you create an application that is going to be used by someone else in an organization, it needs to meet the needs of the user and make their job easier, otherwise, what’s the point? This is an age old problem in software development – how to involve the stakeholders and end-users so you’re not just creating the application in a vacuum at the top of an ivory tower. You should be building your tools and their interfaces around the way that they will be used in production, not just around some model or abstract whiteboard drawing.

If you release an application and the users come to you saying “this doesn’t make sense” or “this is too complicated”, you should discuss this with your users and try to find a solution that will actually work for them instead of against them. However, this doesn’t mean just saying to them, “ok, tell me how to fix this particular problem for you”. You’re an intelligent, value-adding technologist! You yourself implement the IProvideBusinessValue interface! Your job isn’t just to churn out the codez that make the widgets do stuff for people. Your job is to come up with intelligent solutions that solve the underlying problem for the user and add value to the business. By just working from task-to-task to feature-to-feature, you can very easily create a piece of software that is more complicated than the original manual process it was intended to replace.

This same concept same holds true for system administrators.  When someone in your organization requests a new server for some purpose, you obviously need to gather some requirements first. What kind of resource utilization are they expecting? What are their connectivity requirements? What are their physical location requirements? And so on. However, you also need to come to the table with solutions, not just a list of options.

While there are always exceptions, you should be prepared with a limited set of standard server “templates” or builds. Your standard configuration for a web server in terms of CPU, memory, disk space, RAID configuration, OS version, etc. Your standard configuration for a back-end application server. Your standard configuration for… hopefully you get the idea.

You should have a small, limited set of server configurations based on typical use cases in your organization. If a user requests a server, don’t ask them what kind of CPUs they want (or even how many), or what particular service pack of Windows Server they want – tell them what they’re going to get! Come to the table with solutions, just like a third party vendor or service provider would. And if they have special requirements, then you can discuss that with them and come up with a solution that will meet their needs, but also fit within your standards.

Just like code, server configurations – both hardware and software – should be designed with change in mind. It just takes a little inventory tracking/management and a well defined, repeatable server build process to make this happen. If you’re hand crafting solutions based on each user’s request, your inventory of possible options can quickly spiral out of control and be a nightmare to manage.

Just remember – whether you’re building software or servers – you need to listen to your users needs and be accommodating, but at the same time, don’t bog them down in details. Many times users don’t know what they really want, or they have a solution in mind for a problem that doesn’t actually exist – or they’re not thinking about the larger context of their problem. Consider your users’ requirements along with the holistic system requirements to come up with winning solutions for everyone involved. Present solutions, not options.

It is fairly typical for immature software to have many dependencies on its local installation folder. After all, it is just so darn easy to read and write files using relative paths! This easy default causes configuration files, log files and data files to pile up in the application’s install directory. To make matters worse, the .NET framework encourages this behavior via the built-in app.config mechanism, which teaches developers that it is okay to store application configuration next to the executable. Unfortunately, the use of relative paths comes with many pitfalls. First and foremost, relative paths rely on the current working directory, which is very likely to be the install directory (containing your entry executable), but it is not guaranteed to be so. And it will come as no surprise to anyone that has used the “file open” dialog that the current directory can change while the application is running. But, perhaps the worst thing about reliance on relative paths from a DevOps perspective is that such behavior is probably the leading cause of dysfunctional, overly complex deployments.

When user configuration, application data, and audit logs all sit in the application installation directory, deployments become a terrifying dance of removing certain files while preserving and backing up others. This approach makes a simple xcopy deployment impossible, because the install directory cannot be removed without destroying the user’s data! To enable xcopy deployment, applications must scrupulously avoid accessing files in the current working directory or the installation directory. Instead, they should store files in one or more of the known folders that Windows provides for our use. In .NET, the known folders are accessed by calling the Environment.GetFolderPath method with a member of the Environment.SpecialFolders enumeration. There are many folders available, but there are a few you should definitely know about as they have the power to reduce your reliance on relative paths:


  • Environment Variable : %appdata%
  • Typical Path : C:\Users\username\AppData\Roaming
  • Should be used for user-specific data that should roam to multiple machines as part of the user’s roaming profile. This is a good place to store user preferences like colors and fonts.


  • Environment Variable : %localappdata%
  • Typical Path : C:\Users\username\AppData\Local
  • Should be used for user-specific data that should not roam with the user. If users run the application on multiple machines with different configurations, it is a good idea to use this folder instead of its roaming counterpart.


  • Environment Variable : %programdata%
  • Typical Path : C:\ProgramData
  • Should be used for non-user-specific application data that is common to the machine. Depending on the circumstances, this is a good spot to write log files or configuration data that is not specific to or editable by the user.


  • Environment Variable : %programfiles%
  • Typical Path : C:\Program Files
  • This directory should be used to store application installations (and should not be manipulated by apps at runtime). On a 32-bit system, this always corresponds to the “C:\Program Files” directory. On a 64-bit system, it corresponds to the “C:\Program Files” directory within a 64-bit process and the “C:\Program Files (x86)” directory within a 32-bit process. Deployment automation solutions should xcopy your applications to this directory.

When placing data in these special folders, your applications should follow the convention of using a subdirectory of the special folder named for the company, and a subdirectory of the that directory named for the application. It is useful to wrap up this convention in a helper class that ensures consistent application-specific access to the special folder:


Do yourself a favor and stop using relative paths in your applications. Write configuration files to absolute paths inside a special folder. This ensures that your application accesses the same files regardless of its install location or working directory and it will enable you to easily deploy and upgrade your applications via a simple xcopy-based process.