Microsoft changing again icons and colors in Visual Studio 2013…but not too much

It seems that this is going to be a nightmare for developers of Visual Studio extensions, but now with a yearly VS cadence (if not worse with the new VS Updates approach). This post on the Visual Studio blog explains the new changes in icons and colors for the next Visual Studio 2013 version:

Designing the Visual Studio 2013 User Experience
http://blogs.msdn.com/b/visualstudio/archive/2013/06/27/designing-the-visual-studio-2013-user-experience.aspx

As you see, the UX team keeps insisting on the direction started with Visual Studio 2012, and very reluctantly changes painfully slowly what it was quite evident for many: the new UI introduced by VS 2012 sucks. It lacked borders, it lacked colors, it lacked contrast, and the new icon designs were horrible for many people. What is worse: what was intended “to make the content to stand out”, caused the opposite effect (distraction).

In Office 2013 you get the history repeated: upper case for main menus, and three boring themes (white, light gray, dark gray) rather than two. I bet that at some point a “Blue” theme will be introduced. And afterwards, some more color and borders.

I wonder (and feel sorry) about how many hours were devoted in VS 2012 to change a user interface that was not broken in VS 2010, and now to fix it a bit in VS 2013, while other areas of Visual Studio that provided real value to many users are removed (ex: macros) or frozen (ex: automation model for add-ins, code model, etc.). Not to mention that the performance of Visual Studio is still bad.

Unfortunately, what all this means for developers of VS extensions is that we need to change icons again in our extensions if we want to mimic the Visual Studio 2013 icons.

MZ-Tools Articles Series: HOWTO: Change the build platform of a project from a Visual Studio add-in

And the final chapter of this series about to create solution configurations, project configurations and project platforms, and the lack of support to create new solution platforms, and how to change project configuration, is about changing the project platform for a given solution platform, something that had to wait 3 versions of Visual Studio (2005, 2008, 2010) until support was added in VS 2012:

HOWTO: Change the build platform of a project from a Visual Studio add-in
http://www.mztools.com/articles/2013/MZ2013014.aspx

PRB: Cannot change the build platform of a project from a Visual Studio add-in
http://www.mztools.com/articles/2013/MZ2013015.aspx

MZ-Tools Articles Series: HOWTO: Change the build configuration of a project from a Visual Studio add-in

Once we learned how to create solution configurations, project configurations and project platforms, and the lack of support to create new solution platforms, the next thing is to be able to change the project configuration for a given solution configuration. Alas, this is possible in VS 2005 and 2012 but VS 2008 and 2010 have a bug that ruins the attempt:

HOWTO: Change the build configuration of a project from a Visual Studio add-in
http://www.mztools.com/articles/2013/MZ2013012.aspx

BUG: Build configuration of a project cannot be changed from a Visual Studio add-in
http://www.mztools.com/articles/2013/MZ2013013.aspx

Book review: Continuous Integration in .NET

Manning Publications provided me a free electronic copy of their book “Continuous Integration in .NET” that I was interested in. If you have started with automated unit testing, continuous integration (CI) is the next major step to increase the quality of the software that you deliver.

This book is excellent to get you introduced in CI for .NET and to get started with a set of tools (not only from Microsoft) such as:

  • CruiseControl.NET, TeamCity and Team Foundation Server (2010) as CI servers
  • MS build as build automation tool
  • NUnit, MS Test as unit testing framework
  • PartCover as test coverage tool
  • White, Selenium and FiNesse for integration, functional, acceptance tests
  • FxCop (Code Analysis), NDepend for compiled code analysis
  • StyleCop for source code analysis
  • Sandcastle as documentation generation tool
  • MS Setup, WiX and MS Deploy as setup / deployment tools
  • Etc.

I read programming books on a Kindle app for iPad / iPhone rather that on a computer, so I appreciate that the book is easy to read, with handy screenshots that avoid you to install/use the tools on a computer to get the idea about them.

The book covers the basics of each area and tool, detailing some good and not so good things of each tool, and providing examples of use with a sample project. If you have decided that you are going to stick to free tools, you can skip some sections (and the same applies if you have decided to use only Microsoft tools).

But once you have decided which of the above area(s) of CI and tools you are going to use, likely you will need other books/docs to get deeper. For example, for unit testing I recommend The Art of Unit Testing, also from Manning, but wait until the second edition is published. If you decide to use Team Foundation Server (TFS) version 2012, I recommend the free book Testing for Continuous Delivery with Visual Studio 2012. For other tools, you will need to use the documentation of the product.

The book is also a good resource to get your team introduced to CI is that is your scenario. Many developers tend to be much more focused on the code / manual testing than on automated testing, let alone on continuous integration which maybe they ignore at all. Maybe with books like this they realize the spectrum of things that can be done automatically and in a continuous fashion.

MZ-Tools Articles Series: HOWTO: Add / delete build project platforms from a Visual Studio add-in

After learning how to add / delete build project configurations from a Visual Studio add-in, the counterpart to do the same with project platforms:

HOWTO: Add / delete build project platforms from a Visual Studio add-in
http://www.mztools.com/articles/2013/MZ2013011.aspx

This article completes the creation / deletion of solution configurations, solution platforms, project configurations and project platforms. In the next articles I will show how to change programmatically the project configuration/platform for a given solution configuration/platform, along with some issues doing it.

MZ-Tools Articles Series: PRB: Build solution platforms cannot be added / deleted from a Visual Studio add-in

The convoluted build configuration automation model (EnvDTE/EnvDTE80) and its diagram was already so tricky to add / delete solution configurations that it has to explode from some angle: the lack of direct (*) support to add / delete solution platforms:

PRB: Build solution platforms cannot be added / deleted from a Visual Studio add-in
http://www.mztools.com/articles/2013/MZ2013009.aspx

(*) There is a kind of workaround creating project platforms propagated as new solution platforms (via EnvDTE.ConfigurationManager.AddPlatform(newName, existingName, true) that I will explore in a new post / article.

MZ-Tools Articles Series: HOWTO: Add / delete build solution configurations from a Visual Studio add-in

The next article about the convoluted build configuration automation model (EnvDTE/EnvDTE80) and its diagram series of articles that I have started shows the code to add or delete solution configurations from a Visual Studio add-in. The deletion approach of the automation model has a hidden trap explained in the article and code:

HOWTO: Add / delete build solution configurations from a Visual Studio add-in
http://www.mztools.com/articles/2013/MZ2013008.aspx