Solving performance issues with dotTrace

If you’ve ever had any performance issues with your .NET applications, you may find this writing interesting. In this post I’d like to present to you a tool produced by JetBrains – dotTrace, showing how using only one of its functionalities can help in finding causes of performance issues in .NET applications.

Performance issue on production

Months ago some of your colleagues implemented an application and delivered it to the Customer. The app is “Countries and Cities Manager”, which is used by some administrator working in local government unit. That’s how it looks:
Countries and Cities Manager
That’s cool, isn’t it ? This “administration panel” allows to add a new city to the country. User fills name of the city and provides ISO code of the country considered. You may think “who would ever use it and for what?”. True. But first of all, this is just an example 🙂 , and secondly, imagine that Russia annexes some big European country. What happens then ? User administrating local government system must use your manager application to insert hundreds or thousands of new cities in Russia. Gotcha! The next day you receive a ticket in your company’s issues tracking system. Taking into consideration that an average number of cities in east-European countries is ~600, the ticket’s priority is set to “Blocking”. The description of the issue is:
  1. User fills the “City” and “Country ISO Code”, clicks “Add city”
  2. Waits for 10 seconds…
  3. Waits for 20 seconds…
  4. Waits for 30 seconds…
  5. Error message received:
    ISO not found
  6. User corrects “RU” to “RUS”
  7. Waits for 10 seconds…
  8. Waits for 20 seconds…
  9. Waits for 30 seconds…
  10.  City added!
  11. Scenario repeats for each new city to be added. Performance is unacceptable.
Initially you have no idea what could be the reason. Such simple operation and such terrible performance? Let’s see…

Looking for issue with dotTrace profiling

In such cases, especially if I don’t know the code of the application considered, the very first thing I do it to use dotTrace in order to profile the application when executing bad-performance actions. It provides many features, including: detecting performance bottlenecks in .NET applications getting information about calls execution times analyzing calls order on a timeline profilling SQL queries and HTTP requests profiling unit tests … and

many more read more...

Hello Xamarin World – first steps

This time I want to say “Hello” to Xamarin world.

First thing that needs to be done before starting Xamarin development, is obviously the installation of all necessary components.

In this post I want to share my feelings about the installation (not without issues of course), configuration of my Xamarin Android solution and deployment process to the device.

Xamarin installation into Visual Studio 2015

I’ve created my account at xamarin.com, logged in and chose Download Xamarin for free to download the installation package. There are generally two IDEs that can be used for Xamarin development: Visual Studio or Xamarin Studio. I’ve already had VS 2015 installed and decided I don’t want to explore a new IDE, so I downloaded installer for Visual Studio. What’s more, following Xamarin’s website, “Xamarin Studio is no longer included” in the Windows installer and they “encourage Windows developers to move to Visual Studio”. Well, that’s understandable, Microsoft acquired Xamarin, didn’t they? 😉

BTW, when downloading Xamarin I was obliged to fill the “Company” field – does anyone know why is that?

 Android SDK and emulator images size

Interesting parts of the installation (if there could by any at all?) are Android Emulator installation which is then integrated into Visual Studio as well as Android SDK installation – fortunately it’s possible to change the location of Android SDK installation, because right after the setup it takes an enormous amount of disk space (with mandatory tools mentioned in the installation guide and two Android APIs):

Android SDK size - 41.6 GBs
Android SDK size

I’ve examined a bit more and it turns out that system images take the most of this space. Those are used only by emulators to be able to create a virtual device and debug on a simulator instead of deploying the app to a physical device every rime.

When I used to write some Android apps in Java and Android Studio long time ago, I found it very hard and complex to debug/test anything using emulator – it was simply very, very slow to load and work. This time I’ll see if emulator built in Visual Studio will do the job – if yes, why not using it ? I will of course also deploy directly to the device for tests, but it also takes time. I remember that when I wanted to test some small adjustments done “on the fly” (e.g. UI modifications/alignments) I dreamt about doing it quicker then deploying app to the phone every time. We’ll see, if emulator won’t do the job – I will clean up those folders.

 First issue in DSP

I had to create a separate paragraph for that 🙂 Of course, it must have finally happened – first issue on my DSP way! Installation error, of course – “Installation of ‘Xamarin’ failed with more then one exception (attempt 3). It was not possible to complete an automatic installation.”

I expected the installation to terminate and evening spent on looking for a solution, exploring StackOverflow threads, but to my surprise a quite familiar-looking screen appeared explaining what to do next, i.e. how to install all the components manually. I had to download and install Java JDK, Android SDK and Xamarin.

Android Solution Creation

VS Android Xamarin Solution
VS Android Xamarin Solution
  • Properties – here AssemblyInfo.cs is probably well-known to all .NET developers (for the others: this file is .NET assembly’s metadata file, containing basic data about our application, like its name, version, company etc.), but there is also AndroidManifest.xml, which contains details and requirements for Android application, e.g. app’s name, supported SDKs versions numbers and required permissions for which the end user is asked when installing the app
  • References – contains other assemblies required for the application to build; in case of Xamarin Android solution, it references both .NET assemblies like System or System.Core and Mono.Android assembly
  • Components – stores Xamarin development packages that can be retrieved from Components Store (something like Xamarin-specific Nuget, I guess 😉 )
  • Assets – allows to store additional files needed by the app (e.g. text files) available easily from the code
  • Resourcescontains strings, images and layouts of the application
MainActivity

[Activity(Label = "MoneyBack", MainLauncher = true, Icon = "@drawable/icon")] read more...

Building Windows Services using Topshelf

Hello again 🙂 Visibly this is going to be my first technical post here. I hope you’ll find it useful.

Windows Services

Recently I came up with a need to create an application, which executes some tasks in the background based on file system’s events. “That’s easy”, one would say. “Build Windows Service app”, he would add. Sure, that was also my first idea.

I think that’s very common that we want to create an application without any GUI, which purpose is just to do something in the background. Moreover we’d like it to be independent from the user running it – we want it to be running all the time, without having to manually launch it – especially when the application is running on customer’s environment, where we can’t be logged in all the time running the application.

Here comes the service – long-running executable with no user interface, which runs in its own Windows session. Such application can be:

  • executed by any user created in the system (e.g. with specific security policies assigned),
  • started automatically when the system launches,
  • automatically restarted in case of errors,
  • at any time started, paused, stopped or restarted.

Even if you’ve never developed any service applications, you are using many of them – check your services.msc to see the list of services currently running in your system.

Topshelf

Visual Studio 2015 provides a template to create Windows Service application and probably I could finish my post here. However, I would like to share with you an even easier way of building services: to do it with Topshelf – a very lightweight open-source library, which purpose it to make services development, debugging and deployment painless. Topshelf allows the developer to focus on service’s functionality, instead of wasting time interacting with .NET Framework’s build-in services support. There is also no more need to install your service using InstallUtil or learn how to attach your Visual Studio debugger to running service to detect issues.

Using Topshelf it’s enough to create console application, add one service class with public Start and Stop methods, configure service’s startup parameters (its name, display name, description etc.) and you’re ready to go. Below we’ll see how to do it.

Creating Windows Service application

After creating console application in Visual Studio, add Topshelf to the project by installing it from Nuget:

Topshelf - Nuget

Adding service class

Then, create service class, which is responsible for executing your service’s logic:

class FileWatcherService { public bool Start() { // Initialize your service application here return true; } public bool Stop() { // Executed when the service is stopped // Dispose your objects here etc. return true; } } read more...