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!