Book Image

Visual Studio 2010 Best Practices

By : Peter Ritchie
Book Image

Visual Studio 2010 Best Practices

By: Peter Ritchie

Overview of this book

When you are developing on the Microsoft platform, Visual Studio 2010 offers you a range of powerful tools and makes the whole process easier and faster. After learning it, if you are think that you can sit back and relax, you cannot be further away from truth. To beat the crowd, you need to be better than others, learn tips and tricks that other don't know yet. This book is a compilation of the best practices of programming with Visual Studio. Visual Studio 2010 best practices will take you through the practices that you need to master programming with .NET Framework. The book goes on to detail several practices involving many aspects of software development with Visual Studio. These practices include debugging and exception handling and design. It details building and maintaining a recommended practices library and the criteria by which to document recommended practices The book begins with practices on source code control (SCC). It includes different types of SCC and discusses how to choose them based on different scenarios. Advanced syntax in C# is then covered with practices covering generics, iterator methods, lambdas, and closures. The next set of practices focus on deployment as well as creating MSI deployments with Windows Installer XML (WiX)óincluding Windows applications and services. The book then takes you through practices for developing with WCF and Web Service. The software development lifecycle is completed with practices on testing like project structure, naming, and the different types of automated tests. Topics like test coverage, continuous testing and deployment, and mocking are included. Although this book uses Visual Studio as example, you can use these practices with any IDE.
Table of Contents (16 chapters)
Visual Studio 2010 Best Practices
Credits
About the Author
About the Reviewers
www.PacktPub.com
Preface

Summary


I hope the information in this chapter has motivated you to help become part of the solution of thinking more about "recommended practices" or "contextual practices." I've tried to ensure that each practice is complete, correct, and up-to-date when it was written. But over time, each of these practices will become more and more out-of-date. I leave it as an exercise to the reader to improve each practice as time goes on.

So don't take this as a recipe book. You should try to understand each of the recommended practices, recognize the context for which it is intended, and try your hardest to either improve it or to tailor it to your project or your context. You're doing yourself a disservice if you simply take these practices and employ pragmatic re-use.

I hope this chapter has either re-enforced your thoughts on the term "best practices", or opened your eyes slightly. "Best practices" are far from a panacea, and far from "best" in every context. We've seen several motivating factors about why we might want to "use recommended practices" and why we're sometimes forced to resort to "recommended practices" rather than figure it out. I hope the information in this chapter has motivated you to help become part of the solution of thinking more about "recommended practices" or "contextual practices." Finding and using recommended practices is just the first part of the puzzle. In order to use a practice properly, we need to evaluate the practice: we need to know the context for which it's intended as well as the context in which we'd like to use it. This can be a complex endeavor, but several criteria can help us evaluate applicability of a practice. Once we know our own context, the context in which we would like to apply a particular pattern, it is only then we can truly evaluate a practice and use it properly. After all, we don't want to use a practice to save time and avoid technical debt if, in fact, it increases our technical debt and reduces quality.

In the next chapter we'll begin looking at source control practices. We'll look at some terminology, source code control architectures, and source code control usage practices.