Creating an ecosystem with Continuous Integration, Installer and Deployments for a WPF / UWP application

I’ve been developing Windows desktop applications for many years now, and the operations behind the development process always fascinated me. I mean matters like issues tracking, build machine, installer and deployments. Everything  that involves in a developing a successful project, that’s not directly writing code.

In recent years buzz words like Continuous Integration and Devops popped up into consciousness, which partly describe this process.

I’m going to write here about the tools and technology stacks we have to choose and implement to create a successful ecosystem for your project.

The Goal

In between buzz words, it’s a bit hard to understand what is continuous integration and what exactly we are trying to achieve.

One way of defining it is that continuous integration means to have an automated work flow, in which every time a developer checks in code, it will compile and build on a dedicated server. This dedicated server will also run tests and if the build fails, or if at least one of the tests fail, the check-in will be rejected.

Now let’s go a bit further and think about Deployment. By that, I mean the way you deliver your software to the customer. Let’s assume for now, you want to give him a setup.exe, which he can run on his PC and install the program.

Our dedicated CI server should  also produce such a setup.exe file and even upload this file to some other server dedicated to published versions that the customer can download and install.

Out CI server is also there for the QA department, which needs to get product versions, test them, open bugs and get new versions with fixed bugs.

Part of this process which I described is called Continuous Integration. But, I also want to talk about the Deployment part which is a close cousin of the continuous integration and they both compose the ecosystem of the development process.

Continue reading

Visual Studio 2017 Extension development tutorial, Part 3: Add to context menu, Get selected code

In part 2 of the tutorial we created a simple VS extension with a single Menu item.

The extension will eventually be able to add code documentation in a separate file (.cs.cdocs) and view it in a nice Heads-Up display. The tutorial explains every step of the way to build such an extension.

For starters, we need the ability to select a piece of code and add documentation, which is what we’ll be doing here.

We’re going to add a new Menu item to the code editor’s context menu. When invoked, the extension will find the selected text and its Span (From where to where). Then, it’s just a matter of showing a nice Popup window for the user to edit the documentation.

Continue reading

Visual Studio 2017 Extension development tutorial, Part 2: Add Menu Item

The previous blog post introduced the wonderful world of Visual Studio extensions.

Let’s start and do some coding. During the tutorial we are going to build a VS extensions called CodyDocs and place it on GitHub.

CodyDocs will save code documentation in a separate file and the extension will allow to view and edit the documentation in the editor itself.

In the first part, we’ll start with a simple “Hello World” program. We’ll create an extensions with a Menu item that does something. I’ll make things a bit more interesting and make the menu item act as a checkbox.

Starting the project

A great way to start any feature is to add a button to disable it. So first order of business: Add a checkable menu item to Enable and Disable the feature our extension performs.

First, we’ll create a new project with File -> New Project -> VSIX project and call it CodyDocs.

Now to be able to enable and disable the feature, we need the ability to store a bool value that stores our setting.

Continue reading

Visual Studio 2017 Extension development tutorial, Part 1

Ever used Resharper, CodeMaid, WebEssentials, OzCode or CodeRush?

Those are pretty incredible tools, right?

Ever thought about developing an extensions for yourself and your team? Maybe a little something that edits the very difficult configuration files your company invented?
Or how about an extensions that automatically performs a localization merge?

There are a lot of advantages to in-house VS extensions and some big companies even have a dedicated team to work on in-house VS extensions. Extensions development is a very useful skill to have in your toolbox.

Working on OzCode, an awesome extension that helps debugging, I discovered a new world of knowledge. I’m going to write a series of blog posts introducing the wonderful world of VS extensibility.

So what can a VS extension do?

If you used Resharper or any other mentioned extension, you know the extension can do almost anything. Here are some examples:

  • Add commands to VS Menu.
  • Analyze code files with Roslyn.
  • Change code files and projects.

Continue reading

What’s the best way to learn a new technology?

In software we have to learn new technologies all the time. I mean, every day there are probably a couple of additional JavaScript frameworks born into the world.

The amount of languages, frameworks, 3rd party libraries and tools is staggering. And every place of work uses a unique permutation of those.

As developers, we have to stay on top of things, no two ways about it.

Once we’ve decided we want to learn a new technology, we have a lot of ways to approach that. Especially with the burst of information nowadays. There’s no clear answer as to how we learn something. It depends on the technology itself, how deep you need to learn it, how much time and money you have to spend on this and personal taste.

If it’s a big technology stack like WPF, some YouTube videos probably won’t cut it. However, if you need to do learn a small JavaScript library, reading the documentation alone might be enough. It all depends. If I know I’m going to do a big project with React, which I don’t know at all, I’ll take a long Pluralsight course at the very least.

Continue reading

Debugging a .Net program after crash (Post-mortem debugging)

In my previous company, we experienced a reoccurring nightmare. It went something like this:

New critical bug arrived from QA:
Program suddenly crashed. Reproduces 1 / 10 times. Reproduce steps – unclear.

The development team, after realizing they are unable to reproduce the bug on their development machine would claim the bug doesn’t reproduce, moving the ticket back to QA.
In return, the QA team reproduced the bug, moving the ticket back to dev.
Then, the development team would claim another layer of the code caused the bug, moving the ticket to a second development team maintaining that code.
The second development team, with spite, would find an obscure line of code in the log file proving the bug is actually not in their layer of code, moving the ticket to the original dev team.

This would go on until either the development team succeeded in moving the bug to backlog or, in rare cases and by sheer luck, the development team was able to solve the bug.

In our defense, all the coders who originally built the system were long gone, the application was huge and complicated.

I guess not much of an excuse but eventually we learned some tricks to help us solve those pesky crash bugs.

Well, some developers learned. Others kept claiming the bug doesn’t reproduce 🙂

Introducing our bag of tricks:

Continue reading

WPF complete guide to Themes and Skins

In WPF we define a UI resource system (mostly in XAML resource dictionaries) which includes colors, templates, icons, styles and so on. Sometimes, we need the ability to change our application’s look and feel dynamically, allowing different Themes or Skins.

We might have Shared resources for all Themes and Dynamic resources based on the current Theme or Skin.

The following article talks about the different ways to build a theming/skinning infrastructure in a WPF application.

Continue reading

Software Engineer’s path to the best annual performance review

How the annual review scores are formed in the eyes of managers always fascinated me. I have five years of experience with annual reviews myself, and I was always able to do well on them.

As a tech lead I got to give recommendations and participate in some discussions with managers. I formed a pretty firm and possibly naive point of view on them now.

Continue reading

WPF XAML Resource Benchmark

WPF is very dynamic and allows us to use resources in many different ways. We can use Static or Dynamic. We can place all our resources in App.xaml or use merged dictionaries each time.

You can see all the approaches and what I think is best practice in my WPF Merged Dictionary problems and solutions post.

If you’re new to WPF resources, I suggest reading my Explicit, Implicit and Default styles in WPF post before diving into this one.

This benchmark is supposed to show, in numbers, how any approach affects performance.
Here’s what I want answered with this benchmark:

  1. Is splitting resources in App.xaml to many Merged Dictionaries file vs. one long App.xaml file means longer application startup time?
  2. Is loading all resources in App.xaml once better than loading the resources every time with merged dictionary?
  3. Is DynamicResource instead of StaticResource an issue? How big of an issue?’

Continue reading

Why Visual Studio keeps rebuilding my projects for no good reason

Did you ever feel like Visual Studio is rebuilding projects every single time, even when there were no changes to the code?

We can build, change nothing, build again and there we go… VS is starting a build instead of saying all my projects are up to date.

Also, there’s that nagging feeling that even when we do change something, VS is building way more projects that it needs.

Like most things I do in life, frustration led me to look further into this matter.

Continue reading