Surviving the Enterprise Application

Many of us have worked on this sort of application: “The Monster”, “The Big One”, “The Behemoth”, or simply “The Enterprise Application”. You know the kind I mean: it’s a mess of dozens of projects and solutions. It requires setting up three console applications and two databases just so you can debug something (god forbid you could just launch it from within Visual Studio), and after making changes to some code, getting the updates DLLs to the right place can be a headache. The sheer amount of time wasted on getting around the architecture can be daunting, and changing this behavior, especially when the app has years of crud and not enough tests, is not something you want to take on yourself.

This is where tools come in. Good tools make the difference when navigating such a codebase between “horrendous chore” and merely “momentous undertaking”. Some are commercial tools and add-ins, like Resharper, which are indispensable for making heads or tails of a giant project. But there are many tools that are built into Visual Studio or even Windows that can make our lives easier. Here are a few of them:

Macros Are Your Friends

I’m saddened, heartbroken, devastated that Microsoft has removed support for Macros in Visual Studio 2012. They’re a feature I’ve used for many years for automating common tasks, especially the ones that accompany a huge project. In many projects, one needs to launch the application manually, then attach via the Attach to Process command. That, in itself, is not an overly complex process. But repeat that fifty times a day, and you’re starting to lose serious minutes. And if you’ve got specific parameters involved – such as attaching to one process with .NET Debugging only, and to another with Managed Debugging as well, and you have endless frustration. That’s where macros come in. You can add a short macro (recorded automatically, then customized) to attach to a specific process, add that macro to your toolbar or map it to a keyboard shortcut, and watch productivity soar (well, jump a bit, maybe). Here’s an example of such a macro. Do not fear the Visual Basic. The Visual Basic is your friend.

That’s all there is to it, barring some error handling code if the process isn’t found – in which case you can even add code to launch it automatically. Assuming, of course, it’s a simple case of launching an EXE. If it isn’t, we have some more tricks up our sleeve:

Back To Basics With Batch Files

Yes, yes. It ain’t pretty, and It’s not as powerful as bash or PowerShell scripts. But many times you need a simple script without the learning curve, .BAT files can give you what you’re after. In my current project, launching the basic application environment involves launching a server app in a console window, waiting for it to load, then launching a second service, giving that one enough time, and only then launching the client. This can be easily implemented with a lesser-known utility called TIMEOUT.EXE, originally a part of the Windows Resource Kit, but starting with Vista, a standard part of every Windows installation. This lets us space our startup logic appropriately:

(Yes, that’s fifteen seconds to wait every time. That’s one heck of an Enterprise Application).

But spacing out application launches isn’t always enough. Sometimes we need a batch file to kill all processes at once, so we can update data and restart them. Here we have, again, a built-in Windows utility named TASKKILL.EXE that can receive either a process ID or, better for us, an executable name and kills the process dead. However, in this case, I would recommend skipping the built-in tool and using PsKill, part of SysInternals indispensable PsTools package, which has a host of useful tools.

SendTo? Really?

I remember, when Windows 95 rolled into town, I was enchanted with the possibilities that Windows Explorer offered. One of these was the Send To menu, and specifically, how easy it was to add a new option to that menu. Now I could send any file to any app, easily! Of course, after 10 minutes of wonder, I discovered that I never use it for anything except attaching a file to an Outlook message, and (rarely) creating a desktop shortcut. But now, with the Enterprise Application, it came back to me!

In my current project, we have several solutions, each compiling outputs to a different build folder. Of course, if you’re building the Shared Enterprise Apps solution, you have to remember to copy the new files to the Enterprise Application Client folder, or you’ll be constantly surprised and frustrated by your old code running again. Of course, this entails keeping lots of Explorer windows open, closing them, reopening them, copying the new files, and so on, and so forth. This is where my teenage fascination with Send To came back to me – I can actually use it! For real!

In Windows 7, the Send To menu resides in the application data folder, under %AppData%\Microsoft\Windows\SendTo. All we have to do is add a shortcut to our Enterprise Client folder, and be able to quickly send any file to it from anywhere:

Seconds Count

All these tips I’ve collected here may seem a bit trivial. The problems they come to solve only cost us a handful of seconds each. But when we sit in front of our projects for hours every day, repeating endless cycles of code-test-fix, these seconds add up. They add up in productivity, and they add up in frustration. A smooth development and operations process keeps us focused on what counts – fixing the real bugs, solving the real problems, and going home. If you have your own productivity tips, I’d love to hear them.