.NET Tips and Tricks

Blog archive

Always Go to Production in Release Mode

I was at a client's site recently and watched them move the new version of their app to production by copying all the DLLs from the "staging" computer to the production computer. I commented on how that was the beauty of the .NET Framework: Once you had the application installed, upgrades could just consist of replacing the EXEs and DLLs. Of course, I added, you have to remember to do one last compile in Release mode before copying the DLLs.

My client said, "Pardon?" I said, "What!?!"

It turns out that, at my client's site, once a developer got their code working, my client just copied that developer's DLLs to the QA testing site. There's nothing wrong with that ... but my client was leaving money on the table as far as performance goes.

When you press F5 to start debugging, Visual Studio saves and compiles your application. However, that compile is a "fast and sloppy" one -- Visual Studio doesn't do any real optimization of your code. There are a couple of reasons for that. First, this "fast and sloppy" compile gets you into debug mode faster (which is good). Second, skipping optimization avoids rearranging, merging or even eliminating lines of your code, which some compiler optimizations can do. When you're stepping through your source code in debug mode, it's helpful if there's a one-to-one relationship between your source code and your compiled code which rearranging/merging/eliminating makes difficult.

However, when you move to production, you want all of those optimizations. I know that I've said elsewhere that the speed of business applications is controlled by their data access ... but for the cost of going up to the toolbar and changing that Solution Configuration's dropdown list setting from Debug to Release you can, potentially, get a significant improvement in your application's performance (my client estimated about a 10 percent reduction in average response time, for example).

You do have to remember to switch back to Debug mode after doing your "production compile." One of the other things that the Debug mode does is generate a .pdb file that supports debugging (among other things, it provides the relationship between your lines of source code and your compiled code). If you don't keep regenerating that file as you make changes to your source code, your debugging sessions will get decidedly weird.

Posted by Peter Vogel on 09/09/2016


comments powered by Disqus

Featured

  • Full Stack Hands-On Development with .NET

    In the fast-paced realm of modern software development, proficiency across a full stack of technologies is not just beneficial, it's essential. Microsoft has an entire stack of open source development components in its .NET platform (formerly known as .NET Core) that can be used to build an end-to-end set of applications.

  • .NET-Centric Uno Platform Debuts 'Single Project' for 9 Targets

    "We've reduced the complexity of project files and eliminated the need for explicit NuGet package references, separate project libraries, or 'shared' projects."

  • Creating Reactive Applications in .NET

    In modern applications, data is being retrieved in asynchronous, real-time streams, as traditional pull requests where the clients asks for data from the server are becoming a thing of the past.

  • AI for GitHub Collaboration? Maybe Not So Much

    No doubt GitHub Copilot has been a boon for developers, but AI might not be the best tool for collaboration, according to developers weighing in on a recent social media post from the GitHub team.

  • Visual Studio 2022 Getting VS Code 'Command Palette' Equivalent

    As any Visual Studio Code user knows, the editor's command palette is a powerful tool for getting things done quickly, without having to navigate through menus and dialogs. Now, we learn how an equivalent is coming for Microsoft's flagship Visual Studio IDE, invoked by the same familiar Ctrl+Shift+P keyboard shortcut.

Subscribe on YouTube