0 Comments

At first glance, it seemed to me to be a really easy task. Install QEMU for Windows, download latest Raspbian and run! Unfortunately after whole evening of tries I still fail to have it usable anyhow. Maybe it’s not totally not running, but still it’s pretty useless in terms of any further development of application without a device. Simply, at current state (as of 2018-02-18) of QEMU, it doesn’t support emulation of the USB controller, and since the whole network relays on it, there are huge connectivity issues (no network interface at all, so no SSH, no tools installation, no file transfers neither).

Just for reference, here is the tutorial I followed, not to be very bold, that I have discovered everything myself. I appreciate the work already done by QEMU team and others involved. I only hope they can emulate BCM2836’s USB anytime soon…

Probably since the spec of the USB controller is not publicly available, it makes the whole thing harder and that’s why the emulation not yet available. Although I found some article describing try of porting the USB driver itself into the Xinu OS running on Raspberry Pi. Maybe this could be used somehow to create the opposite.


OK. That’s a NO GO for the moment. Is there any other solution?


Well, yes, there is. After a while, it turned out that there are plenty of people (here, here or here) doing some heresy, but at the end of the day, it works. Instead of running Raspbian on emulator of the Raspberry Pi hardware, they use the ARM Versatile/PB board, which works somehow as expected. Among the best, it has network working!

This is pretty amazing, but also has some own quirks. First – a set of kernel patches must be applied to make it boot. Secondly it can handle only up to 256 MB of RAM (qemu exits with an error, when more is specified). Should be enough to start the device, but it’s quite low for some serious scenarios of audio/video processing. Thankfully Dhruv Vyas prepared required QEMU binaries in this open-sourced project (well, took over the work after xecdesign.com went down few years ago and is updating it along with all recent Raspbian releases). Great job!

So after downloading updated kernel, it’s just a matter of issuing single long command (Windows 10 shell):

"C:\Program Files\qemu\qemu-system-arm.exe" -m 256 -M versatilepb -cpu arm1176 -serial stdio -no-reboot -kernel kernel-qemu-4.14.79-stretch -dtb versatile-pb.dtb -net nic -net user -append "root=/dev/sda2 panic=1" -drive format=raw,media=disk,index=0,file=D:\Raspi\2018-11-13-raspbian-stretch-lite.img

Update paths accordingly to your installation. Then QEMU will start fine.


PS.

One final note. It would be recommended at the very beginning to enlarge the SD card image to get some extra space for new programs to be installed.

This could be done with following command:

"C:\Program Files\qemu\qemu-img.exe" resize D:\Raspi\2018-11-13-raspbian-stretch-lite.img +2G


That's all. Have fun!

0 Comments

Some time ago I have written a post about, how to setup Windows 10 to wake it up remotely via network using magic packet. The question that remained unanswered is: how to actually send this packet to the PC to trigger it running.


In the first example I will use Raspberry Pi with Rasbpian Stretch Lite installed:

1) First make sure a tool etherwake is available. If not, this could be fixed with following command, otherwise skip this step:

sudo apt-get install etherwake

2) Then simply invoke it with proper arguments:

sudo etherwake –i <ethernet-interface-name> <PC MAC-address>

Some explanations:

Yes, it will ask you for a password, each time you try to call it. Also MAC address should be specified in format “XX:XX:XX:XX:XX:XX”. That was the easier part.

The harder part is that etherwake by default tries to use eth0 as the network interface, where to send the magic packet. Raspberry has a feature called “Predictable network interface names” enabled by default (since August 2017 I think; was even in Jessie edition, but was disabled by default). With a big probability the name of the interface will be different than eth0 (something like enx?? or wlx?? depending if using LAN or WiFi and ?? should be replaced with Raspberry’s own MAC address).

To list existing network interfaces type this command:

ip link show

Then grab the proper name, which is not a loopback. Or use raspi-config (via command “sudo raspi-config”) and navigate to “2: Network Options” and disable predictable network interface names, so it should go back to using eth0 and wlan0 names.


In the second example I wish to show, how to achieve the same effect on Synology NAS station.

If your DSM is really old, you could use the optional package manager named ipkg. Though this manager make sure wakelan utility is installed. And waking up a PC is just a matter of issuing following command in the console:

export PATH=$PATH:/volume1/@optware/bin/

wakelan –m <PC MAC-address>

MAC this time is in format: “XXYYZZXXYYZZ”.


On the other hand, if you don’t want to play with custom package managers and have a decent DSM 6.x on-board, one could use the build-in synonet utility (as also described here). Then it’s just a matter of calling it this way:

sudo synonet --wake XX:XX:XX:XX:XX:XX eth0

Executable is located at: /usr/syno/sbin/synonet


And that’s all. Have fun!

0 Comments

Among all the features of ASP.NET framework, there is one I love the most:

moving parts of the configuration (i.e. Web.config) into separate files!

It’s just it, a little something, that makes life so much easier by:

  • less effort while working with GiT (conflicts are subtle and with better context, changing braches mostly let you move also your local changes, or reset parts of it)
  • quicker navigation, as they are files with my custom naming convention (via R# hit Ctrl+T and start typing the name using only first uppercase letters of the file to open it)
  • custom sections can also be put in an another file.


In my typical scenario, I move away sections responsible for:

  • database connection strings (as they change the most)
  • WCF service definitions (behaviors, bindings and services themselves) as they can occupy lots of space
  • and definition of my custom section of continuously evolving list of options (titanSection).


Sample web.config

As the picture above shows separation is achieved simply by using “configSource” attribute inside a section that is supposed to be outsourced. And that’s all – just name the file, create it and inside that file define directly the same section tag as from Web.config. But this time put there a real content.


For example the content of database connection-strings (named by me: Web.Connections.config, that is located next to Web.config), could look like that:

Separate file with database connection-strings


You can name the files whatever you like. However I highly encourage you to have a naming schema. Anything that starts with ‘Web’ and has an extension ‘.config’ would be probably sufficient and also be easy enough to remember, what is inside.


Final though on custom section. It might be placed in separate location in identical way. Only difference is that his kind of section should have a code-behind C# class inheriting from ConfigurationSection with all public properties marked with ConfigurationPropertyAttribute attribute (and inner tags define as separate classes inheriting from ConfigurationElement).

Once the class is completed, inside Web.config there should be a link defined between that class and a custom name of the section. Notice the “configSections” and a “section” entry on the picture above. It contains the name of the “titanSection” section and also points to a TitanConfigSection class (with an assembly name) that will handle accumulation of all settings.

Then only the imagination stops you from creating config complicated as the one below:

titanConfig


I hope it proved useful for you too!

0 Comments

It should be simple, it should be quick. And as usual it turned out to be hard, painful and forced me to install Visual Studio 2017 back on a build machine. I’ve cried a lot that hour. Now I am just waiting, what will fail next, once I see this comment in TC build logs, even though I logged-in and obtained permanent license.

[13:05:08][Step 3/3] Starting: C:\TeamCity\buildAgent\temp\agentTmp\custom_script5352870621326270693.cmd
[13:05:08][Step 3/3] in directory: C:\TeamCity\buildAgent\work\2906b7d01f979ef5

[13:05:12][Step 3/3]
[13:05:12][Step 3/3] Microsoft Visual Studio 2017 Version 15.0.27428.2027.
[13:05:12][Step 3/3] Copyright (C) Microsoft Corp. All rights reserved.
[13:05:12][Step 3/3]
[13:05:12][Step 3/3] The license for Visual Studio expires in 30 days.


Anyway, it makes me to loose even more hairs, due to the fact, that not so long ago I happily removed Visual Studio 2010 from it (check this post)! And simply Visual Studio 2017 build-tools were not enough for the SQL Server Data Tools (SSDT) installer including SQL Server Integration Services (SSIS). Somehow documentation stays, it should be possible to continue and that it will install minimal version of Visual Studio (Shell or something?), but at 85% it tried to apply some VSIX package, failed and roll backed everything.

What’s even worse, is that .dtproj project format is incompatible with MSBuild and it’s impossible to build it without essentially Visual Studio IDE (i.e. devenv.com, check here). Even if you wish to build it using VSTS Online/TFS you still need some tricks.

I hope I linked all stuff, that helped me to understand the subject. So let’s stop weeping and wailing and let’s get something done!


TL;DR


Prerequisites:

  1. Install Visual Studio 2017 Community
  2. Install SQL Server Data Tools (SSDT) (with checked option for SQL Server Integration Services)


Now in TeamCity:

  1. Create a build configuration (here named “Bazy Win32” on figures below)
  2. Add new parameter that points to the location of devenv.com of the Visual Studio

    TeamCity build parameters

    i.e.: C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\devenv.com

  3. Add a command-line build step, that will invoke Visual Studio and instruct it to build the solution

    TeamCity build step

    The command is:
    "%env.vs2017_devenv_path%"  <path_to_solution> /rebuild "Development"

    (variable is taken in quotation marks, since it contains spaces etc. as its value)

  4. Remember to put generated .ispac (from bin/Development folder) among other artifacts of the build configuration.
  5. DONE!

0 Comments

Recently, I have shown, how to enable Application Insights within own WCF server application (look here). It might similarly work in other kinds of apps, so we won’t bother with further demystification of this procedure. But as you might suspect (or already stepped on), you will quickly require more metadata transmitted than it is done by default.

My scenario is pretty simple. The WCF server is installed multiple times, in multiple physical locations across the whole country. And they all just sit there, working since most of the bugs aren’t so critical. It can’t be even updated everywhere at the same time. So how to actually distinguish between different instances and app versions in case of a crash or other serious misbehaviors?

And the answer is – ITelemetryInitializer.

This kind of objects are responsible for performing initialization of the telemetry data gathered and then sent back to the Azure’s AppInsights service.


Here is the recipe, how to define and enable one in own project:

1) First create a class that implements ITelemetryInitializer interface.

2) Within Initialize() method, set additional context properties. To match my scenario, let it be two fields:

  • ClientInstance” – to let know, which server it’s running on (yes, it should be read from external configuration file, but should be clear enough for now, as I hard-code it)
  • BuildInfo” – to inform about application version running there, which I read directly from the assembly name

Of course the way it was obtained should be updated to match the logic in your app.

public sealed class ClientInstanceTelemetryInitializer : ITelemetryInitializer
{
    private const string ClientInstanceParam = "ClientInstance";
    private const string BuildInfoParam = "BuildInfo";

    private readonly string _instance;
    private readonly string _version;

    public ClientInstanceTelemetryInitializer()
    {
        _instance = "beaa9ac0-3267-41e4-9c14-2167271aca4d"; // should be different for each running instance
        _version = new AssemblyName(Assembly.GetExecutingAssembly().FullName).Version;
    }

    /// <inheritdoc />
    void ITelemetryInitializer.Initialize(ITelemetry telemetry)
    {
        telemetry.Context.Properties[ClientInstanceParam] = _instance;
        telemetry.Context.Properties[BuildInfoParam] = _version;
    }
}

3) Finally, register the initializer via ApplicationInsights.config file (this file was added automatically to the project, when AppInsights NuGet packages were installed inside the previous guide). Simply add the type at the end of TelemetryInitializers section. It will be instantiated automatically at application startup.

Telemetry Initializers

And that was all again.


Verification:

Now, when navigating to the crash logs on Azure, open a request details, click ‘Show all’ properties and the view should look similar to this one:

Azure Telemetry Info

“Custom Data” section contains info about ClientIntance and BuildInfo as expected.


Thanks!