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!