tpodolak.com

ASP.NET Core - adding controllers directly from integration tests

Mon, 22 Jun 2020 08:00:12 GMT

1. Introduction

From time to time it might happen, that you need to test certain parts of your ASP.NET Core configuration without hitting publicly visible business-related controllers. For instance, in my case, I wanted to make sure that my ASP.NET Core API behavior is consistent with the original API written in Nancy. As you might expect there are quite a lot of differences between both of the frameworks, so let's focus on testing one thing, namely non-nullable reference type handling. Long story short, in order to have the same behavior in ASP.NET Core as in Nancy I had to add the following line of configuration

// This method gets called by the runtime. Use this method to add services to the container.
public void ConfigureServices(IServiceCollection services)
{
    services.AddControllers(opts => opts.SuppressImplicitRequiredAttributeForNonNullableReferenceTypes = true)
        .AddNewtonsoftJson();
}

This one prevents ASP.NET Core from marking non-nullable reference type properties in request as required. Having that configuration ready, I wanted to test it with an end to end test. Because there was no business-related logic yet, I needed to figure out the way of adding API controllers to my application directly from the integration tests. Here is how you can achieve that.

2. Accessing ApplicationPartManager from integration tests

ASP.NET Core is able to compose your API from different parts thanks to ApplicationPartManager. By default, you don't use it directly but rather with IMvcBuilder AddApplicationPart extension method while setting up your application

// This method gets called by the runtime. Use this method to add services to the container.
public void ConfigureServices(IServiceCollection services)
{
    services.AddControllers()
        .AddApplicationPart(typeof(SomeClass).Assembly)
        .AddNewtonsoftJson();
}

However, there is no easy way of getting IMvcBuidler from the integration tests(at least I didn't find a proper way of doing that without tampering too much with the original application pipeline) so we need to access ApplicationPartManager directly. Inspecting the source code of the framework you will find that ApplicationPartManager can be retrieved directly from IServiceCollection with following code

private static ApplicationPartManager GetApplicationPartManager(IServiceCollection services)
{
    var manager = GetServiceFromCollection<ApplicationPartManager>(services);
    if (manager == null)
    {
        manager = new ApplicationPartManager();

        var environment = GetServiceFromCollection<IWebHostEnvironment>(services);
        var entryAssemblyName = environment?.ApplicationName;
        if (string.IsNullOrEmpty(entryAssemblyName))
        {
            return manager;
        }

        manager.PopulateDefaultParts(entryAssemblyName);
    }

    return manager;
}

private static T GetServiceFromCollection<T>(IServiceCollection services)
{
    return (T)services
        .LastOrDefault(d => d.ServiceType == typeof(T))
        ?.ImplementationInstance;
}

Applying similar code to the WebApplicationFactory will allow us to add controllers directly from tests

[Fact]
public async Task DoesNotReturnBadRequest_WhenNonNullableTypeHasNoValue_FirstAttempt()
{
    var webApplicationFactory = new WebApplicationFactory<Startup>()
        .WithWebHostBuilder(
            builder => builder.ConfigureServices(services =>
            {
                var partManager = (ApplicationPartManager) services
                    .Last(descriptor => descriptor.ServiceType == typeof(ApplicationPartManager))
                    .ImplementationInstance;

                partManager.ApplicationParts.Add(new AssemblyPart(GetType().Assembly));
            }));

    var expectedResponse = new Request
    {
        Id = "1"
    };

    var httpClient = webApplicationFactory.CreateClient();
    var httpResponseMessage = await httpClient.GetAsync("test?id=1");

    httpResponseMessage.IsSuccessStatusCode.Should().BeTrue();
    var rawContent = await httpResponseMessage.Content.ReadAsStringAsync();
    var result = JsonConvert.DeserializeObject<Request>(rawContent);

    result.Should().BeEquivalentTo(expectedResponse);
}

[ApiController]
public class MvcOptionsTestController : ControllerBase
{
    [HttpGet("test")]
    public object Get([FromQuery] Request request)
    {
        return request;
    }
}

public class Request
{
    public string Id { get; set; }

    public string OtherId { get; set; }
}

3. Handling private controllers

The solution presented below works nice, however it has couple of drawbacks. First of all, it only discovers public non-nested controllers. Second of all, it will always add all controllers from given assembly - which potentially might affect other integration tests. In order to get rid of these drawbacks, we need to tell ApplicationPartManager to include only selected controllers. We can achieve that by adding additional IApplicationFeatureProvider<ControllerFeature> to the list of FeatureProviders.

public class ExternalControllersFeatureProvider : IApplicationFeatureProvider<ControllerFeature>
{
    private readonly Type[] _controllers;

    public ExternalControllersFeatureProvider(params Type[] controllers)
    {
        _controllers = controllers ?? Array.Empty<Type>();
    }

    public void PopulateFeature(IEnumerable<ApplicationPart> parts, ControllerFeature feature)
    {
        foreach (var controller in _controllers)
        {
            feature.Controllers.Add(controller.GetTypeInfo());
        }
    }
}

[Fact]
public async Task DoesNotReturnBadRequest_WhenNonNullableTypeHasNoValue()
{
    var webApplicationFactory = new WebApplicationFactory<Startup>()
        .WithWebHostBuilder(
            builder => builder.ConfigureServices(services =>
            {
                var partManager = (ApplicationPartManager) services
                    .Last(descriptor => descriptor.ServiceType == typeof(ApplicationPartManager))
                    .ImplementationInstance;

                partManager.FeatureProviders.Add(new ExternalControllersFeatureProvider(typeof(MvcOptionsTestController)));
            }));
// rest of the code omitted for brevity
}

Putting it all together and applying some refactoring we will end up with following code

internal static class WebHostBuilderExtensions
{
    public static IWebHostBuilder WithAdditionalControllers(this IWebHostBuilder builder, params Type[] controllers)
    {
        return builder.ConfigureTestServices(
            services =>
            {
                var partManager = GetApplicationPartManager(services);

                partManager.FeatureProviders.Add(new ExternalControllersFeatureProvider(controllers));
            });
    }

    private static ApplicationPartManager GetApplicationPartManager(IServiceCollection services)
    {
        var partManager = (ApplicationPartManager)services
            .Last(descriptor => descriptor.ServiceType == typeof(ApplicationPartManager))
            .ImplementationInstance;
        return partManager;
    }

    private class ExternalControllersFeatureProvider : IApplicationFeatureProvider<ControllerFeature>
    {
        private readonly Type[] _controllers;

        public ExternalControllersFeatureProvider(params Type[] controllers)
        {
            _controllers = controllers ?? Array.Empty<Type>();
        }

        public void PopulateFeature(IEnumerable<ApplicationPart> parts, ControllerFeature feature)
        {
            foreach (var controller in _controllers)
            {
                feature.Controllers.Add(controller.GetTypeInfo());
            }
        }
    }
}

public class MvcOptionsConfigurationTests
{
    [Fact]
    public async Task DoesNotReturnBadRequest_WhenNonNullableTypeHasNoValue()
    {
        var webApplicationFactory = new WebApplicationFactory<Startup>()
            .WithWebHostBuilder(
                builder => builder.WithAdditionalControllers(typeof(MvcOptionsTestController)));

        var httpClient = webApplicationFactory.CreateClient();
        var expectedResponse = new Request
        {
            Id = "1"
        };

        var httpResponseMessage = await httpClient.GetAsync("test?id=1");

        httpResponseMessage.IsSuccessStatusCode.Should().BeTrue();
        var rawContent = await httpResponseMessage.Content.ReadAsStringAsync();
        var result = JsonConvert.DeserializeObject<Request>(rawContent);

        result.Should().BeEquivalentTo(expectedResponse);
    }

    [ApiController]
    private class MvcOptionsTestController: ControllerBase
    {
        [HttpGet("test")]
        public object Get([FromQuery] Request request)
        {
            return request;
        }
    }

    private class Request
    {
        public string Id { get; set; }

        public string OtherId { get; set; }
    }
}

Source code for this post can be found here

Running ASP.NET Core together with Nancy

Mon, 20 Apr 2020 08:00:44 GMT

1. Introduction

Our current API runs on Nancy which in my opinion is past its prime. Recent news from the GitHub issue tracker seems to confirm that thesis, that is why we started looking for a migration path from Nancy based API to ASP.NET Core. Because the codebase is quite large we didn't want to do a Big Bang Rewrite but instead of that, we wanted to gradually replace old API with a new one, so both of them can coexist next to each other.

2. Legacy API

Before I jump into implementation, here is a sample Nancy API with two endpoints - products and variants

public class Startup
{
    // This method gets called by the runtime. Use this method to add services to the container.
    public void ConfigureServices(IServiceCollection services)
    {
        // nancy has its own container
    }

    // This method gets called by the runtime. Use this method to configure the HTTP request pipeline.
    public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
    {
        app.UseOwin(owin => owin.UseNancy());
    }
}

public sealed class ProductsNancyModule : NancyModule
{
    public ProductsNancyModule()
    {
        Get("products", args => Response.AsJson(new List<Product>
        {
            new Product(Guid.NewGuid().ToString(), "First product from nancy"),
            new Product(Guid.NewGuid().ToString(), "Second product from nancy")
        }));
    }
}

public sealed class VariantsNancyModule : NancyModule
{
    public VariantsNancyModule()
    {
        Get("variants", args => Response.AsJson(new List<Variant>
        {
            new Variant(Guid.NewGuid().ToString(), Guid.NewGuid().ToString(), "first variant from nancy"),
            new Variant(Guid.NewGuid().ToString(), Guid.NewGuid().ToString(), "second variant from nancy")
        }));
    }
}

The goal is to replace products endpoint with ASP.NET Core implementation while variants endpoint should still be served by Nancy

3. Combining Nancy with `ASP.NET Core`

The solution is based on branching the pipeline feature which is available starting from ASP.NET Core 2.1. Long story short - it is possible to configure different pipelines for different route paths thanks to

public static IApplicationBuilder Map(this IApplicationBuilder app, PathString pathMatch, Action<IApplicationBuilder> configuration)

method. Having that in mind we can `Map` products path to run through ASP.NET Core pipeline whereas the rest would go through Nancy.

// This method gets called by the runtime. Use this method to add services to the container.
public void ConfigureServices(IServiceCollection services)
{
    // register mvc services
    services.AddControllers();
    services.AddMvc(options => options.EnableEndpointRouting = false);
}

// This method gets called by the runtime. Use this method to configure the HTTP request pipeline.
public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
    // run everything with products prefix through mvc
    app.Map("/products", appBuilder =>
    {
        appBuilder.UseMvc();
    });

    // run the rest through Nancy
    app.Map(string.Empty, appBuilder =>
    {
        appBuilder.UseOwin(options => options.UseNancy());
    });
}

[ApiController]
public class ProductsController : ControllerBase
{
    [HttpGet("/products")]
    public List<Product> Get()
    {
        return new List<Product>
        {
            new Product(Guid.NewGuid().ToString(), "First product from asp net core"),
            new Product(Guid.NewGuid().ToString(), "Second product from asp net core")
        };
    }
}

At this point we are almost there, however running request through Map pipeline will remove the path prefix, meaning that our controller would be accessible under / path instead of products. In order to bypass this limitation we have to restore original prefix with RewriteMiddleware. Once we put it all together, now we are able to replace multiple Nancy endpoints with ASP.NET Core ones using following piece of code

// This method gets called by the runtime. Use this method to configure the HTTP request pipeline.
public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
    var aspNetCorePaths = new PathString[] {"/products"};
    foreach (var path in aspNetCorePaths)
    {
        app.Map(path, appBuilder =>
        {
            // we still want to access the resource under old url, so we need to add the branch path back to the route
            var rewriteOptions = new RewriteOptions().AddRewrite(
                "(?<Path>.*)",
                $"{path}/${{Path}}",
                skipRemainingRules: true);
            appBuilder.UseRewriter(rewriteOptions);
            appBuilder.UseMvc();
        });
    }

    app.Map(string.Empty, appBuilder =>
    {
        appBuilder.UseOwin(options => options.UseNancy());
    });
}

Source code for this post can be found here

Introduce substitute refactoring comes to NSubstitute.Analyzers

Thu, 09 Apr 2020 08:00:03 GMT

I am glad to announce the newest version of NSubstitute.Analyzers comes with "introduce substitute" refactoring, which allows you to automatically create substitutes for constructor arguments as fields or local variables. As an image is worth a thousand words here is a quick demo of C# version

and VisualBasic one

.NET Core - missing currency symbol in docker alpine image

Mon, 18 Nov 2019 13:54:32 GMT

During the process of moving a Scala-based API to .NET Core, we encountered an interesting localization issue when running our code in a docker container based on an alpine image. The code itself was doing a currency formatting based on some culture. It looked more or less as below

[Route("api/[controller]")]
[ApiController]
public class PriceController : ControllerBase
{
    [HttpGet]
    public ActionResult<object> Get(string cultureCode = "de-DE")
    {
        var cultureInfo = CultureInfo.CreateSpecificCulture(cultureCode);
        var price = 10m;
        
        return new
        {
            price,
            formattedPrice = price.ToString("C", cultureInfo),
            currencySymbol = cultureInfo.NumberFormat.CurrencySymbol
        };
    }
}

We also had some integration tests for that piece of logic

public class PriceTests : IClassFixture<WebApplicationFactory<Startup>>
{
    private readonly WebApplicationFactory<Startup> _factory;

    public PriceTests(WebApplicationFactory<Startup> factory)
    {
        _factory = factory;
    }
        
    [Fact]
    public async Task GetPrice_ReturnsCorrectCurrency()
    {
        var httpClient = _factory.CreateClient();
        var httpResponseMessage = await httpClient.GetAsync("api/Price");
            
        httpResponseMessage.EnsureSuccessStatusCode();
        var content = await httpResponseMessage.Content.ReadAsStringAsync();
        var jObject = JObject.Parse(content);

        jObject["currencySymbol"].ToObject<string>().Should().Be("€");
    }
}

The tests were run during a CI build in a container with an image defined as below

# Builder image
FROM mcr.microsoft.com/dotnet/core/sdk:2.1.700-alpine AS builder
WORKDIR /sln

COPY ./*.sln ./

# Copy the main source project files
COPY src/*/*.csproj ./
RUN for file in $(ls *.csproj); do mkdir -p src/${file%.*}/ && mv $file src/${file%.*}/; done

# Copy the test project files
COPY test/*/*.csproj ./
RUN for file in $(ls *.csproj); do mkdir -p test/${file%.*}/ && mv $file test/${file%.*}/; done

RUN dotnet restore

# Copy across the rest of the source files
COPY ./test ./test
COPY ./src ./src

RUN dotnet build -c Release

RUN dotnet test "./test/AlpineMissingCurrencySymbol.Tests/AlpineMissingCurrencySymbol.Tests.csproj" \
    -c Release --no-build --no-restore

RUN dotnet publish "./src/AlpineMissingCurrencySymbol/AlpineMissingCurrencySymbol.csproj" \
    -c Release -o "../../dist" --no-restore

# App image
FROM mcr.microsoft.com/dotnet/core/aspnet:2.1.11-alpine
WORKDIR /app
ENTRYPOINT ["dotnet", "AlpineMissingCurrencySymbol.dll"]
COPY --from=builder /sln/dist .

At this point, we were sure that everything works fine, as the tests were green and everything was also working correctly on our local machines. However, after deployment to a testing environment, we started getting invalid currency symbols

curl localhost:8080/api/price 
{ 
  "price": 10, 
  "formattedPrice": "¤10.00", 
  "currencySymbol": "¤" 
}

As you can see the response contains ¤ (invariant currency symbol) instead of expected €. It took us some time to figure this out but finally, it turned out that aspnet:2.1.11-alpine image(the one we used for running the application) contrary to the SDK image(used for building and running tests) is missing icu-libs package. In default conditions, the application should throw the following exception during the startup

FailFast:
Couldn't find a valid ICU package installed on the system. Set the configuration flag System.Globalization.Invariant to true if you want to run with no globalization support.

   at System.Environment.FailFast(System.String)
   at System.Globalization.GlobalizationMode.GetGlobalizationInvariantMode()
   at System.Globalization.GlobalizationMode..cctor()
   at System.Globalization.CultureData.CreateCultureWithInvariantData()
   at System.Globalization.CultureData.get_Invariant()
   at System.Globalization.CultureInfo..cctor()
   at System.StringComparer..cctor()
   at System.AppDomain.InitializeCompatibilityFlags()
   at System.AppDomain.Setup(System.Object)

However, aspnet:2.1.11-alpine image has the DOTNET_SYSTEM_GLOBALIZATION_INVARIANT flag set to true by default, so the missing package was not validated during a startup. After all, in order to fix the issue, we had to install the icu-libs package and also set the DOTNET_SYSTEM_GLOBALIZATION_INVARIANT back to false. This was done by these two lines in Dockerfile

ENV DOTNET_SYSTEM_GLOBALIZATION_INVARIANT=false 
RUN apk add --no-cache icu-libs

Once the lines were added the application started working as expected

curl localhost:8080/api/price 
{ 
  "price": 10, 
  "formattedPrice": "10,00 €", 
  "currencySymbol": "€" 
}

Source code for this post can be found here

MongoDB.Driver - class-based server side projection

Tue, 22 Oct 2019 08:00:31 GMT

1. Introduction

When working with NoSQL databases, your documents might be quite heavy and in some cases, you would like to get only a slice of original data. For instance, let's assume we have an Account document which among other things contains a list of transactions

public class Account : IAccountDefinition
{
    public ObjectId Id { get; set; }

    public string Name { get; set; }

    public List<Transaction> Transactions { get; set; }
}

public class Transaction
{
    public ObjectId Id { get; set; }
        
    public decimal Amount { get; set; }
        
    public DateTime CreatedAt { get; set; }
        
    public DateTime ModifiedAt { get; set; }
}

As there might be hundreds of transaction in the account object, you might want to occasionally work on a subset of original data, say for instance AccountSlim object to improve the performance

public class AccountSlim : IAccountDefinition
{
    public ObjectId Id { get; set; }
        
    public string Name { get; set; }
}

2.Exploring existing options

MongoDB.Driver has a couple of ways of defining projections so as you can operate on a slimmer object instead of a default one. For instance

List<AccountSlim> accountSlims = await accountsCollection.Find(defaultAccountFilterDefinition)
                .Project(Builders<Account>.Projection.As<AccountSlim>())
                .ToListAsync();


IAsyncCursor<AccountSlim> asyncCursor = await accountsCollection.FindAsync(defaultAccountFilterDefinition,
                new FindOptions<Account, AccountSlim>());

Unfortunately, those are a client-side projection. This means that the entire object is returned from the database and we just serialized it to a different class. You can check it on your own by examining request and result commands sent to Mongo

var clientSettings = MongoClientSettings.FromUrl(new MongoUrl("mongodb://localhost:27017")); 
clientSettings.ClusterConfigurator += builder => 
{ 
    builder.Subscribe<CommandStartedEvent>(OnCommandStarted); 
    builder.Subscribe<CommandSucceededEvent>(OnCommandSucceeded); 
}; 
var client = new MongoClient(clientSettings); 

private static void OnCommandSucceeded(CommandSucceededEvent @event) 
{ 
    if (@event.CommandName == FindCommandName) 
    { 
        Console.WriteLine("Returned document:"); 
        PrintDocument(@event.Reply); 
    } 
} 
 
private static void OnCommandStarted(CommandStartedEvent @event) 
{ 
    if (@event.CommandName == FindCommandName) 
    { 
        Console.WriteLine("Requested document:"); 
        PrintDocument(@event.Command); 
    } 
}

In both cases requested query doesn't contain projection section, so entire document is returned

// query 
{ 
  "find" : "Accounts", 
  "filter" : { 
    "_id" : ObjectId("5dac6ab1ea342a254e1b7748") 
  }, 
  "$db" : "Accounting", 
  "lsid" : { 
    "id" : CSUUID("c6b40361-c47f-4fe6-99bd-6a9ec1702576") 
  } 
} 

// returned document 
{ 
  "cursor" : { 
    "firstBatch" : [{ 
        "_id" : ObjectId("5dac6ab1ea342a254e1b7748"), 
        "AccountName" : "WRKYDWKKJY", 
        "Transactions" : [{ 
            "_id" : ObjectId("5dac6ab1ea342a254e1b7749"), 
            "Amount" : "413648280", 
            "CreatedAt" : ISODate("2019-10-20T14:09:53.635Z"), 
            "ModifiedAt" : ISODate("2019-10-20T14:09:53.635Z") 
          }] 
      }], 
    "id" : NumberLong(0), 
    "ns" : "Accounting.Accounts" 
  }, 
  "ok" : 1.0 
}

Of course, there is a possibility to manually create a server-side projection, for instance

var accountSlims = await accountsCollection.Find(defaultAccountFilterDefinition)
                .Project(new ObjectProjectionDefinition<Account, AccountSlim>(new { id = 1, name = 1 }))
                .ToListAsync();

or with a strongly typed version

var bsonDocument = Builders<Account>.Projection.Exclude(x => x.Transactions)
                .Render(accountsCollection.DocumentSerializer, accountsCollection.Settings.SerializerRegistry);

List<AccountSlim> accountSlim = await accountsCollection.Find(defaultAccountFilterDefinition)
                .Project(new BsonDocumentProjectionDefinition<Account, AccountSlim>(bsonDocument))
                .ToListAsync();

However, in my opinion, this is error-prone and it would be better to generate server-side projection automatically based on properties in a slim object. As I didn't find anything like that in the official driver, here is my approach for handling this

3. Class-based server-side projection

In order to create a custom projection, all we have to do is to extend ProjectionDefinition<TSource, TResult> class and provide a RenderedProjectionDefinition with all properties which are in both "heavy" and "slim" object

using System.Collections.Generic;
using System.Collections.ObjectModel;
using System.Linq;
using System.Reflection;
using MongoDB.Bson.Serialization;
using MongoDB.Driver;

namespace MongoDBServerSideProjection.Projections
{
    public class ServerSideProjectionDefinition<TSource, TResult> : ProjectionDefinition<TSource, TResult>
    {
        private readonly ProjectionDefinition<TSource> _projectionDefinition;

        public ServerSideProjectionDefinition()
        {
            _projectionDefinition = BuildProjectionDefinition();
        }

        public override RenderedProjectionDefinition<TResult> Render(IBsonSerializer<TSource> sourceSerializer, IBsonSerializerRegistry serializerRegistry)
        {
            var bsonDocument = _projectionDefinition.Render(sourceSerializer, serializerRegistry);

            return new RenderedProjectionDefinition<TResult>(bsonDocument, serializerRegistry.GetSerializer<TResult>());
        }

        private static ProjectionDefinition<TSource> BuildProjectionDefinition()
        {
            var sourceProperties = ProjectionPropertyCache<TSource>.PropertyNames;
            var resultProperties = ProjectionPropertyCache<TResult>.PropertyNames;

            var projectionDefinitionBuilder = Builders<TSource>.Projection;

            var projectionDefinitions = resultProperties.Intersect(sourceProperties).Select(
                name => projectionDefinitionBuilder.Include(new StringFieldDefinition<TSource>(name)));

            return projectionDefinitionBuilder.Combine(projectionDefinitions);
        }

        private class ProjectionPropertyCache<T>
        {
            static ProjectionPropertyCache()
            {
                PropertyNames = GetProperties();
            }

            public static IReadOnlyCollection<string> PropertyNames { get; }

            private static ReadOnlyCollection<string> GetProperties()
            {
                return typeof(T).GetProperties(BindingFlags.Public | BindingFlags.Instance)
                    .Where(prop => !prop.IsSpecialName).Select(prop => prop.Name).ToList().AsReadOnly();
            }
        }
    }
}

As you can see we use MongoDB.Driver build-in projections to render our custom projection consisting of necessary properties. Note, that as we are using StringFieldDefinition instead of defining Bson document manually, the projection will take into account potential class mappings or attribute mappings applied to your object

BsonClassMap.RegisterClassMap<Account>(cm =>
            {
                cm.AutoMap();
                cm.MapProperty(account => account.Name).SetElementName("AccountName");
            });

Having the projection ready we can make it a bit easier to use by introducing some extensions. The first one looks as follows

using MongoDB.Driver;
using MongoDBServerSideProjection.Projections;

namespace MongoDBServerSideProjection.Extensions
{
    public static class ProjectionDefinitionBuilderExtensions
    {
        public static ServerSideProjectionDefinition<TSource, TResult> ServerSide<TSource, TResult>(this ProjectionDefinitionBuilder<TSource> builder)
        {
            return new ServerSideProjectionDefinition<TSource, TResult>();
        }
    }
}

which allows you to use this projection similarly like others – so by accessing Builders class

var projection = Builders<Account>.Projection.ServerSide<Account, AccountSlim>();
List<AccountSlim> slims = await accountsCollection.Find(defaultAccountFilterDefinition)
                .Project(projection)
                .ToListAsync();

The second method will extend IFindFluent<TDocument, TProjection> interface

using MongoDB.Driver;

namespace MongoDBServerSideProjection.Extensions
{
    public static class FindFluentExtensions
    {
        public static IFindFluent<TSource, TResult> ProjectTo<TSource, TResult>(this IFindFluent<TSource, TSource> findFluent)
        {
            var serverSideProjectionDefinition = Builders<TSource>.Projection.ServerSide<TSource, TResult>();
            return findFluent.Project(serverSideProjectionDefinition);
        }
    }
}

and thanks to it we will end up with an even better syntax

List<AccountSlim> list = await accountsCollection.Find(defaultAccountFilterDefinition)
                .ProjectTo<Account, AccountSlim>()
                .ToListAsync();

One way or another we will end up with proper projection definition which will result in a smaller document returned from the database

// query
{ 
  "find" : "Accounts", 
  "filter" : { 
    "_id" : ObjectId("5dac846eea29403cb83f99bb") 
  }, 
  "projection" : { 
    "_id" : 1, 
    "AccountName" : 1 
  }, 
  "$db" : "Accounting", 
  "lsid" : { 
    "id" : CSUUID("cf5d5a88-2598-4110-9295-6417d1a5f7dd") 
  } 
} 

// returned document
{ 
  "cursor" : { 
    "firstBatch" : [{ 
        "_id" : ObjectId("5dac846eea29403cb83f99bb"), 
        "AccountName" : "CBBRRWQVKJ" 
      }], 
    "id" : NumberLong(0), 
    "ns" : "Accounting.Accounts" 
  }, 
  "ok" : 1.0 
}

Source code for this post can be found here

Performance improvements in NSubstitute.Analyzers 1.0.11

Mon, 21 Oct 2019 12:57:05 GMT

1. Introduction

I am glad to announce that the latest release of NSubstitute.Analyzers (apart from some bugfixes) brings a lot of performance and memory usage improvements for most of the analyzers. The benchmark results shown below should give you enough information about the speed and memory consumption of the newest version of the library. If you are interested in actual changes behind these results please take a look at this pull request.

2. Benchmark comparision of NSubstitute.Analyzers.CSharp

Analyzer	Mean (us)	Error (us)	StdDev (us)	Gen 0	Gen 1	Allocated (KB)
CallInfoAnalyzer	1,897.0	5.646	5.2814	136.7188	11.7188	424.54
ConflictingArgumentAssignmentsAnalyzer	554.2	1.018	0.9524	33.2031	1.9531	103.47
NonSubstitutableMemberAnalyzer	2,466.9	9.317	8.2596	179.6875	15.6250	560.33
NonSubstitutableMemberReceivedAnalyzer	644.4	2.280	1.9039	31.2500	6.8359	96.27
NonSubstitutableMemberWhenAnalyzer	995.9	2.320	1.9370	37.1094	7.8125	116.74
ReEntrantSetupAnalyzer	57,979.0	196.824	174.4794	2333.3333	-	7175.61
SubstituteAnalyzer	1,960.4	8.197	7.2666	89.8438	19.5313	343.67
UnusedReceivedAnalyzer	524.0	1.671	1.5630	29.2969	1.9531	92.45

Analyzer	Mean (us)	Error (us)	StdDev (us)	Gen 0	Gen 1	Allocated (KB)
CallInfoAnalyzer	1,828.8	5.599	4.963	123.0469	11.7188	379.78
ConflictingArgumentAssignmentsAnalyzer	510.3	1.973	1.846	33.2031	1.9531	102.76
NonSubstitutableMemberAnalyzer	766.0	2.798	2.336	39.0625	8.7891	122.27
NonSubstitutableMemberReceivedAnalyzer	600.6	3.411	3.191	27.3438	5.8594	85.82
NonSubstitutableMemberWhenAnalyzer	866.0	3.144	2.941	34.1797	9.7656	107.87
ReEntrantSetupAnalyzer	7,442.0	34.067	31.866	281.2500	15.6250	870.18
SubstituteAnalyzer	1,870.2	29.787	27.863	87.8906	23.4375	346.09
UnusedReceivedAnalyzer	482.1	1.705	1.511	25.8789	1.9531	80.96

3. Benchmark comparision of NSubstitute.Analyzers.VisualBasic

Method	Mean (ms)	Error (ms)	StdDev (ms)	Gen 0	Gen 1	Allocated (KB)
CallInfoAnalyzer	3.459	0.0137	0.0121	156.2500	11.7188	484.15
ConflictingArgumentAssignmentsAnalyzer	1.279	0.0103	0.0086	21.4844	1.9531	69.15
NonSubstitutableMemberAnalyzer	1.975	0.0108	0.0090	35.1563	7.8125	108
NonSubstitutableMemberReceivedAnalyzer	1.287	0.0070	0.0065	13.6719	1.9531	47.46
NonSubstitutableMemberWhenAnalyzer	1.589	0.0103	0.0092	25.3906	5.8594	82.72
ReEntrantSetupAnalyzer	54.131	0.2320	0.1937	3600.0000	-	11139.45
SubstituteAnalyzer	3.615	0.0168	0.0149	105.4688	23.4375	393.13
UnusedReceivedAnalyzer	1.306	0.0258	0.0528	13.6719	1.9531	43.3

Analyzer	Mean (ms)	Error (ms)	StdDev (ms)	Gen 0	Gen 1	Allocated (KB)
CallInfoAnalyzer	3.737	0.0878	0.1110	152.3438	11.7188	471.79
ConflictingArgumentAssignmentsAnalyzer	1.402	0.0266	0.0285	21.4844	1.9531	68.36
NonSubstitutableMemberAnalyzer	1.543	0.0264	0.0247	25.3906	5.8594	81
NonSubstitutableMemberReceivedAnalyzer	1.213	0.0051	0.0048	13.6719	1.9531	45.43
NonSubstitutableMemberWhenAnalyzer	1.475	0.0055	0.0051	27.3438	7.8125	85.25
ReEntrantSetupAnalyzer	7.044	0.0236	0.0209	265.6250	7.8125	837.14
SubstituteAnalyzer	3.333	0.0912	0.1186	101.5625	23.4375	377.16
UnusedReceivedAnalyzer	1.102	0.0067	0.0062	11.7188	-	40.24

NSubstitute.Analyzers 1.0.0 released

Wed, 24 Oct 2018 09:00:51 GMT

A while ago I've announced a release of the first beta package of NSubstitute.Analyzers. Now, 4 months later I am happy to say that the first stable version is available for download. As usual, analyzers comes with two flavors:

Both of them come together with 19 diagnostics, which will warn you against common misusages of NSubstitue API. Feel free to grab them from NuGet and try them in your project. In case of any issues don't hestitate to report a bug via GitHub issue tracker.

Announcing NSubstitute.Analyzers (beta)

Mon, 11 Jun 2018 08:06:20 GMT

1. Introduction

I am glad to announce that yesterday, together with NSubstitute team we released first beta version of Roslyn analyzers for NSubstitute - NSubstitute.Analyzers. The analyzers come in two flavors: NSubstitute.Analyzers.CSharp and NSubstitute.Analyzers.VisualBasic. Feel free to grab them from NuGet and try them in your project.

2. Diagnostics

As for today analyzers can detect two most common misusages of NSubstitute:

non-virtual call setup
Received used without following method call

Feels free to suggest additional diagnostic you would like to have in the package.

ASP.NET Web API 2 - missing swagger query parameters

Mon, 23 Apr 2018 08:00:27 GMT

Last week I've encountered an interesting bug in swagger documentation of our API. For some reason couple of Get operations were missing some of the query parameters. The issue itself was only visible in a couple of controllers, simplified version of one of them is shown below

public class ValuesController : ApiController
{
    // GET api/values
    public IEnumerable<string> Get([FromUri] FullAvailabilityRequest request)
    {
        return new string[] {"value1", "value2"};
    }
}

As you can see the controller has a Get method which takes as an argument following class

public class FullAvailabilityRequest : AvailabilityRequest
{
    public string TermsOfService { get; set; }
}

[DataContract]
public class AvailabilityRequest
{
    [DataMember]
    public string Origin { get; set; }

    [DataMember]
    public string Destination { get; set; }
}

If you run swagger for Get operation you will see that only two parameters are listed in a parameter list

After some digging I found the actual problem were basically [DataMember] and [DataContract] attributes randomly scattered in the models used in Get methods arguments. Even though these attributes are not used for model binding from the query string, swagger takes them into account either way. It happens basically because swagger under the hood uses JsonObjectContract (even for [FromUri] request classes) and by default it respects [DataContract] attribute - more info can be found here. Removing redundant [DataContract] and [DataMember] attributes from respective models solved the issue.

PS. This particular corner case is not an issue for ASP.NET Core swagger implementation.

Solution-wide project properties with Directory.Build.props

Tue, 03 Apr 2018 08:00:14 GMT

1. Problem

When you work with a solution which contains multiple projects, you usually have some kind of convention which is applied to all of the projects. For instance, in my case, I always make sure that Stylecop.Analyzers package is installed and properly configured in every project. In this particular case, this boils down to adding these lines into the csproj file

<PropertyGroup>
  <TreatWarningsAsErrors>True</TreatWarningsAsErrors>
</PropertyGroup>
<ItemGroup>
  <AdditionalFiles Include="..\StyleCop.json" />
</ItemGroup>
<ItemGroup>
  <PackageReference Include="StyleCop.Analyzers" Version="1.0.2" />
</ItemGroup>

Unfortunately, you have to add these lines to every project in a solution in order to make the Stylecop.Analyzers work for given project. This might be fine if you create all of them up front, but in real life scenario sooner or later you will add a new project to the solution. In that case, you might forget about adding those magic lines, so you will end up with inconsistent coding style in your repository. An additional problem with this approach is a code duplication so in case you rename StyleCop.json file you will have to make sure you update it everywhere. A partial solution for that problem is a manual import of custom made .props file, however, this approach is not perfect as well. The import part is not automatic, that is why you still have to remember about adding import directive to all of your projects.

2. Solution

Fortunately starting form MSBuild 15 you can bypass the limitations mentioned above thanks to automatic imports of properties from Directory.Build.props file. All you have to do is to create a beforementioned file in the root folder of your solution and you are good to go. The properties defined in the Directory.Build.props file will be automatically propagated to all of the child projects. In my case, this file looks as follows

<Project>
  <PropertyGroup>
    <TreatWarningsAsErrors>True</TreatWarningsAsErrors>
  </PropertyGroup>
  <ItemGroup>
    <AdditionalFiles Include="..\StyleCop.json" />
  </ItemGroup>
  <ItemGroup>
    <PackageReference Include="StyleCop.Analyzers" Version="1.0.2" />
  </ItemGroup>
</Project>

The sample application which leverages this feature can be found here

ASP.NET Core – custom ILogger and Nlog callsite layout renderer issue

Thu, 01 Mar 2018 08:00:34 GMT

1. Introduction

In my current project, we use Microsoft.Extensions.Logging.ILogger<T> default implementation as our logging mechanism. This basically comes with the ASP.NET Core 2.0 package and it was working fine so far. However recently we decided to switch the default implementation with a custom one, due to the fact that we wanted to have some additional logic applied for all of the logging providers.

2. Implementation

The custom implementation itself is very similar to the original one, we came up with something like that

public class Logger<T> : ILogger<T>
{
    private readonly ILogger _logger;

    public Logger(ILoggerFactory loggerFactory)
    {
        _logger = loggerFactory.CreateLogger<T>();
    }

    public void Log<TState>(LogLevel, EventId, TState state, Exception, Func<TState, Exception, string> formatter)
    {
        string Formatter(TState innserState, Exception innerException)
        {
            // additional logic goes here, in my case that was extracting additional information from custom exceptions
            var message = formatter(innserState, innerException) ?? string.Empty;
            return message + " additional stuff in here";
        }

        _logger.Log(logLevel, eventId, state, exception, Formatter);
    }

    public bool IsEnabled(LogLevel logLevel)
    {
        return _logger.IsEnabled(logLevel);
    }

    public IDisposable BeginScope<TState>(TState state)
    {
        return _logger.BeginScope(state);
    }
}

and we replaced the default logger with this code

services.Replace(new ServiceDescriptor(typeof(ILogger<>), typeof(Logger.Logger<>), ServiceLifetime.Singleton));

As you can see we basically wanted to add information from custom exceptions to the message. Due to the fact that this is added in here, we don’t have to modify all of our existing logging providers.

3. `NLog` call site renderer issue

Once we run the application all of the providers were working fine and were producing expected output apart from NLog provider. Originally NLog provider for the following code

[Route("api/[controller]")]
public class ValuesController : Controller
{
    private readonly ILogger<ValuesController> _logger;

    public ValuesController(ILogger<ValuesController> logger)
    {
        _logger = logger;
    }

    [HttpGet]
    public IEnumerable<string> Get()
    {
        _logger.LogTrace("Get method called trace");
        _logger.LogWarning("Get method called warning");
        _logger.LogError("Get method called error");
        _logger.LogInformation("Get method called information");

        return new string[] {"value1", "value2"};
    }
}

was producing this output

TimeStamp=2018-02-28 20:14:37.2711 Callsite=AspNetCoreCustomLoggerAndNLogCallsiteIssue.Controllers.ValuesController.Get Level=TRACE Message=Get method called trace 
TimeStamp=2018-02-28 20:14:37.3261 Callsite=AspNetCoreCustomLoggerAndNLogCallsiteIssue.Controllers.ValuesController.Get Level=WARN Message=Get method called warning 
TimeStamp=2018-02-28 20:14:37.3261 Callsite=AspNetCoreCustomLoggerAndNLogCallsiteIssue.Controllers.ValuesController.Get Level=ERROR Message=Get method called error 
TimeStamp=2018-02-28 20:14:37.3261 Callsite=AspNetCoreCustomLoggerAndNLogCallsiteIssue.Controllers.ValuesController.Get Level=INFO Message=Get method called information

However, after introducing new implementation of ILogger<T>, it started appending wrong caller member name

TimeStamp=2018-02-28 20:17:27.4044 Callsite=AspNetCoreCustomLoggerAndNLogCallsiteIssue.Logger`1.Log Level=TRACE Message=Get method called trace additional stuff in here 
TimeStamp=2018-02-28 20:17:27.5117 Callsite=AspNetCoreCustomLoggerAndNLogCallsiteIssue.Logger`1.Log Level=WARN Message=Get method called warning additional stuff in here 
TimeStamp=2018-02-28 20:17:27.5117 Callsite=AspNetCoreCustomLoggerAndNLogCallsiteIssue.Logger`1.Log Level=ERROR Message=Get method called error additional stuff in here 
TimeStamp=2018-02-28 20:17:27.5202 Callsite=AspNetCoreCustomLoggerAndNLogCallsiteIssue.Logger`1.Log Level=INFO Message=Get method called information additional stuff in here

After some digging, it turned out that the issue lies in the (indirect)configuration of NLog's callsite layout renderer. Long story short, when you add NLog provider to your logger providers, under the hood it adds Microsoft.Extensions.Logging.Abstractions assembly(among others) to something called hidden assembly collection. Once the NLog tries to figure out what is the caller member name, it crawls the stack trace to find a method name. If the method in current frame comes from a hidden assembly, logger skips it and continues iteration. As we changed the Logger<T> to our custom one, it is no longer part of Microsoft.Extensions.Logging.Abstractions assembly, so the NLog reports Log method from our custom logger as a caller member name.

4. The fix

In order to restore previous behavior you have to add custom logger assembly to the hidden assembly collection. You can do it via

LogManager.AddHiddenAssembly(typeof(Logger.Logger<>).Assembly);

Of course, if the logger is located in the same assembly as rest of your code, this might not be the perfect solution - as this will impact the way the callsite is rendered for other parts of your code in this assembly. In that case, you might consider moving the logging piece to separate assembly or resign from using callsite layout renderer at all. We decided to replace it with logger layout renderer as callsite layout renderer, either way, wouldn’t be used in production environments.

Source code for this post can be found here

ASP.NET Core - make sure IOptions is initialized

Mon, 29 Jan 2018 08:00:06 GMT

1. Introduction

As most people know IOptions<T> is a convenient way of handling configuration options in your application. Even though I've been using it for quite some time, last week I was unpleasantly surprised by a production bug caused by wrong usage of this mechanism.

2. Problem

Let's say we have a simple controller which depends on two instances of IOptions<T>

[Route("api/[controller]")]
public class ValuesController : Controller
{
    private readonly IOptions<PaymentOptions> _paymentOptions;
    private readonly IOptions<NotificationOptions> _notificationOptions;

    public ValuesController(IOptions<PaymentOptions> paymentOptions, IOptions<NotificationOptions> notificationOptions)
    {
        _paymentOptions = paymentOptions ?? throw new ArgumentNullException(nameof(paymentOptions));
        _notificationOptions = notificationOptions ?? throw new ArgumentNullException(nameof(notificationOptions));
    }

    // GET api/values
    [HttpGet]
    public IEnumerable<string> Get()
    {
        var notificationOptions = _notificationOptions.Value;
        var paymentOptions = _paymentOptions.Value;
            
        return new string[] {"value1", "value2"};
    }
}

Then we add only IOptions in Startup class - IOptions<PaymentOptoins>

public class Startup
{
    // Rest of the code omitted for brevity
    // This method gets called by the runtime. Use this method to add services to the container.
    public void ConfigureServices(IServiceCollection services)
    {
        services.AddOptions();
        services.AddMvc();
        services.Configure<PaymentOptions>(Configuration.GetSection("PaymentOptions"));
    }
      // Rest of the code omitted for brevity
}

Now, when we run the app and hit one of the endpoints in ValuesController I was expecting to get an exception, as I didn't register IOptions<NotificationOptions>. Surprisingly for me, the application was running normally and IOptions<NotificationOptions> was created with the new instance of NotificationOptions class(with all the properties defaulted).

In order to find out why it behaves like that we have to take a look how services responsible for handling IOptions<T> are registered in the container.

public static IServiceCollection AddOptions(this IServiceCollection services)
{
    if (services == null)
        throw new ArgumentNullException(nameof (services));

    services.TryAdd(ServiceDescriptor.Singleton(typeof (IOptions<>), typeof (OptionsManager<>)));
    services.TryAdd(ServiceDescriptor.Scoped(typeof (IOptionsSnapshot<>), typeof (OptionsManager<>)));
    services.TryAdd(ServiceDescriptor.Singleton(typeof (IOptionsMonitor<>), typeof (OptionsMonitor<>)));
    services.TryAdd(ServiceDescriptor.Transient(typeof (IOptionsFactory<>), typeof (OptionsFactory<>)));
    services.TryAdd(ServiceDescriptor.Singleton(typeof (IOptionsMonitorCache<>), typeof (OptionsCache<>)));
    return services;
}

As you can see AddOptions method registers open generics for (among others) IOptions<> which means that you don’t have to register specific types of IOptions<T>, however, you are responsible for its configuration with

services.Configure<T>(Configuration.GetSection("Section"));

I was always convinced that services.Configure registers and configure IOptions<T> but apparently, I was wrong.

3. Ensuring initialization

As these kind of errors are rather difficult to catch(at least in case of our application) I wanted to minimize the risk of doing the same bug again. The idea was to make sure that at least one IConfigureOptions<T> or IPostConfigureOptions<T> service is registered in the container (as these are the services which are responsible for setting the values of T class). My first approach was to replace default OptionsFactory<T> with a custom one

public class ValidatableOptionsFactory<TOptions> : OptionsFactory<TOptions> where TOptions : class, new()
{
    private static readonly string NamespacePrefix = typeof(Program).Namespace.Split('.').First();

    public ValidatableOptionsFactory(IEnumerable<IConfigureOptions<TOptions>> setups, IEnumerable<IPostConfigureOptions<TOptions>> postConfigures)
            : base(setups, postConfigures)
    {
        if (typeof(TOptions).Namespace.StartsWith(NamespacePrefix) && setups.Any() == false && postConfigures.Any() == false)
        {
            throw new InvalidOperationException($"No configuration options or post configuration options was found to configure {typeof(TOptions)}");
        }
    }
}

public class Startup
{      
    // This method gets called by the runtime. Use this method to add services to the container.
    public void ConfigureServices(IServiceCollection services)
    {
        services.AddTransient(typeof(IOptionsFactory<>), typeof(ValidatableOptionsFactory<>));
        services.AddOptions();
    }
}

This method works fine (although probably needs smarter TOptions filter)

however I got to conclusion that there is no point to do validation in a runtime, and the integration test might be a better choice. I came up with following code (I am assuming that all configuration options are stored in the same assembly, as this is convention in my project)

public class OptionsTests
{
    private readonly Lazy<IWebHost> _webHost = new Lazy<IWebHost>(Program.BuildWebHost(null));

    // this test will fail as not every option in assembly is configured
    [Fact]
    public void AllConfigurationOptions_HasConfigurationServicesDefined()
    {
        var optionsType = typeof(IOptions<>);
        var constructorParameterTypes = typeof(Program).Assembly.GetExportedTypes()
                .SelectMany(type => type.GetConstructors().SelectMany(ctor => ctor.GetParameters()))
                .Select(parameter => parameter.ParameterType);

        var optionValueTypes = constructorParameterTypes.Where(parameterType => IsAssignableToGenericType(parameterType, optionsType))
                .Select(options => options.GetGenericArguments().Single())
                .Distinct();
            
        var postConfigureOptionsType = typeof(IPostConfigureOptions<>);
        var configureOptionsType = typeof(IConfigureOptions<>);

        var postConfiguration = optionValueTypes.Select(type => new
        {
            optionsType = type,
            configureOptionsType = _webHost.Value.Services.GetServices(configureOptionsType.MakeGenericType(type)),
            postConfigureServices = _webHost.Value.Services.GetServices(postConfigureOptionsType.MakeGenericType(type))
        });

        var emptyConfigurations =
                postConfiguration.Where(item => item.configureOptionsType.Any() == false && item.postConfigureServices.Any() == false)
                    .Select(item => item.optionsType);

        emptyConfigurations.Should().BeEmpty("All options should be configured");
    }

    // https://stackoverflow.com/questions/74616/how-to-detect-if-type-is-another-generic-type/1075059#1075059
    public static bool IsAssignableToGenericType(Type givenType, Type genericType)
    {
        var interfaceTypes = givenType.GetInterfaces();

        if (interfaceTypes.Any(it => it.IsGenericType && it.GetGenericTypeDefinition() == genericType))
        {
            return true;
        }

        if (givenType.IsGenericType && givenType.GetGenericTypeDefinition() == genericType)
            return true;

        var baseType = givenType.BaseType;
        if (baseType == null) return false;

        return IsAssignableToGenericType(baseType, genericType);
    }
}

Running the test shows that NotificationOptions was not configured

Source code for this post can be found here

ASP.NET Core - passing command-line arguments to Startup class

Tue, 16 Jan 2018 09:00:24 GMT

1. Introduction

I usually pass configuration to my web API via JSON files, but recently I needed to pass them also via command-line arguments. As the solution for ASP.NET Core 2.x is quite different than for ASP.NET Core 1.x I decided to describe both methods in here.

2. ASP.NET Core 2.x

For the newest version of ASP.NET Core, the solution is pretty straightforward as IConfiguration is injected by default to the Startup class. All we have to do is to add CommandLineConfigurationSource to IConfigurationBuilder when configuring IWebHost. CommandLineConfigurationSource is part of the Microsoft.Extensions.Configuration.CommandLine package and can be easily used by AddCommandLine extension method

public class Program
{
    public static void Main(string[] args)
    {
        BuildWebHost(args).Run();
    }
	
    public static IWebHost BuildWebHost(string[] args)
    {
        var webHost = new WebHostBuilder()
	     .UseKestrel()
	     .UseContentRoot(Directory.GetCurrentDirectory())
	     .ConfigureAppConfiguration((hostingContext, config) =>
	     {
	         var env = hostingContext.HostingEnvironment;
	         config.AddJsonFile("appsettings.json", optional: true, reloadOnChange: true)
	               .AddJsonFile($"appsettings.{env.EnvironmentName}.json", optional: true, reloadOnChange: true);
	         config.AddEnvironmentVariables();
	         config.AddCommandLine(args);
	     }).UseStartup<Startup>()
	       .Build();
        return webHost;
    }
}

Now we can access our command-line arguments just like any other configuration

public class Startup
{
    private readonly IConfiguration _configuration;

    public Startup(IConfiguration configuration)
    {
        _configuration = configuration;
    }

    // This method gets called by the runtime. Use this method to add services to the container.
    public void ConfigureServices(IServiceCollection services)
    {
        services.AddMvc();
    }

    // This method gets called by the runtime. Use this method to configure the HTTP request pipeline.
    public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory, IApplicationLifetime applicationLifetime)
    {
        loggerFactory.AddConsole();
        loggerFactory.AddDebug();
        applicationLifetime.ApplicationStarted.Register(() => loggerFactory.CreateLogger<Startup>().LogInformation("CommandLine argument {0}: ", _configuration["usecustomschema"]));
        if (env.IsDevelopment())
        {
            app.UseDeveloperExceptionPage();
        }

        app.UseMvc();
    }
}

3. ASP.NET Core 1.x

The solution for ASP.NET Core 1.x requires a bit more work but it is possible to achieve the same result. We still will be using CommandLineConfigurationSource from Microsoft.Extensions.Configuration.CommandLine package, however this time we have to manually create IConfiguration object and register it in the container before the Startup class is created. This is possible because the WebHostBuilder exposes ConfigureServices method.

public class Program
{
    public static void Main(string[] args)
    {
        var host = new WebHostBuilder()
             .UseKestrel()
             .UseContentRoot(Directory.GetCurrentDirectory())
             UseIISIntegration()
             .ConfigureServices(serviceCollection =>
                 serviceCollection.AddSingleton<IConfiguration>(new ConfigurationBuilder().AddCommandLine(args).Build()))
             .UseStartup<Startup>()
             .Build();

          host.Run();
    }
}

Having our service registered now we can easily access IConfiguration object in our application

public class Startup
{
    // This method gets called by the runtime. Use this method to add services to the container.
    public void ConfigureServices(IServiceCollection services)
    {
        // Add framework services.
        services.AddMvc();
    }

    // This method gets called by the runtime. Use this method to configure the HTTP request pipeline.
    public void Configure(IApplicationBuilder app, IHostingEnvironment hostingEnvironment, IConfiguration configuration, ILoggerFactory loggerFactory, IApplicationLifetime applicationLifetime)
    {
        loggerFactory.AddConsole();
        loggerFactory.AddDebug();
        applicationLifetime.ApplicationStarted.Register(() =>
                loggerFactory.CreateLogger<Startup>().LogInformation("CommandLine argument {0}: ", configuration["usecustomschema"]));

        if (hostingEnvironment.IsDevelopment())
        {
            app.UseDeveloperExceptionPage();
        }

        app.UseMvc();
    }
}

Source code for this post can be found here

ASP.NET Core - retrieving swagger specification without hosting API

Mon, 08 Jan 2018 08:00:19 GMT

1. Introduction

I am currently exploring possible ways of removing a repetitive work when it comes to creating integration tests for our API. The one thing which usually takes some time when testing a new endpoint is a process of creating response and request classes (as we don't share the models between API project and integration test project). That is why I would like to have some kind of a tool (AutoRest or NSwag) which would do it for us (possibly, in a prebuild step). As those tools generate API clients based on swagger specification and I wanted this process to be as fast as possible I decided to figure out the way how to retrieve swagger specs without hosting the API.

2. Implementation

After taking a look at Swashbuckle.AspNetCore.Swagger source code it turned out that Swashbuckle.AspNetCore.Swagger.ISwaggerProvider is responsible for creating a SwaggerDocument class. JSON representation of that class is a swagger specification. Having all of that in mind I wrote following piece of code.

public class SchemaRetriever
{
    private readonly Lazy<IWebHost> _webHostProxy = new Lazy<IWebHost>(() => Program.BuildWebHost(new string[0]));

    private IWebHost WebHost => _webHostProxy.Value;
        
    public string RetrieveSchema(string swaggerDocument)
    {
        using (var scope = WebHost.Services.CreateScope())
        {
            var serviceProvider = scope.ServiceProvider;
            var swaggerProvider = serviceProvider.GetRequiredService<ISwaggerProvider>();
            var mvcJsonOptions = serviceProvider.GetRequiredService<IOptions<MvcJsonOptions>>();
            var document = swaggerProvider.GetSwagger(swaggerDocument, null, "/");

            var serializer = new JsonSerializer
                {
                    NullValueHandling = NullValueHandling.Ignore,
                    Formatting = mvcJsonOptions.Value.SerializerSettings.Formatting,
                    ContractResolver = new SwaggerContractResolver(mvcJsonOptions.Value.SerializerSettings)
                };

            using (var stringWriter = new StringWriter())
            {
                serializer.Serialize(stringWriter, document);
                return stringWriter.ToString();
            }   
        }
    }
}

public class Program
{
    public static void Main(string[] args)
    {
        BuildWebHost(args).Run();
    }

    public static IWebHost BuildWebHost(string[] args) =>
            WebHost.CreateDefaultBuilder(args)
                .UseStartup<Startup>()
                .Build();
}

The Program class is an entry point of the API. The only one difference compared to default ASP.NET Core template is the fact that I made the BuildWebHost method public. Thanks to that we can build the host (but without running) and get our hands on the DI container of our application. From that point the rest is easy, I retrieve the ISwaggerProvider from the container so I can get the swagger document for given id.

In order to make sure that the SchemaRetriever works as expected I wrote simple integration test which makes sure that swagger specs from hosted API is the same as the one retrieved without hosting.

[Fact]
public async Task RetrieveSchema_RetrievesSwaggerSchema_SameAsDeployedSchema()
{
    var swaggerSchemaWithoutHosting = _subject.RetrieveSchema(_swaggerDocumentName);
    using (var testServer = new TestServer(new WebHostBuilder().UseStartup<Startup>()))
    {
        using (var httpClient = testServer.CreateClient())
        {
            var response = await httpClient.GetAsync($"swagger/{EscapeDataString(_swaggerDocumentName)}/swagger.json");
            response.EnsureSuccessStatusCode();
            var content = await response.Content.ReadAsStringAsync();

            swaggerSchemaWithoutHosting.Should().Be(content);
        }
    }
}

Source code for this post can be found here

Null-propagation operator and conditional statements

Sun, 17 Dec 2017 15:23:23 GMT

This post is just a quick reminder for me to put a bit more attention to conditional statements combined with a null-propagation operator. Nothing too fancy but I tend to overlook this when doing code review. Starting from C# 6 we can simplify accessing members of an object which might be null thanks to ?. operator. For my perspective it is particularly useful within if statements, however, you have to be aware of how compiler rewrites the code under the hood otherwise, it is easy to introduce a bug. Consider following scenario

public Flight GetFirstPossibleFlight(Availability availability)
{
    if (availability.Flights?.Any() == false)
    {
       return null;
    }
            
    // more magic in here
     return availability.Flights.First();
}

At a glance everything seems to be ok, we make sure that Flight collection is not accessed if it is null, however simple test shows that this method has a bug.

[Fact]
public void GetFirstPossibleFlight_ReturnsNull_WhenFlightsCollectionIsEmpty()
{
    var availability = new Availability
    {
        Flights = null
    };
            
    var subject = new AvailabilityScanner();

    var result = subject.GetFirstPossibleFlight(availability);

    result.Should().BeNull();
}

We protected the code from NullReferenceException in if statement, however we failed on the return statement. This happens because our original code is rewritten by compiler as follows

public Flight GetFirstPossibleFlight(Availability availability)
{
    List<Flight> expr_07 = availability.Flights;
    bool flag = expr_07 != null && !expr_07.Any<Flight>();
    Flight result;
    if (flag)
    {
        result = null;
    }
    else
    {
        result = availability.Flights.First<Flight>();
    }
    return result;
}

Now it is clearly visible that we have to satisfy both of the conditions in order to return null. Fortunately, you still can use one-liner and have a bug-free code, the one thing which is needed is an additional null-coalescing operator in the if statement.

public Flight GetFirstPossibleFlight(Availability availability)
{            
    if ((availability.Flights?.Any() ?? false) == false)
    {
        return null;
    }
            
    // more magic in here
    return availability.Flights.First();
}

Now the compiler will rewrite the code in a following way

public Flight GetFirstPossibleFlight(Availability availability)
{
    List<Flight> expr_07 = availability.Flights;
    bool flag = expr_07 == null || !expr_07.Any<Flight>();
    Flight result;
    if (flag)
    {
        result = null;
    }
    else
    {
        result = availability.Flights.First<Flight>();
    }
    return result;
}

Notice that AND operator was replaced with OR operator, resulting in code safe from NullReferenceException. Source code for this post can be found here

ASP.NET Core MemoryCache - GetOrCreate calls factory method multiple times

Wed, 13 Dec 2017 21:57:20 GMT

Recently I've been trying to locate a performance issue in our application. Stress tests have shown an excessive usage of memory combined with too many external server requests. As usual in such cases, I've run the profiler and after a bit of searching, I've noticed that issue is connected with our caching mechanism. The problematic part was a factory delegate (responsible for populating cache, if the cache for given key is empty) which was called multiple times when concurrent requests were sent. That was a bit surprising to me as we basically were using a very naïve wrapper over ASP.NET Core MemoryCache.

public class CacheService : ICacheService
{
    private readonly IMemoryCache _memoryCache;

    public CacheService(IMemoryCache memoryCache)
    {
        _memoryCache = memoryCache ?? throw new ArgumentNullException(nameof(memoryCache));
    }

    public T GetOrAdd<T>(string cacheKey, Func<T> factory, DateTime absoluteExpiration)
    {
        return _memoryCache.GetOrCreate(cacheKey, entry =>
        {
            entry.AbsoluteExpiration = absoluteExpiration;
            return factory();
        });
    }
}

However simple test proved that this was an actual issue

[Fact]
public void GetOrAdd_CallsFactoryMethodOnce()
{
    var factoryMock = Substitute.For<Func<string>>();
    var optionsMock = Substitute.For<IOptions<MemoryCacheOptions>>();
    optionsMock.Value.Returns(callInfo => new MemoryCacheOptions());
    var memoryCache = new MemoryCache(optionsMock);

    var subject = new CacheService(memoryCache);

    var threads = Enumerable.Range(0, 10).Select(_ => new Thread(() => subject.GetOrAdd("key", factoryMock, DateTime.MaxValue))).ToList();
            
    threads.ForEach(thread => thread.Start());
    threads.ForEach(thread => thread.Join());

    factoryMock.Received(1)();
}

After doing a bit of a digging it turned out that this was by-design behavior, which is documented in the very end of official documentation . However, as this behavior wasn't the one we were expecting, we decided to reduce amount of factory calls by applying custom logic. We had couple of ideas when it comes to implementation, including:

Exclusive lock over factory method
Lock per key
Lock per type

After discussion we decided to go with third option, mainly because we didn't want to over-complicate the design, plus we wanted to allow concurrent factory method calls for different types of objects. Once CacheService was updated with following code

public class CacheService: ICacheService
{
    private readonly IMemoryCache _memoryCache;

    public CacheService(IMemoryCache memoryCache)
    {
        _memoryCache = memoryCache ?? throw new ArgumentNullException(nameof(memoryCache));
    }

    public T GetOrAdd<T>(string cacheKey, Func<T> factory, DateTime absoluteExpiration)
    {
        // locks get and set internally
        if (_memoryCache.TryGetValue<T>(cacheKey, out var result))
        {
            return result;
        }

        lock (TypeLock<T>.Lock)
        {
            if (_memoryCache.TryGetValue(cacheKey, out result))
            {
                return result;
            }

            result = factory();
            _memoryCache.Set(cacheKey, result, absoluteExpiration);

            return result;
         }
    }    

    private static class TypeLock<T>
    {
        public static object Lock { get; } = new object();
    }
}

we stoped experiencing excessive memory usage.

Source code for this post can be found here

Finding typos with ReSharper Command Line Tools, ReSpeller and Cake

Fri, 27 Oct 2017 08:06:04 GMT

1. Introduction

I tend to do a lot of typos when I write a code and I mean a lot. This is quite annoying for me so I decided to somehow automate the process of finding the spelling errors during the build. My first thought was to use some kind of Roslyn analyzer, however, I failed to find any working one. This is why I decided to give a try to ReSharper Command Line Tools (also known as CLIT) combined with ReSpeller plugin. For those who don't know, ReSharper Command Line Tools is set of tools which allow you to use ReSharper inspections without Visual Studio

2. First attempt

This was supposed to be a rather straightforward task because according to documentation command line inspections support extensions out of the box. The example presented in the help page was supposed to be the perfect one for me

InspectCode.exe --project=Documents -o="OutputFile.xml" --no-swea -x=EtherealCode.ReSpeller "SolutionFile.sln"

Unfortunately, it turned out that extensions support is broken for some time and it wasn't working for me either (tested on Command Line Tools version 2017.2).

3. The workaround

Even though extension support is not working as expected I was able to make it work with some workaround. The workaround itself is a combination of helpful tips taken from this YouTrack issue. Long story short, we have to manually install the plugin and then force ReSharper to use it. Assuming that you have command line tools installed this can be achieved in following way. First of all we have to get our hands on ReSpeller plugin. We can install it using NuGet but before you do it, remember to add additional feed to nuget.config file.

nuget sources add -name JetBrains-Feed -source https://resharper-plugins.jetbrains.com/api/v2/curated-feeds/Wave_v9.0/

The feed url can be found in the ReSharper's option page and for version 2017.2 it is

Having our NuGet sources updated we can retrieve the package using following command

nuget install "EtherealCode.ReSpeller" -Version "4.6.9.2"

The next step is to copy ReSpeller's DLLs from following folders

etherealcode.respeller.4.6.9.2\EtherealCode.ReSpeller\lib\net45\
etherealcode.respeller.4.6.9.2\Extended.Wpf.Toolkit\lib\net40\
etherealcode.respeller.4.6.9.2\NHunspell\lib\net\

directly to CLIT tools folder - JetBrains.ReSharper.CommandLineTools\tools. What is more, ReSpeller comes together with dictionary files which also have to be copied to the tools folder. This time, however, we have to copy entire etherealcode.respeller.4.6.9.2\EtherealCode.ReSpeller\lib\net45\dic directory, not only its content. The very last thing is to make ReSharper aware of the plugin, in order to do that we have to find EtherealCode.ReSpeller.JetMetadata.sstg file. The file itself doesn’t come together with the package but it is generated by ReSharper during plugin installation. So the easiest way of getting that file is to install ReSpeller as a ReSharper plugin in Visual Studio and then copy the sstg file to tools folder. After all that work now if you run

InspectCode.exe --project=Documents -o="OutputFile.xml" --no-swea -x=EtherealCode.ReSpeller "SolutionFile.sln"

(note lack of \-x switch) you will see spellcheck inspections in output file.

4. Cake integration

Doing all that stuff manually is error-prone and time-consuming and of course, I wanted to have the spellcheck up and running on the CI server, that is why I've also automated all above steps with Cake build script. The core concept is to use ReSpeller and ReSharper Command Line Tools as so-called "Cake tools" to run the inspections and Cake.Issues and Cake.Issues.InspectCode plugins for analyzing the output file. Adding tools and add-ins is straightforward we just have to add following lines on top of the build file.

#tool "nuget:?package=EtherealCode.ReSpeller&version=4.6.9.2"
#tool "nuget:?package=JetBrains.ReSharper.CommandLineTools&version=2017.2.2"
#addin "Cake.Issues"
#addin "Cake.Issues.InspectCode"

We also have to add nuget.config file to our build directory in order to point Cake to ReSharper feed (you could also modify the global nuget.config but I don’t want a build process to change the behavior of entire system)

<configuration>
    <packageSources>
      <add key="nuget.org" value="https://api.nuget.org/v3/index.json" protocolVersion="3" />
      <add key="resharper-plugins" value="https://resharper-plugins.jetbrains.com/api/v2/curated-feeds/Wave_v9.0/" protocolVersion="2" />
    </packageSources>
</configuration>

Before calling InspectCode.exe we have to make sure that all of the files and folders exist

var destinationPath = "tools/jetbrains.resharper.commandlinetools.2017.2.2/JetBrains.ReSharper.CommandLineTools/tools";
Setup(context =>
{
    if(!DirectoryExists(".artifacts"))
    {
        CreateDirectory(".artifacts");
    }

    if(!DirectoryExists(destinationPath + "/dic"))
    {
        CreateDirectory(destinationPath + "/dic");
    }
});
	
Task("Prepare-Respeller")
.Does(()=>
{
    // works for pinned version of ReSpeller
    var destinationPath = "tools/jetbrains.resharper.commandlinetools.2017.2.2/JetBrains.ReSharper.CommandLineTools/tools";
    CopyFiles("tools/etherealcode.respeller.4.6.9.2/EtherealCode.ReSpeller/lib/net45/*.dll", destinationPath);
    CopyFiles("tools/etherealcode.respeller.4.6.9.2/Extended.Wpf.Toolkit/lib/net40/*.dll", destinationPath);
    CopyFiles("tools/etherealcode.respeller.4.6.9.2/NHunspell/lib/net/*.dll", destinationPath);
    CopyFiles("../Spelling/*.dic",  destinationPath + "/dic");
    CopyFiles("../Spelling/*.aff",  destinationPath + "/dic"); // using shared dictionaries not the ReSpeller ones
    CopyFiles("EtherealCode.ReSpeller.JetMetadata.sstg", destinationPath);
});

Having all of the items in place now we are ready to run the actual spellcheck and verify the results

Task("Run-SpellCheck")
.IsDependentOn("Prepare-Respeller")
.Does(() =>
{
    var processArgumentBuilder = new ProcessArgumentBuilder().AppendSwitch("--profile","=","../Spelling/Resharper.ReSpeller.DotSettings")
                                          .AppendSwitch("--caches-home","=","tools")
                                          .AppendSwitch("-o","=","../.artifacts/inspectcode.xml")
                                          .Append("../ResharperCommandLineInspections.sln");

    var processSettings = new ProcessSettings 
    {
        Arguments = processArgumentBuilder,
        Silent = true,
        RedirectStandardOutput = true
    };

    IEnumerable<string> redirectedOutput, redirectedErrors;

    var exitCode = StartProcess(Context.Tools.Resolve("inspectcode.exe"), processSettings, out redirectedOutput, out redirectedErrors);
    if(exitCode !=0)
    {
        throw new CakeException($"InspectCode exited with unexpected error code: {exitCode}");
    }

    var issues = ReadIssues(InspectCodeIssuesFromFilePath("../.artifacts/inspectcode.xml"), "../");
    var spellingIssues = issues.Where(issue => issue.Rule.Contains("Typo")).ToList();

    if(spellingIssues.Any())
    {
        var errorMessage = spellingIssues.Aggregate(new StringBuilder(), (stringBuilder, issue) => stringBuilder.AppendFormat("FileName: {0} Line: {1} Message: {2}{3}", issue.AffectedFileRelativePath, issue.Line, issue.Message, Environment.NewLine));
        throw new CakeException($"{spellingIssues.Count} spelling errors detected: {Environment.NewLine}{errorMessage}please fix them or add missing words to the dictionary.");
    }
});

As you can see I start InspectCode.exe process with a bunch of parameters. Once the process returns successful exit code I can go ahead and process the results thanks to ReadIssues and InspectCodeIssuesFromFilePath methods provided by the add-ins. Because of the fact that ReSharper can produce a ton of inspections I only care about the ones which are typos. Simple and very naïve LINQ query can do it for me

var spellingIssues = issues.Where(issue => issue.Rule.Contains("Typo")).ToList();

If any typos were found I just throw exception with a listing of all the issues. Note that I aggregate all the issues into one big message because if you have lots of typos (just like I do) rendering them can take some time

The source code for slightly enhanced version of that script can be found here

ASP.NET Core 1.x - curios case of missing IOptions array item

Tue, 17 Oct 2017 08:00:08 GMT

1. Introduction

Last week while I was working on one of the features for my current project, I noticed quite surprising behavior of IOptions<T> object. Long story short, for some reasons there were missing array elements in my parsed application settings class.

2. Problem

Just like everyone else, we store our application settings in JSON file. The settings are pretty straightforward, just a bunch of properties with some nested objects

{
    "PaymentMethods": [
        {
            "Name": "MasterCard",
            "ExcludedCurrencies": []
        },
        {
            "Name": "Visa",
            "ExcludedCurrencies": null
        },
        {
            "Name": "Apple Pay"
        },
        {
            "Name": "PayPal",
            "ExcludedCurrencies": [
                "MAD"
            ]
        }
    ]
}

which are bound to the AppSetting class thanks to these couple of lines of code

// This method gets called by the runtime. Use this method to add services to the container.
public void ConfigureServices(IServiceCollection services)
{            
    services.Configure<AppSettings>(Configuration);
    // Add framework services.
    services.AddMvc();
}

where AppSettings class looks as follows

public class AppSettings
{
    public List<PaymentMethod> PaymentMethods { get; set; }
}

public class PaymentMethod
{
    public string Name { get; set; }

    public List<string> ExcludedCurrencies { get; set; }
}

As you can see nothing too fancy in here, standard ASP.NET Core approach for handling configuration files. However, if you access the PaymentMethods property of IOptions<AppSettings>

[Route("api/[controller]")]
public class ValuesController : Controller
{
    private readonly IOptions<AppSettings> _appSettings;

    public ValuesController(IOptions<AppSettings> appSettings)
    {
        _appSettings = appSettings;
    }
        
    // GET api/values
    [HttpGet]
    public List<PaymentMethod> Get()
    {
        return _appSettings.Value.PaymentMethods;
    }
}

you will see that instead of four elements we ended up having 3 items

as the Visa element is missing.

3. Solution

If you look closely at the appsettings.json file you will notice that a Visa item configuration is a bit different than the ones which are parsed just fine. Namely null is assigned to excludedCurrencies property, whereas in other items an empty array or no property at all is used. So the first fix is just to use the same approach as in the other items

{
    "Name": "Visa",
    "ExcludedCurrencies": []
}

This approach works fine, however, it is not a silver bullet as someone still might use null and introduce a bug. Another fix might be upgrading to ASP.NET Core 2.0 as the problem doesn’t seem to exist in there. Of course, this is rather a huge change so not everyone will be willing to do it. The last option is a manual installation of Microsoft.Extensions.Configuration.Binder 2.0 along with Microsoft.Extensions.Configuration.Json 2.0 package. However, this approach requires you to retarget your application to netcoreapp2.0. One way or another every solution in here works fine, so once you apply the fix you will see all items in the array

Source code for this post can be found here

.NET Core - calculating code coverage with OpenCover (on Windows)

Thu, 12 Oct 2017 08:00:27 GMT

1. Introduction.

I've been struggling for some time to make OpenCover work with .NET Core projects, so I've decided to document a working example. This is basically an aggregation of hints and answers I found on the Web (especially in here)

2. Working example.

If you run an OpenCover with the same arguments you were running it for a classic framework, you will end up with something like this

As you can see the coverage was not calculated and OpenCover is complaining about a missing PDBs. In order to fix that we have to do two things. First of all, we have to build the project with a full PDBs

dotnet build "PathToYourSolution.sln" /p:DebugType=Full

And then run OpenCover with and -oldStyle switch


OpenCover.Console.exe -target:"C:/Program Files/dotnet/dotnet.exe" -targetargs:"test \"PathToTestProject.csproj\" --configuration Debug --no-build" -filter:"+[*]* -[*.Tests*]*" -oldStyle -register:user -output:"OpenCover.xml"

From now on, OpenCover recognizes PDB files and the code coverage is calculated correctly

3. Cake script.

As we use a Cake as our build automation tool I've also prepared a sample script for generating a code coverage. The core part of the script looks as follows

// rest of the code omitted for brevity

Task("Build")
    .IsDependentOn("Restore-NuGet-Packages")
    .Does(() =>
{
    DotNetCoreBuild(paths.Files.Solution.ToString(), new DotNetCoreBuildSettings
    {
        Configuration = parameters.Configuration,
        ArgumentCustomization = arg => arg.AppendSwitch("/p:DebugType","=","Full")
    });
});

Task("Run-Tests")
    .IsDependentOn("Build")
    .Does(() =>
{
    var success = true;
    var openCoverSettings = new OpenCoverSettings
    {
        OldStyle = true,
        MergeOutput = true
    }
    .WithFilter("+[*]* -[*.Tests*]*");

    foreach(var project in paths.Files.TestProjects)
    {
        try 
        {
            var projectFile = MakeAbsolute(project).ToString();
            var dotNetTestSettings = new DotNetCoreTestSettings
            {
                Configuration = parameters.Configuration,
                NoBuild = true
            };

            OpenCover(context => context.DotNetCoreTest(projectFile, dotNetTestSettings), paths.Files.TestCoverageOutput, openCoverSettings);
        }
        catch(Exception ex)
        {
            success = false;
            Error("There was an error while running the tests", ex);
        }
    }

    ReportGenerator(paths.Files.TestCoverageOutput, paths.Directories.TestResults);

    if(success == false)
    {
        throw new CakeException("There was an error while running the tests");
    }

});

Notice that script is able to merge code coverage results from multiple test projects thanks to MergeOutput flag passed to OpenCover.

Full sources of that script (along with a dotnet vstest alternative approach) can be found here.

ASP.NET Core – request serialization issues after migration from classic WebApi

Mon, 21 Aug 2017 10:00:49 GMT

We've been migrating a classic WebApi application into the ASP.NET Core API for quite a while now, and last week we decided to deploy it on the test environment and try to run a website against it. We were pretty confident about the quality of a migration because all of the integration tests from old API were green when running against a new one. We were expecting maybe some business logic bugs but from our perspective, the infrastructure part was good to go. Unfortunately, when the QA's run the selenium test suite they quickly found a major issue in our codebase. They basically were getting HTTP 500 errors indicating a NullReferenceException. That was pretty surprising to us and after a bit of a digging we found following lines in the logs

TimeStamp=2017-08-20 00:43:49.4383 TraceId=0HL77AF0N305P Level=DEBUG Message=JSON input formatter threw an exception. Newtonsoft.Json.JsonSerializationException: Error converting value {null} to type 'System.Int32'. Path 'PassengerNumber', line 2, position 26. ---> System.InvalidCastException: Null object cannot be converted to a value type.
   at System.Convert.ChangeType(Object value, Type conversionType, IFormatProvider provider)
   at Newtonsoft.Json.Serialization.JsonSerializerInternalReader.EnsureType(JsonReader reader, Object value, CultureInfo culture, JsonContract contract, Type targetType)
   --- End of inner exception stack trace ---
   at Newtonsoft.Json.Serialization.JsonSerializerInternalReader.EnsureType(JsonReader reader, Object value, CultureInfo culture, JsonContract contract, Type targetType)
   at Newtonsoft.Json.Serialization.JsonSerializerInternalReader.CreateValueInternal(JsonReader reader, Type objectType, JsonContract contract, JsonProperty member, JsonContainerContract containerContract, JsonProperty containerMember, Object existingValue)
   at Newtonsoft.Json.Serialization.JsonSerializerInternalReader.SetPropertyValue(JsonProperty property, JsonConverter propertyConverter, JsonContainerContract containerContract, JsonProperty containerProperty, JsonReader reader, Object target)
   at Newtonsoft.Json.Serialization.JsonSerializerInternalReader.PopulateObject(Object newObject, JsonReader reader, JsonObjectContract contract, JsonProperty member, String id)

this was resulting in a null request in controller's application

As you can see JSON serializer was not able to convert null into the int. We double checked the requests coming from front-end and this is how one of them looked like

{
   "PassengerNumber": null,
   "PassengerType": "2"
}

whereas corresponding request class on the server side was written in following way

public class CreatePassengerRequest
{
    public int PassengerNumber { get; set; }
        
    public int PassengerType { get; set; }
}

Clearly front-end shouldn't be sending a null as a PassengerNumber however the same request was serialized just fine when running against classic WebApi

Fortunately the fix for that was pretty straightforward. All we had to do was to configure JSON serializer to ignore null values.

// This method gets called by the runtime. Use this method to add services to the container.
public void ConfigureServices(IServiceCollection services)
{
    services.AddMvc().AddJsonOptions(options =>
    {
        options.SerializerSettings.NullValueHandling = NullValueHandling.Ignore;
    });
}

From now on we were able to properly serialize the request

Source code for this post can be found here

NLog.Web.AspNetCore - make sure you add error message for logging exception

Sun, 09 Jul 2017 10:10:34 GMT

I've been using NLog for quite some time already, and it was a natural choice to use it in the ASP.NET Core projects as well. I've configured the logger using this tutorial and everything seemed to be working fine. Unfortunately, after some time we've noticed that for some reasons some of the errors are not logged. We've taken a deeper look at our code base and we've found couple logs being written as follows

_logger.LogError(exception.HResult, exception, string.Empty); 
_logger.LogCritical(exception.HResult, exception, string.Empty);

This piece of code works perfectly fine with ASP.NET Core console logger but it seems it doesn’t for NLog. We double checked that with following piece of code

[Route("api/[controller]")]
public class ValuesController : Controller
{
    private readonly ILogger<ValuesController> _logger;
        
    public ValuesController(ILogger<ValuesController> logger)
    {
        _logger = logger;
    }

    // GET api/values
    [HttpGet]
    public IEnumerable<string> Get()
    {
        var exception = new Exception();
        _logger.LogTrace("Log trace");
        _logger.LogDebug("Log debug");
        _logger.LogInformation("Log information");
        _logger.LogWarning("Log warning");
        _logger.LogError(exception.HResult, exception, string.Empty); // this one will not be logged
        _logger.LogCritical(exception.HResult, exception, string.Empty); // this one will not be logged as well            

        return new string[] {"value1", "value2"};
    }
}

And as you can see in the picture below, no errors have been reported

Changing the error message to any message (even the one containing only white spaces)

 _logger.LogError(exception.HResult, exception, " "); 
 _logger.LogCritical(exception.HResult, exception, " " );

fixed the problem.

That looks like a bug for me, so I will create a PR with the fix and see if that will make its way to the master

As usual, the source code for this post can be found on my GitHub

XUnit - MemberDataAttribute and generic type inheritance

Mon, 19 Jun 2017 20:21:14 GMT

1. Introduction.

When I was writing Cake.Intellisense I was playing a lot with Roslyn syntax rewriters. The one thing which was pretty important for me at this time was a reliable set of tests which can quickly show if rewritten code is valid C# code and if it matches my expectations. As I don’t like to repeat my code I wanted to have a base test class which can be provided with different test cases from inherited classes. The initial implementation looked as follows

public abstract class CSharpSyntaxRewriterTest<T> where T : CSharpSyntaxRewriter
{
    public static IEnumerable<object[]> TestCases { get; set; }
    protected T Subject { get; }

    private readonly NSubstituteAutoMocker<T> _autoMock;
    
    protected CSharpSyntaxRewriterTest()
    {
        _autoMock = new NSubstituteAutoMocker<T>();
        Subject = _autoMock.ClassUnderTest;
    }

    [Theory]
    [MemberData(nameof(TestCases))]
    public void Verify(SyntaxRewriterTestCase testCase)
    {
        var inputTree = SyntaxFactory.ParseSyntaxTree(testCase.Input);
        var result = Subject.Visit(inputTree.GetRoot());

        inputTree.GetDiagnostics().Should().BeEmpty();
        result.GetDiagnostics().Should().BeEmpty();
        result.ToFullString().Should().Be(testCase.ExpectedResult);
    }
}

As you can see I have a generic base test class which holds test cases in a static field TestCases. The field is static as it is required by XUnit, this solution is perfectly valid because a static field is shared across all instances of the same type. Having a base test class ready I wanted to write a set of unit tests for following syntax rewriter

public class InternalToPublicClassModifierSyntaxRewriter : CSharpSyntaxRewriter
{ 
    public override SyntaxNode VisitClassDeclaration(ClassDeclarationSyntax node)
    {
        var internalModifierIndex = node.Modifiers.IndexOf(SyntaxKind.InternalKeyword);
            
        if (internalModifierIndex > -1)
        {
            var tokenInList = node.Modifiers[internalModifierIndex];
            var updatedModifiers = node.Modifiers.Replace(tokenInList,
                   SyntaxFactory.Token(SyntaxKind.PublicKeyword).WithLeadingTrivia(tokenInList.LeadingTrivia)
                        .WithTrailingTrivia(tokenInList.TrailingTrivia));

            node = node.WithModifiers(updatedModifiers);
         }

         return base.VisitClassDeclaration(node);
    }
}

The rewriter shown above is a very simple piece of code which replaces internal class modifier with a public one. Writing the tests for that class was supposed to be very easy, I just had to provide test cases with input code and expected result.

public class InternalToPublicClassModifierSyntaxRewriterTests
        : CSharpSyntaxRewriterTest<InternalToPublicClassModifierSyntaxRewriter>
{
    static InternalToPublicClassModifierSyntaxRewriterTests()
    {
        TestCases = new[]
        {
            new[] { ReplacesInternalModifierWithPublic() },
            new[] { LeavesModifiersIntactWhenClassModifierPublic() },
            new[] { LeavesModifiersIntactWhenClassModifierProtected() }
        };
    }

    private static SyntaxRewriterTestCase ReplacesInternalModifierWithPublic()
    {
        return new SyntaxRewriterTestCase(nameof(ReplacesInternalModifierWithPublic), 
                "internal class Foo { }", "public class Foo { }");
    }

    private static SyntaxRewriterTestCase LeavesModifiersIntactWhenClassModifierPublic()
    {
        return new SyntaxRewriterTestCase(nameof(LeavesModifiersIntactWhenClassModifierPublic),
                "public class Foo { }", "public class Foo { }");
    }

    private static SyntaxRewriterTestCase LeavesModifiersIntactWhenClassModifierProtected()
    {
        return new SyntaxRewriterTestCase(nameof(LeavesModifiersIntactWhenClassModifierProtected),
                "protected class Foo { }", "protected class Foo { }");
    }
}

Unfortunately running the tests resulted in InvalidOperationException being thrown from XUnit

If you look closely at the message you will notice that the TestCases field used for providing data was not initialized, which means that the static constructor of class InternalToPublicClassModifierSyntaxRewriterTests was not run. That was pretty surprising for me that is why I wanted to investigated the issue a bit more.

2. Investigation.

I started from going back to the basics. As we probably all know, the static constructor is triggered when one of the following events occur:

An instance of the class type is created.
Any of the static members of the class type are referenced

The first condition is not met because instance of the test class is created after test cases are enumerated. That is why member data fields have to be a static fields/properties etc. When it comes to second condition the situation in here is a bit more complicated but if you take a look at the MemberDataAttributeBase class

public override IEnumerable<object[]> GetData(MethodInfo testMethod)
{
    Guard.ArgumentNotNull("testMethod", testMethod);

    var type = MemberType ?? testMethod.DeclaringType;
    var accessor = GetPropertyAccessor(type) ?? GetFieldAccessor(type) ?? GetMethodAccessor(type);
    // implementation omitted for brevity  
}

you will notice that member data looks for properties in DeclaringType of method. In my case declaring type is

XUnitMemberDataAndInheritance.CSharpSyntaxRewriterTest`1[[XUnitMemberDataAndInheritance.InternalToPublicClassModifierSyntaxRewriter]]

not

InternalToPublicClassModifierSyntaxRewriterTests

So when XUnit accesses TestCase property the static constructor from InternalToPublicClassModifierSyntaxRewriterTests class will not be called either as the types does not match.

3. Solution.

In order to bend the behavior of XUnit to my needs, I had to ensure that the static constructor from inherited class is called. Fortunately, workaround is pretty straightforward - I had to introduce a custom MemberDataAttribute which calls static constructor from ReflectedType manually

[DataDiscoverer("Xunit.Sdk.MemberDataDiscoverer", "xunit.core")]
[AttributeUsage(AttributeTargets.Method, AllowMultiple = true)]
public class CustomMemberDataAttribute : MemberDataAttributeBase
{
    public CustomMemberDataAttribute(string memberName, params object[] parameters)
            : base(memberName, parameters)
    {
    }

    public override IEnumerable<object[]> GetData(MethodInfo testMethod)
    {
        var type = MemberType ?? testMethod.ReflectedType;
        System.Runtime.CompilerServices.RuntimeHelpers.RunClassConstructor(type.TypeHandle);
        return base.GetData(testMethod);
    }

    protected override object[] ConvertDataItem(MethodInfo testMethod, object item)
    {
        if (item == null)
        {
            return null;
        }

        var array = item as object[];
        if (array == null)
        {
            throw new ArgumentException(
                    $"Property {MemberName} on {MemberType ?? testMethod.ReflectedType} yielded an item that is not an object[]");
        }
            return array;
    }
}

Now all I have to do is use newly created attribute in CSharpSyntaxRewriterTest test class

[Theory]
[CustomMemberData(nameof(TestCases))]
public void Verify(SyntaxRewriterTestCase testCase)
{
    // implementation omitted for brevity        
}

From now on all of the test cases will be run correctly

Source code for this post can be found here

NSubstitute - returning value from IEnumerable

Mon, 12 Jun 2017 11:35:02 GMT

I've been using NSubstitute combined with automocks for quite some time already, but recently I've encountered quite interesting situation. Let's assume that we have the following class we need to write tests for

public class PriceValidator : IValidator<Price>
{
    private readonly IEnumerable<IValidator<Price>> _innerValidators;

    public PriceValidator(IEnumerable<IValidator<Price>> innerValidators)
    {
         _innerValidators = innerValidators;
    }

    public bool IsValid(Price input)
    {
        return _innerValidators.Any() && _innerValidators.All(validator => validator.IsValid(input));
    }
}

As mentioned before I wanted to test that class leveraging the concept of automocks. If you have never used them before, no worries, the idea is pretty simple. Instead of providing mock dependencies manually, you just generate them automatically. Once the dependencies are mocked you can retrieve and set them up if necessary. So in my case, I have to setup IEnumerable<IValidator<Price>> mock so that it yields some values. It can be achieved by mocking return values of GetEnumerator() method.

var automock = new NSubstituteAutoMocker<PriceValidator>();
var innerValidators = new List<IValidator<Price>>
{
    Substitute.For<IValidator<Price>>(),
};            
automock.Get<IEnumerable<IValidator<Price>>>().GetEnumerator().Returns(innerValidators.GetEnumerator());

The entire test then can be written as

[Fact]
public void IsValid_ReturnsTrue_WhenAllInnerValidatorsAreValid()
{
    var automock = new NSubstituteAutoMocker<PriceValidator>();
    var innerValidators = new List<IValidator<Price>>
    {
        Substitute.For<IValidator<Price>>(),
    };
    innerValidators.ForEach(validator => validator.IsValid(Arg.Any<Price>()).Returns(true));
    automock.Get<IEnumerable<IValidator<Price>>>().GetEnumerator().Returns(innerValidators.GetEnumerator());
            
    var result = automock.ClassUnderTest.IsValid(new Price());

    innerValidators.ForEach(validator => validator.Received(1).IsValid(Arg.Any<Price>()));
    result.Should().BeTrue();
}

Everything looks good at that point, however if you run the tests, it will FailedTest

That was quite surprising for me and I have to admit that at the beginning I thought it was a bug in NSubstitute. However, if you looks closely at the implementation of the test, you will see that every time validator collection is enumerated, the same instance of the enumerator is used. As the enumerator keeps its state, the first enumeration (innerValidators.Any()) will move a current element to the first position (which is the last position at the same time) so when I try to enumerate again (innerValidators.All(validator => validator.IsValid(input)) enumeration will continue from the previous position and the iteration will end yielding no results. Fortunately, with NSubstitute you can configure the call so that it always returns a new value. The relevant code changes are shown below

automock.Get<IEnumerable<IValidator<Price>>>().GetEnumerator().Returns(callInfo => innerValidators.GetEnumerator());

Running the tests again will give us "green" result

Source code for this post can be found here

Dotnet CLI - running tests from multiple assemblies

Wed, 07 Jun 2017 19:33:16 GMT

When you start looking for information how to run unit tests for .NET Core based projects in the command line, you will most probably stumble upon dotnet CLI and its dotnet test command. The command works really great when you have just one test project in your solution, however, it doesn’t allow you to run tests from multiple projects at once. Of course, you can write little PowerShell which will run the command in the loop e.g.

Get-ChildItem | ? { $_.Name.Contains(".Tests.") } | ForEach-Object { Push-Location; Set-Location $_.Name; dotnet test; Pop-Location}

Unfortunately, in this case, you won't get an aggregated summary of tests results, instead, you will get a summary per test project.

Luckily dotnet CLI have another command for running tests - namely dotnet vstest. In this case, we do not operate on projects but we provide a location for assemblies with tests. So if you, for instance, would like to run unit and integration tests at once, you can write something like that

dotnet vstest .\DotnetCLIRunningTestsFromMultipleAssemblies.Tests.Integration\bin\Debug\netcoreapp1.1\DotnetCLIRunningTestsFromMultipleAssemblies.Tests.Integration.dll .\DotnetCLIRunningTestsFromMultipleAssemblies.Tests.Unit\bin\Debug\netcoreapp1.1\DotnetCLIRunningTestsFromMultipleAssemblies.Tests.Unit.dll

If you want a bit more flexible solution this simple PowerShell script will scan files and based on naming convention retrieve tests assemblies.

dotnet vstest (Get-ChildItem -recurse -File *.Tests.*dll | ? { $_.FullName -notmatch "\\obj\\?" })

One way or another, the dotnet vstest command will aggregate all of the test results and will present them as one summary.

One thing to note, dotnet vstest won't build the solution, you have to run the build manually with dotnet build command.

Source code for this post can be found here

ASP.NET Core - API versioning by convention

Thu, 04 May 2017 13:02:47 GMT

1. Introduction

If you were looking for information about API versioning support for ASP.NET Core you've probably come across Microsoft.AspNetCore.Mvc.Versioning library. The library itself allows you to set up versioning in a couple of different ways, for instance, via attributes or via manual convention setup. All of this options are really nice but unfortunately, they have one significant drawback, namely, you have to set them up manually. As I tend to forget about this kind of things I wanted to automate that process as much as possible. Thankfully ASP.NET Core has a very nice feature called ApplicationModelConventions which allows you to add some metadata(like routing information, API versioning ) to your controller, actions etc.

2. Convention

I've decided to implement versioning by routing which means the API will be accessible via this template

"v{version:apiVersion}/[controller]"

The template itself doesn’t give you much, as you also have to add information to the controllers which version of API they support. In my case, I decided to go with a version by namespace convention, which means that supported version will be deduced from namespace in which given controller resides. So, in fact, there will be two conventions, one for applying routing and a second one for applying versioning

3. Creating conventions.

In order to write an ASP.NET Core convention, we have to implement IApplicationModelConvention interface. This interface has a single method Apply which takes ApplicationModel class as an argument. This class gives us access to all of our controllers, actions and other parts of the application. So if we want to apply a routing with versioning for all of the controllers, we can do it in following way

public class ApiVersionRoutePrefixConvention : IApplicationModelConvention
{
    private readonly string _versionConstraintTemplate;
    private readonly string _versionedControllerTemplate;

    public ApiVersionRoutePrefixConvention()
    {
        _versionConstraintTemplate = "v{version:apiVersion}";
        _versionedControllerTemplate = $"{_versionConstraintTemplate}/[controller]";
    }

    public void Apply(ApplicationModel application)
    {
        foreach (var applicationController in application.Controllers)
        {
            foreach (var applicationControllerSelector in applicationController.Selectors)
            {
                if (applicationControllerSelector.AttributeRouteModel != null)
                {
                    var versionedConstraintRouteModel = new AttributeRouteModel
                    {
                        Template = _versionConstraintTemplate
                    };

                    applicationControllerSelector.AttributeRouteModel =
                            AttributeRouteModel.CombineAttributeRouteModel(versionedConstraintRouteModel,
                                applicationControllerSelector.AttributeRouteModel);
                }
                else
                {
                    applicationControllerSelector.AttributeRouteModel = new AttributeRouteModel
                    {
                        Template = _versionedControllerTemplate
                    };
                }
            }
        }
    }
}

As you can see we iterate through all of the Selectors and then apply new route model to them. If selector already had a route attribute applied we combine two attributes together. Once our convention is applied our actions will be accessible with following routing prefix

"v{version:apiVersion}/[controller]"

or via

"v{version:apiVersion}/previous_route_for_controller"

Having our routing ready now it is time to add versioning information to our controllers. Once again it will be done via application model convention. The version of the controller will be deduced from the namespace given controller is located in.

public class ApiVersionByNamespaceConvention : IApplicationModelConvention
{
    public void Apply(ApplicationModel application)
    {
        foreach (var controllerModel in application.Controllers)
        {
            var version = DeduceControllerVersion(controllerModel);
            var builder = new ControllerApiVersionConventionBuilder<ControllerModel>();
            builder.HasApiVersion(new ApiVersion(version, 0));
            builder.ApplyTo(controllerModel);
        }
    }

    private int DeduceControllerVersion(ControllerModel model)
    {
        // super trivial way of retrieving version number from namespace
        if (!int.TryParse(model.ControllerType.Namespace.Last().ToString(), out var version))
        {
            throw new InvalidOperationException("Unable to retrieve version information from namespace");
        }
        
        return version;
     }
}

As you can see I iterate through all of the controller models of our application, then check the version of controller based on its namespace and finally with

var builder = new ControllerApiVersionConventionBuilder<ControllerModel>();
builder.HasApiVersion(new ApiVersion(version, 0));
builder.ApplyTo(controllerModel);

I am able to inform the framework which version of API given controller supports.

4. Adding convention to application

Having all of our conventions prepared now we can enable versioning support

// Add framework services.
services.AddApiVersioning(options =>
{
    options.ReportApiVersions = true;
});

And of course, we have to add newly created conventions to list of application conventions

services.AddMvc(options =>
{
    options.Conventions.Remove<ApiVersionConvention>();
    options.Conventions.Remove<ImplicitControllerVersionConvention>();
    options.Conventions.Add(new ApiVersionRoutePrefixConvention());
    options.Conventions.Add(new ApiVersionByNamespaceConvention());
});

Note that I removed ApiVersionConvention and ImplicitControllerVersionConvention with simple extension method Remove<T>

public static class CollectionExtensions
{
    public static void Remove<T>(this IList<IApplicationModelConvention> conventionsCollection)
            where T : IApplicationModelConvention
    {
        var conventions = conventionsCollection.OfType<T>().ToList();

        foreach (var convention in conventions)
        {
            conventionsCollection.Remove(convention);
        }
    }
}

to make sure that only my convention is responsible for API versioning.

Source code for this post can be found here

ASP.NET Core - default API version with url path versioning

Wed, 03 May 2017 20:50:32 GMT

1. Introduction.

When you start versioning your API sometimes you want to have access to your endpoints without specifying version explicitly. Thanks to Microsoft.AspNetCore.Mvc.Versioning library this can be easily achieved with proper setup of configuration action. However, it turns out that in order to enable default API version for url path versioning, there are a couple additional steps to do.

2. Default `API` version without url path versioning

Let's start with the initial setup of API versioning which will work for every type of versioning apart from url path versioning. All you have to do is to assign an ApiVersionSelector and set the AssumeDefaultVersionWhenUnspecified property to true.

public void ConfigureServices(IServiceCollection services)
{
    // Add framework services.
    services.AddApiVersioning(options =>
    {
        options.ApiVersionReader = new QueryStringApiVersionReader();
        options.AssumeDefaultVersionWhenUnspecified = true;
        options.ApiVersionSelector = new CurrentImplementationApiVersionSelector(options);
    });
}

Now when the user will try to access the endpoint without specifying version explicitly the ApiVersionSelector will select proper version - in this case highest available version.

3. Default Api version with URL path versioning

Running the same configuration against controllers which are versioned via url path (not query string)

namespace AspNetCoreDefaultApiVersionAndRoutePrefix.Controllers.V1
{
    [Route("v{version:apiVersion}/[controller]")]
    [ApiVersion("1")]
    public class ValuesController : Controller
    {
        // GET api/values
        [HttpGet]
        public IEnumerable<string> Get()
        {
            return new string[] {"V1"};
        }
    }
}

namespace AspNetCoreDefaultApiVersionAndRoutePrefix.Controllers.V2
{
    [Route("v{version:apiVersion}/[controller]")]
    [ApiVersion("2")]
    public class ValuesController : Controller
    {
        // GET api/values
        [HttpGet]
        public IEnumerable<string> Get()
        {
            return new string[] {"V2"};
        }
    }
}

will result with 404 status code, as routing is not able to match the url.

Fortunately, unlike the ASP.NET Web API, ASP.NET Core allows us to have multiple route attributes applied to given controller, so in order to fix the issue we just have to add

[Route("[controller]")]

attribute to versioned controllers. From now on we can access our API without specifying version as well as with version specified.

4. Adding default route with convention

If you don’t want to specify default route manually for every controller, you can do it via application model convention. The interesting thing about it is the fact that apart from changing existing values of application model we can also add new items to it. This means that we can add additional SelectorModel with our default route to Selectors' collection

public class DefaultRoutePrefixConvention : IApplicationModelConvention
{
    public void Apply(ApplicationModel application)
    {
        foreach (var applicationController in application.Controllers)
        {
            applicationController.Selectors.Add(new SelectorModel
            {
                AttributeRouteModel = new AttributeRouteModel
                {
                    Template = "[controller]"
                }
            });
        }
    }
}

Now we can get rid of [Route("[controller]")] attribute from our versioned controllers and just rely on convention which can be added as follows

public void ConfigureServices(IServiceCollection services)
{
    // rest of the code omitted for brevity 
    services.AddMvc(mvc =>
    {
        mvc.Conventions.Add(new DefaultRoutePrefixConvention());
    });
}

Source code for this post can be found here

VS Code - forcing partial IntelliSense support for Cake scripts

Wed, 12 Apr 2017 22:39:44 GMT

1. Introduction

I've been using Cake for quite some time now, and I really like this tool, however the more complex my build scripts are, the more painful lack of IntelliSense is. Inspired a bit by this post, I decided to see what it takes to enable at least partial IntelliSense for Cake scripts in Visual Studio Code.

2. Investigation

The proper way of providing the code completion for Cake scripts would probably be a plugin to Omnisharp-Roslyn, as Cake script is basically a valid c# snippet. Unfortunately, at this moment Omnisharp-Roslyn doesn’t have plugin infrastructure ready, that is why I decided to go with a bit different path. As you might or might not be aware, VS Code already supports csx files, so if you add an empty project.json file (by empty I mean file with empty JSON object) to your build directory and change extension of your scripts to csx, you will immediately get a C# syntax highlighting and some IntelliSense support. Sadly this will not provide code completion for Cake method aliases. The reason why it fails on that is the fact that the Cake alias is ICakeContext extension method

[CakeMethodAlias]
public static T Argument<T>(this ICakeContext context, string name)

but you use it as it was written as

[CakeMethodAlias]
public static T Argument<T>(string name)

The Cake engine generates additional alias overloads during script compilation, and as these overloads exist only on runtime, VS Code just can't "see" them.

3. My approach

Having in mind the way Cake works I decided to write an application which would be able to take any Cake or Cake add-in and produce a library containing proper alias overloads. For instance, if original Cake method looks as follows

/// <summary>
/// Contains functionality related to arguments.
/// </summary>
[CakeAliasCategory("Arguments")]
public static class ArgumentAliases
{
    /// <summary>
    /// Determines whether or not the specified argument exist.
    /// </summary>
    /// <param name="context">The context.</param>
    /// <param name="name">The argument name.</param>
    /// <returns>Whether or not the specified argument exist.</returns>
    /// <example>
    /// This sample shows how to call the <see cref="HasArgument"/> method.
    /// <code>
    /// var argumentName = "myArgument";
    /// //Cake.exe .\hasargument.cake -myArgument="is specified"
    /// if (HasArgument(argumentName))
    /// {
    ///     Information("{0} is specified", argumentName);
    /// }
    /// //Cake.exe .\hasargument.cake
    /// else
    /// {
    ///     Warning("{0} not specified", argumentName);
    /// }
    /// 
    /// </example>
    [CakeMethodAlias]
    public static bool HasArgument(this ICakeContext context, string name)
    {
        // rest of the code omitted for brevity
    }
}```

the application will rewrite it into

```csharp
/// <summary>
/// Contains functionality related to arguments.
/// </summary>
[CakeAliasCategory("Arguments")]
public static class ArgumentAliasesMetadata
{
    /// <summary>
    /// Determines whether or not the specified argument exist.
    /// </summary>
    /// <param name="name">The argument name.</param>
    /// <returns>Whether or not the specified argument exist.</returns>
    /// <example>
    /// This sample shows how to call the <see cref="HasArgument"/> method.
    /// <code>
    /// var argumentName = "myArgument";
    /// //Cake.exe .\hasargument.cake -myArgument="is specified"
    /// if (HasArgument(argumentName))
    /// {
    ///     Information("{0} is specified", argumentName);
    /// }
    /// //Cake.exe .\hasargument.cake
    /// else
    /// {
    ///     Warning("{0} not specified", argumentName);
    /// }
    /// 
    /// </example>
    public static bool HasArgument(string name)
    {
        return default(bool);
    }
}

The algorithm looks more or less like that

Retrieve Cake or Cake add-in via NuGet
Scan an assembly and find all classes containing alias methods
Use CSharpCodeGenerationService to generate metadata for Cake alias methods
Parse generated code with Roslyn and produce SyntaxTree
Append Metadata suffix to classes containing alias method
Remove ICakeContext parameter from alias method
Generate dummy body for methods which require that (methods which have return type or which have out parameters)
Update xml documentation
Compile generated code and produce dll

There is no point of doing more detailed description in here so if you want to take a closer look here is source code.

4. Generating metadata libraries

Before we start "hacking" VS Code to have IntelliSense, we have to prepare metadata libraries which will contain all necessary Cake alias overloads. In order to do that grab the application from NuGet and generate Cake.Common and Cake.Core metadata libraries. The simplest way of doing it is to run these commands

Cake.Intellisense.exe --Package Cake.Common --PackageVersion 0.19.2 --TargetFramework .NETFramework,Version=v4.5 --OutputFolder C:\Output
	
Cake.Intellisense.exe --Package Cake.Core --PackageVersion 0.19.2 --TargetFramework .NETFramework,Version=v4.5 --OutputFolder C:\Output

As a result, the application will produce following files:

Cake.CommonMetadata.dll
Cake.CommonMetadata.xml
Cake.CoreMetadata.dll
Cake.CoreMetadata.xml

5. Enabling `IntelliSense` in `VS Code`

Having our metadata libraries prepared now we can adjust our build scripts to have code completion in VS Code. Here are the steps:

Add project.json file with empty JSON object into your build directory.
Change extension of all your build scripts to csx.
Copy metadata libraries into your Build directory.
Create imports.csx file. This is the file which contains all original namespace imports. It may look as follows
```
#load "./metadataImports.csx"
using Cake.Core;
using Cake.Core.IO;
// rest of imports
```
Create metadataimports.csx file. This is the file which contains metadata namespaces imports and loads Cake and metadata references.
```
#r "./tools/Cake/Cake.Core.dll"
#r "./tools/Cake/Cake.Common.dll"
#r "./tools/Cake.Metadata/Cake.Core.Metadata.dll"
#r "./tools/Cake.Metadata/Cake.Common.Metadata.dll"
using static Cake.Common.ArgumentAliasesMetadata;
using static Cake.Common.EnvironmentAliasesMetadata;
// rest of imports 
```
Each original Cake alias class has corresponding metadata class with Metadata suffix, for instance Cake.Common.ArgumentAliases -> Cake.Common.ArgumentAliasesMetadata Cake.Common.EnvironmentAliases -> Cake.Common.EnvironmentAliasesMetadata
Load imports.csx to your build.csx file via
```
#load "./imports.csx"    
```
Run VS Code install ms-vscode.csharp 1.7.0, open Build directory and write your build script with IntelliSense support

Before running the script remember to comment out
```
#load "./metadataImports.csx"
```
from imports.csx file

Run the build

build.ps1 -script build.csx -target Your-Target

I do realize this is quite convoluted explanation so in case of any troubles take a look at my build

6. Known issues

Cake.Intellisense can only generate metadata libraries for a standard .NET frameworks, it will fail if you try to create metadata targeting .NETStandard or .NET Core framework
Due to some breaking changes in Omnisharp-Roslyn scripting support, IntelliSense will only work with Omnisharp 1.7.0

7. Summary

This approach is just a temporary solution. As you can see, it requires significant amount of work to have a code completion in VS Code. I believe that once Omnisharp-Roslyn has proper plugin support it should be possible to write some kind of custom IntelliSense provider for Cake scripts. There are already people who forked Omnisharp-Roslyn and play around with that, so we just have to wait for something better than this solution.

Downgrading Visual Studio Code extension

Sun, 09 Apr 2017 17:56:34 GMT

1. Introduction

For time to time when you update Visual Studio Code's extension you realize that there were some breaking changes you don’t like or the extension has a bug which prevents you from using it. Usually, in this kind of situations, you would like to just go back to the version you were using previously rather than stop using the extension at all. Unfortunately, VSCode doesn’t give us an option to install a specific version of the extension for now. Luckily there is an easy way of doing that manually.

2. Installation

Let's assume that I would like to downgrade C# plugin from newest version (1.8.1 at the moment) to 1.7.0. First of all, we have to uninstall current extension. As there as some issues of doing that via command line, just do it from VSCode by clicking on uninstall button in extension screen.

In the next step we have to download proper extension's version using vsassets api. The url pattern looks as follows

https://${publisher}.gallery.vsassets.io/_apis/public/gallery/publisher/${publisher}/extension/${extension_name}/${version}/assetbyname/Microsoft.VisualStudio.Services.VSIXPackage

In my case, the variables looks as follow

${publisher} - ms-vscode
${extension_name} - csharp
${version} - 1.7.0

and entire url can be rewritten as

https://ms-vscode.gallery.vsassets.io/_apis/public/gallery/publisher/ms-vscode/extension/csharp/1.7.0/assetbyname/Microsoft.VisualStudio.Services.VSIXPackage

Having the link prepared we can paste it into browser address bar and download the extension. Once the file is downloaded, run VSCode, hit CTRL+SHIFT+P, type vsix in command line and choose

Extensions: Install from VSIX...

Select the file you've just downloaded and restart editor after installation. From now on you can use older version of your favorite extension.

Asp.NET Core - populating IOptions from external data source

Sun, 26 Feb 2017 22:56:52 GMT

1. Introduction

In ASP.NET Core web.config is no longer a proper place for storing application settings. New framework introduces the concept of a json based configuration and the default file which stores the settings now is appsettings.json. Here is a quick tutorial how to use new features.

2. Reading configuration

Let's assume that our appsettings.json file looks as follows.

{
    "Logging": {
        "IncludeScopes": false,
        "LogLevel": {
            "Default": "Debug",
            "System": "Information",
            "Microsoft": "Information"
        }
    },
    "AvailabilitySearchOptions": {
        "FlexDaysIn": 2,
        "FlexDaysOut": 3
    }
}

Thanks to ConfigurationBuilder we can parse this config and later on materialize sections or entire file into strongly typed configuration classes. Let's say we want to parse AvailabilitySearchOptions node to following class

public class AvailabilitySearchOptions
{
    public int FlexDaysIn { get; set; }

    public int FlexDaysOut { get; set; }

    public TimeSpan MinimumConnectionTime { get; set; }

    public TimeSpan MinimumDepartureTime { get; set; }
}

We can achieve that with following steps. First of all, we need to read entire configuration

public IConfigurationRoot Configuration { get; }

public Startup(IHostingEnvironment env)
{
    var builder = new ConfigurationBuilder()
                        .SetBasePath(env.ContentRootPath)
                        .AddJsonFile("appsettings.json", optional: true, reloadOnChange: true)
                        .AddJsonFile($"appsettings.{env.EnvironmentName}.json", optional: true)
                        .AddEnvironmentVariables();
    Configuration = builder.Build();
}

And in the next step we have to register IOptions<AvailabilitySearchOptions> in the container using services.Configure<TOptions>(IConfiguration section) method


// This method gets called by the runtime. Use this method to add services to the container.
public void ConfigureServices(IServiceCollection services)
{
    // Add framework services.
    services.AddMvc();
    services.Configure<AvailabilitySearchOptions>(Configuration.GetSection("AvailabilitySearchOptions"));  
}

Note Configuration.GetSection("AvailabilitySearchOptions") passed as argument to services.Configure method. From now on we can access AvailabilitySearchOptions settings via IOptions<AvailabilitySearchOptions> interface, which you can easily inject into your classes.


[Route("api/[controller]")]
public class OptionsController : Controller
{
    private readonly IOptions<AvailabilitySearchOptions> availabilitySearchOptions;

    public OptionsController(IOptions<AvailabilitySearchOptions> availabilitySearchOptions)
    {
        this.availabilitySearchOptions = availabilitySearchOptions;
    }

    public AvailabilitySearchOptions Get()
    {
        return availabilitySearchOptions.Value;
    }
}

3. Populating `IOptions<T>` from external data source

From time to time, reading configuration just from JSON file might not be enough and for instance you would like to add additional configuration read from some external data source. Fortunately you don't have to resign from the IOptions<T> class as it is possible to read additional data for literally any other source thanks to IConfigureOptions<T> class. All we have to do is to create a setup class which implements IConfigureOptions<T> interface


public class AvailabilitySearchOptionsSetupService : IConfigureOptions<AvailabilitySearchOptions>
{
    private readonly ILogger<AvailabilitySearchOptionsSetupService> logger;
    private readonly IReservationSettingsService reservationSettingsService;
	
    public AvailabilitySearchOptionsSetupService(ILogger<AvailabilitySearchOptionsSetupService> logger ,IReservationSettingsService reservationSettingsService)
    {
        this.logger = logger;
        this.reservationSettingsService = reservationSettingsService;
    }
	
    public void Configure(AvailabilitySearchOptions options)
    {
        this.logger.LogInformation($"Calling first {typeof(IConfigureOptions<AvailabilitySearchOptions>)} service");
        options.MinimumConnectionTime = reservationSettingsService.GetMinimumConnectionTime();
    }
}

And then registering this class in our container


// This method gets called by the runtime. Use this method to add services to the container.
public void ConfigureServices(IServiceCollection services)
{
    // Add framework services.
    services.AddMvc();
    services.Configure<AvailabilitySearchOptions>(Configuration.GetSection("AvailabilitySearchOptions"));
    services.AddSingleton<IConfigureOptions<AvailabilitySearchOptions>, AvailabilitySearchOptionsSetupService>();
}

From now on, when value of IOptions<AvailabilitySearchOptions> is accessed for very first time, Configure method from AvailabilitySearchOptionsSetupService will be called and you will be able to set additional values for your settings. Note that values from appsettings.json will already be there. In addition, it is possible to have multiple implementations of IConfigureOptions<T> so if you want your setup to be split into multiple classes you are good to go.

Source code for this post can be found here

XUnit - sharing test data across assembly

Sun, 19 Feb 2017 14:02:19 GMT

1. Introduction

XUnit provides two ways of sharing data between tests - ICollectionFixture and IClassFixture. The first one allows you to shared context across collections and the second one across test classes. I've already had a couple of cases in which these fixtures were not enough. Basically, I wanted to share data between all tests in given assembly - without worrying in which test class or test collection given test is. In these circumstances, I've usually used some kind of old fashioned singleton or custom TestFrameworkExecutor. I've never liked those solutions, fortunately recently I've come across a nice little library - xunit.assemblyfixture.

2. Usage

Xunit.assemblyfixture allows you to share data between tests in given assembly via IAssemblyFixture interface. The usage is basically the same as in other XUnit's fixtures. All we have to do is to create a class which instance we want to share with other tests

public class TestFixture : IDisposable
{
    public static int InitializationCounter { get; private set; }

    public TestFixture()
    {
        InitializationCounter++;
    }

    public void Dispose()
    {
        // free resources if necessary
    }
}

And then create test classes which implement IAssemblyFixture interface. If we want to have access to the fixture from the tests, we can inject instance of TFixture via constructor

public class TestBase : IAssemblyFixture<TestFixture>
{
    protected readonly ITestOutputHelper TestOutputHelper;
    protected readonly TestFixture Fixture;

    protected TestBase(ITestOutputHelper testOutputHelper, TestFixture fixture)
    {
        this.TestOutputHelper = testOutputHelper;
        this.Fixture = fixture;
    }

    protected void DisplayInitializationCount()
    {
        TestOutputHelper.WriteLine($"Initialization count: {TestFixture.InitializationCounter}");
    }
}

Xunit.assemblyfixture fixture will ensure that given test class is shared via all the tests and is initialized only once.

If you want to share multiple classes across the assembly, you can, of course, use IAssemblyFixture multiple times.

3. Visual Studio 2017 - XUnit beta tests runners

As for now VS 2017 RC requires beta runners of XUnit in order to run our unit tests. xunit.assemblyfixture seems not to cooperate with them smoothly. However, there is a simple workaround to fix that. All we have to do is to add the following attribute to our test project

[assembly: TestFramework("Xunit.TestFramework", "xunit.assemblyfixture")]

And from now on, XUnit correctly can inject assembly fixtures into our test classes

Source code for this post can be found here

ASP.NET Core - tracking flow of requests with NLog

Sat, 18 Feb 2017 14:11:18 GMT

1. Introduction

A while ago I wrote an article about using MappedDiagnosticsLogicalContext for tracking request flow in your application. As we are moving our project to ASP.NET Core, I wanted to keep that functionality in place. Unfortunately, MDLC layout renderer is not available in that framework anymore(when targeting .NET Core). Luckily, there are two other renderers which can be used as a replacement:

aspnet-traceidentifier
aspnet-item

2. Configuring NLog

Before I dig into details of layout renderers mentioned above, we have to configure ASP.NET Core to use NLog as a logger. First of all, we need to grab NLog.Web.AspNetCore NuGet package. Once the package is installed we have to manually add NLog.config to the project (the file won't be added automatically by NuGet installer). The next step is to configure NLog with our config, then configure NLogWeb and finally register NLog in LoggingFactory. All of these steps should be done in Startup class.

public class Startup
{
    public Startup(IHostingEnvironment env)
    {
        // rest of the code omitted for brevity
        env.ConfigureNLog("NLog.config");
        // rest of the code omitted for brevity
    }
	
    // This method gets called by the runtime. Use this method to configure the HTTP request pipeline.
    public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory)
    {
        // rest of the code omitted for brevity
        loggerFactory.AddNLog();
        app.AddNLogWeb();
        // rest of the code omitted for brevity
    }
}

The final step required for NLog to work is to register HttpContextAccessor in IoC container of your choice. If you use the build one, you can do it like that

public class Startup
{
    // rest of the code omitted for brevity
    public void ConfigureServices(IServiceCollection services)
    {
        services.AddSingleton<IHttpContextAccessor, HttpContextAccessor>();
    }
    // rest of the code omitted for brevity
}

3. Using aspnet-traceidentifier renderer

Aspnet-traceidentifier layout renderer allows you to obtain value of TraceIdentifier property from current HttpContext. TraceIdentifier is basically unique id which identifies the request. The renderer can be used as follows

<?xml version="1.0" encoding="utf-8" ?>
	<nlog xmlns="http://www.nlog-project.org/schemas/NLog.xsd"
	      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	      autoReload="true">
	
	  <extensions>
	    <add assembly="NLog.Web.AspNetCore"/>
	  </extensions>
	  
	  <targets>
	    <target xsi:type="File" name="File" fileName="${basedir}/logs/${shortdate}.log"
	            layout="TimeStamp=${longdate} Level=${uppercase:${level}} TraceId=${aspnet-traceidentifier} Message=${message}" />
	  </targets>
	   
	  <rules>
	    <logger name="*" minlevel="Debug" writeTo="File" />
	  </rules>
</nlog>

From now on (without any additional configuration) every log entry logged (once HttpContext is created), will contain TraceIdentifier.

TimeStamp=2017-02-15 23:10:52.1901 Level=INFO TraceId=0HL2LTTU3JVBI Message=Request starting HTTP/1.1 GET http://localhost:50334/api/values  
TimeStamp=2017-02-15 23:10:52.1941 Level=DEBUG TraceId=0HL2LTTU3JVBI Message=Request successfully matched the route with name '' and template 'api/Values'.
TimeStamp=2017-02-15 23:10:52.1941 Level=DEBUG TraceId=0HL2LTTU3JVBI Message=Action 'AspNetCoreLoggingWithCorrelationId.Controllers.ValuesController.Post (AspNetCoreLoggingWithCorrelationId)' with id 'a133346a-a8f9-4182-ac10-efa1afb18c4d' did not match the constraint 'Microsoft.AspNetCore.Mvc.Internal.HttpMethodActionConstraint'
TimeStamp=2017-02-15 23:10:52.1941 Level=DEBUG TraceId=0HL2LTTU3JVBI Message=Executing action AspNetCoreLoggingWithCorrelationId.Controllers.ValuesController.Get (AspNetCoreLoggingWithCorrelationId)
TimeStamp=2017-02-15 23:10:52.2091 Level=INFO TraceId=0HL2LTTU3JVBI Message=Executing action method AspNetCoreLoggingWithCorrelationId.Controllers.ValuesController.Get (AspNetCoreLoggingWithCorrelationId) with arguments () - ModelState is Valid
TimeStamp=2017-02-15 23:10:52.2091 Level=INFO TraceId=0HL2LTTU3JVBI Message=Get method requested
TimeStamp=2017-02-15 23:10:52.2091 Level=INFO TraceId=0HL2LTTU3JVBI Message=Log from Get action, from thread=4
TimeStamp=2017-02-15 23:10:52.2271 Level=INFO TraceId=0HL2LTTU3JVBI Message=Log from Get, from thread 3 assigned by scheduler
TimeStamp=2017-02-15 23:10:52.2271 Level=INFO TraceId=0HL2LTTU3JVBI Message=Log from Get action, from async continuation, from thread 3
TimeStamp=2017-02-15 23:10:52.2422 Level=INFO TraceId=0HL2LTTU3JVBI Message=Log from Get action, from explicitly created thread 15
TimeStamp=2017-02-15 23:10:52.3212 Level=DEBUG TraceId=0HL2LTTU3JVBI Message=Executed action method AspNetCoreLoggingWithCorrelationId.Controllers.ValuesController.Get (AspNetCoreLoggingWithCorrelationId), returned result Microsoft.AspNetCore.Mvc.ObjectResult.
TimeStamp=2017-02-15 23:10:52.3212 Level=DEBUG TraceId=0HL2LTTU3JVBI Message=No information found on request to perform content negotiation.
TimeStamp=2017-02-15 23:10:52.3322 Level=DEBUG TraceId=0HL2LTTU3JVBI Message=Selected output formatter 'Microsoft.AspNetCore.Mvc.Formatters.JsonOutputFormatter' and content type 'application/json' to write the response.
TimeStamp=2017-02-15 23:10:52.3322 Level=INFO TraceId=0HL2LTTU3JVBI Message=Executing ObjectResult, writing value Microsoft.AspNetCore.Mvc.ControllerContext.
TimeStamp=2017-02-15 23:10:52.3492 Level=INFO TraceId=0HL2LTTU3JVBI Message=Executed action AspNetCoreLoggingWithCorrelationId.Controllers.ValuesController.Get (AspNetCoreLoggingWithCorrelationId) in 140.4884ms
TimeStamp=2017-02-15 23:10:52.3492 Level=INFO TraceId=0HL2LTTU3JVBI Message=Request finished in 170.7178ms 200 application/json; charset=utf-8
TimeStamp=2017-02-15 23:10:52.3672 Level=DEBUG TraceId= Message=Connection id "0HL2LTTU1ONI7" completed keep alive response.

4. Using aspnet-item renderer

If for some reasons we don’t like to use TraceIdentifier as our CorrelationId, we can leverage aspnet-item renderer, which basically allows you to read data from HttpContext.Items collection. However in that case, we are responsible for providing and storing unique identifier of request in HttpContext.Items. Fortunately it is pretty straightforward to do with custom middleware.

public class LoggingMiddleware
{
    private readonly ILogger<LoggingMiddleware> logger;
    private readonly RequestDelegate next;
	
    public LoggingMiddleware(ILogger<LoggingMiddleware> logger, RequestDelegate next)
    {
        this.logger = logger;
        this.next = next;
    }
	
    public async Task Invoke(HttpContext context)
    {
        context.Items["CorrelationId"] = Guid.NewGuid().ToString();
        logger.LogInformation($"About to start {context.Request.Method} {context.Request.GetDisplayUrl()} request");
	
        await next(context);

        logger.LogInformation($"Request completed with status code: {context.Response.StatusCode} ");
    }
}

Of course we have to also use this middleware in our application so we have to add following line

app.UseMiddleware<LoggingMiddleware>();

in configure method of our Startup class. Having all the pieces in place, now we can append CorrelationId read from HttpContext.Items to our log entries with following configuration

<?xml version="1.0" encoding="utf-8" ?>
<nlog xmlns="http://www.nlog-project.org/schemas/NLog.xsd"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      autoReload="true">

  <extensions>
    <add assembly="NLog.Web.AspNetCore"/>
  </extensions>
  
  <targets>
    <target xsi:type="File" name="File" fileName="${basedir}/logs/${shortdate}.log"
            layout="TimeStamp=${longdate} Level=${uppercase:${level}} CorrelationId=${aspnet-item:variable=CorrelationId} Message=${message}" />
  </targets>
   
  <rules>
    <logger name="*" minlevel="Debug" writeTo="File" />
  </rules>
</nlog>

From now on, CorrelationId will be automatically added to our log entries

TimeStamp=2017-02-15 23:35:56.8333 Level=INFO CorrelationId= Message=Request starting HTTP/1.1 GET http://localhost:50334/api/values  
TimeStamp=2017-02-15 23:35:56.8333 Level=INFO CorrelationId=15989892-9f27-49d0-88b5-ced61b6851ac Message=About to start GET http://localhost:50334/api/values request
TimeStamp=2017-02-15 23:35:56.8333 Level=DEBUG CorrelationId=15989892-9f27-49d0-88b5-ced61b6851ac Message=Request successfully matched the route with name '' and template 'api/Values'.
TimeStamp=2017-02-15 23:35:56.8513 Level=DEBUG CorrelationId=15989892-9f27-49d0-88b5-ced61b6851ac Message=Action 'AspNetCoreLoggingWithCorrelationId.Controllers.ValuesController.Post (AspNetCoreLoggingWithCorrelationId)' with id '5d60d23c-ddef-4d20-98eb-a0c03885bea5' did not match the constraint 'Microsoft.AspNetCore.Mvc.Internal.HttpMethodActionConstraint'
TimeStamp=2017-02-15 23:35:56.8513 Level=DEBUG CorrelationId=15989892-9f27-49d0-88b5-ced61b6851ac Message=Executing action AspNetCoreLoggingWithCorrelationId.Controllers.ValuesController.Get (AspNetCoreLoggingWithCorrelationId)
TimeStamp=2017-02-15 23:35:56.8513 Level=INFO CorrelationId=15989892-9f27-49d0-88b5-ced61b6851ac Message=Executing action method AspNetCoreLoggingWithCorrelationId.Controllers.ValuesController.Get (AspNetCoreLoggingWithCorrelationId) with arguments () - ModelState is Valid
TimeStamp=2017-02-15 23:35:56.8673 Level=INFO CorrelationId=15989892-9f27-49d0-88b5-ced61b6851ac Message=Get method requested
TimeStamp=2017-02-15 23:35:56.8673 Level=INFO CorrelationId=15989892-9f27-49d0-88b5-ced61b6851ac Message=Log from Get action, from thread=3
TimeStamp=2017-02-15 23:35:56.8923 Level=INFO CorrelationId=15989892-9f27-49d0-88b5-ced61b6851ac Message=Log from Get, from thread 4 assigned by scheduler
TimeStamp=2017-02-15 23:35:56.8993 Level=INFO CorrelationId=15989892-9f27-49d0-88b5-ced61b6851ac Message=Log from Get action, from async continuation, from thread 4
TimeStamp=2017-02-15 23:35:56.8993 Level=INFO CorrelationId=15989892-9f27-49d0-88b5-ced61b6851ac Message=Log from Get action, from explicitly created thread 16
TimeStamp=2017-02-15 23:35:56.9163 Level=DEBUG CorrelationId=15989892-9f27-49d0-88b5-ced61b6851ac Message=Executed action method AspNetCoreLoggingWithCorrelationId.Controllers.ValuesController.Get (AspNetCoreLoggingWithCorrelationId), returned result Microsoft.AspNetCore.Mvc.ObjectResult.
TimeStamp=2017-02-15 23:35:56.9163 Level=DEBUG CorrelationId=15989892-9f27-49d0-88b5-ced61b6851ac Message=No information found on request to perform content negotiation.
TimeStamp=2017-02-15 23:35:56.9274 Level=DEBUG CorrelationId=15989892-9f27-49d0-88b5-ced61b6851ac Message=Selected output formatter 'Microsoft.AspNetCore.Mvc.Formatters.JsonOutputFormatter' and content type 'application/json' to write the response.
TimeStamp=2017-02-15 23:35:56.9274 Level=INFO CorrelationId=15989892-9f27-49d0-88b5-ced61b6851ac Message=Executing ObjectResult, writing value Microsoft.AspNetCore.Mvc.ControllerContext.
TimeStamp=2017-02-15 23:35:56.9444 Level=INFO CorrelationId=15989892-9f27-49d0-88b5-ced61b6851ac Message=Executed action AspNetCoreLoggingWithCorrelationId.Controllers.ValuesController.Get (AspNetCoreLoggingWithCorrelationId) in 83.2831ms
TimeStamp=2017-02-15 23:35:56.9444 Level=INFO CorrelationId=15989892-9f27-49d0-88b5-ced61b6851ac Message=Request completed with status code: 200 
TimeStamp=2017-02-15 23:35:56.9674 Level=INFO CorrelationId=15989892-9f27-49d0-88b5-ced61b6851ac Message=Request finished in 134.3253ms 200 application/json; charset=utf-8
TimeStamp=2017-02-15 23:35:56.9764 Level=DEBUG CorrelationId= Message=Connection id "0HL2LUBSKVM2T" completed keep alive response.

6. It works in multithreading scenarios

If you take a closer look at logs presented above, you will see that both of the renderers can log proper CorrelationId/TraceId regardless of the thread from which the logger was called. This is possible thanks to implementation of HttpContextAccessor which uses AsyncLocal under the hood, which allows you to persist data across threads.

// decompiled code
namespace Microsoft.AspNetCore.Http
{
    public class HttpContextAccessor : IHttpContextAccessor
    {
        private AsyncLocal<HttpContext> _httpContextCurrent = new AsyncLocal<HttpContext>();
	
        public HttpContext HttpContext
        {
            get
            {
                return this._httpContextCurrent.Value;
            }
            set
            {
                this._httpContextCurrent.Value = value;
            }
        }
    }
}

Source code for this post can be found here

Boxstarter - breaking infinite reboot loop

Mon, 19 Dec 2016 23:20:40 GMT

1. Introduction

Boxstarter is a great tool for configuring your machine without any user interaction. I've been using it for a while now, however recently I've noticed that for no apparent reason it wasn't able to finish the execution of provisioning script as it stuck in infinite reboot loop. Is was quite frustrating for me, that is why I've decided to investigate the problem. Here are my findings.

2. Detecting pending reboots

If you dive into Boxstarter source code you will notice that script responsible for checking if reboot is necessary uses Get-PendingReboot cmdlet. By default Boxstarter doesn’t export it, so if you want to see what it does you have to add following line in your Boxstarer script

Import-Module (Join-Path $Boxstarter.BaseDir Boxstarter.Bootstrapper\Get-PendingReboot.ps1) -global -DisableNameChecking

Calling the Get-PendingReboot cmdlet will give you an information about mandatory reboots. In my case, the output looked as following

As you can see RebootPending flag is set to true and the reason is that the value of PendingFileRenVal property is not null. Basically, in most of the cases, a restart is indeed required however, some applications leave information about pending reboot in the registry (HKEY\LOCAL\MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Session Manager\\PendingFileRenameOperations) and operating system (in some cases) never cleans this up. As a result Get-PendingReboot indicates that reboot is required and Boxstarter falls into infinite restart loop.

3. Fixing the problem

The obvious solution is to remove that value from the registry key manually. However this approach didn’t work for me, basically because the registry value somehow was added at the beginning of execution of my script. That is why, I've decided to modify my script and add a function which clears undesirable pending file renames of my choice.

function Clear-Known-Pending-Renames($ignoredRenames){
    $regKey = "HKLM:SYSTEM\CurrentControlSet\Control\Session Manager\"
    $regProperty = "PendingFileRenameOperations"
    $pendingReboot = Get-PendingReboot

    Write-BoxstarterMessage "Current pending reboot $($pendingReboot | Out-String)"
    
    if($pendingReboot.PendFileRename){

        $output = $pendingReboot.PendFileRenVal | %{$_ -split [Environment]::NewLine} | ? { 
            $current = $_
            ![string]::IsNullOrWhiteSpace($current) -and ($ignoredRenames | ? { $current.StartsWith($_)  } ).Length -eq 0 } | Get-Unique

        if($output -eq $null){
            $output = @()
        }
        
        Set-ItemProperty -Path $regKey -Name $regProperty -Value ([string]::Join([Environment]::NewLine, $output))
        Write-BoxstarterMessage "Updated pending reboot $(Get-PendingReboot | Out-String)"
    }
}

As you can see I am taking current value of PendingFileRenameOperations and remove the entries which I know that will stay there forever. Calling that function as the very first step of my installation script solved the problem and I was able to successfully restore my machine from Boxstarter script

Entire Boxstarter script can be found here.

Logstash - reading logs from RabbitMQ

Thu, 17 Nov 2016 13:53:07 GMT

1. Introduction

In my previous post, I've shown how to configure Logstash to parse logs from files. This is pretty useful however if your application is deployed on multiple servers, you usually log to some kind of central log storage - in my case to queue, RabbitMQ to be more specific. In this post, I will show how to configure Logstash so it reads the logs from that queue.

2. Preparing queue

Before we move to Logstash configuration, first of all, we have to prepare RabbitMQ test instance. If you don't have RabbitMQ yet, go to this website and install the queue. Once installation is done, go to the installation folder (C:\Program Files\RabbitMQ Server\rabbitmq\server-3.6.5\sbin in my case) and run in console

rabbitmq-plugins.bat enable rabbitmq_management

This command will prepare RabbitMQ management website, so it will be easier for us to see what is going on in given queue. In the next step, we have to prepare the queue, the logs will be sent to. You can do it via the website we've just enabled (http://localhost:15672/) or via RabbitMQ admin console. As I prefer to automate things as much as possible I will do it via command line. What is quite unusual when it comes RabbitMQ CLI is the fact that it is a python script you have to download and run locally (this is not an executable). The script can be found on management site under this address. Once the script is downloaded (in my case it is saved as rabbitmqadmin.py) you can start preparing necessary elements: exchange, queue and the binding.

python rabbitmqadmin.py declare exchange name=logger type=topic -u username -p password

python rabbitmqadmin.py declare queue  name=MyAppLogginQueue auto_delete=false durable=true -u username -p password

python rabbitmqadmin.py  declare binding source=logger destination=MyAppLogginQueue routing_key=MyApp -u username -p password

As you can see I've created exchange called logger which is bound to MyAppLogginQueue queue using MyApp route. This means that every message with topic MyApp sent to logger exchange will be pushed to MyAppLogginQueue .

3. Preparing Logstash

Logstash configuration will be modified version of my previous config. I will just add another input source. Here is a basic usage

input {	
	rabbitmq {
        host => "localhost"
        queue => "MyAppLogginQueue"
        heartbeat => 30
        durable => true
        password => "password"
        user => "username"
    }
}

As you can see we will be consuming messages from MyAppLogginQueue which is deployed on localhost. For password and user properties use your own credentials. That is basically it, so now it is time to see if everything is working.

4. Testing coniguration

In order to test the configuration you have to run the Elasticsearch, Kibana and use new config for Logstash. I've shown how to do it in one of my recent post. For sending messages to the queue I will just use RabbitMQ management website API. The API exposes

api/exchanges/%2F/{exchange_name}/publish

endpoint accepting POST verbs which can be used for publishing messages to given exchange. In my case POST body will look as follows

{
  "vhost": "/",
  "name": "logger",
  "properties": {
    "delivery_mode": 2,
    "headers": {}
  },
  "routing_key": "MyApp",
  "delivery_mode": "2",
  "payload": "TimeStamp=2016-11-01 00:13:01.1669 CorrelationId=77530786-8e6b-45c2-bbc1-31837d911c14 Level=INFO Message=Request completed with status code: 200",
  "headers": {},
  "props": {},
  "payload_encoding": "string"
}

and I will be sending it to

http://localhost:15672/api/exchanges/%2F/logger/publish

Note that I will be sending messages to the exchange, not to the queue itself. The exchange's responsibility is to route the message to all bound queues. Here is how it looks in practice

As you can see our configuration is valid and messages are shown on Kibana's dashboard almost in real time.

Full Logstash config can be found here

Logstash - parsing multiline log entries

Thu, 03 Nov 2016 20:26:28 GMT

In my previous post I've shown how to configure Logstash so that, it would be able to parse the logs in custom format. Configuration presented in that post had one significant drawback - it wasn't able to parse multiline log entries. This is a rather common scenario, especially when you log exceptions with a stack trace. Log entry, in that case may look as follows

TimeStamp=2016-11-01 02:08:02.9086 CorrelationId=69dd69bb-3457-4440-8f77-88b1fd39255a Level=ERROR Message=System.InvalidOperationException: Operation is not valid due to the current state of the object.
   at AspNetMvcLoggingWithCorrelationId.Controllers.HomeController.<About>d__2.MoveNext() in E:\Tomek\Programowanie\BlogSrc\AspNetMvcLoggingWithCorrelationId\AspNetMvcLoggingWithCorrelationId\Controllers\HomeController.cs:line 24
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at System.Web.Mvc.Async.TaskAsyncActionDescriptor.EndExecute(IAsyncResult asyncResult)
   at System.Web.Mvc.Async.AsyncControllerActionInvoker.<>c__DisplayClass37.<BeginInvokeAsynchronousActionMethod>b__36(IAsyncResult asyncResult)
   at System.Web.Mvc.Async.AsyncResultWrapper.WrappedAsyncResult`1.CallEndDelegate(IAsyncResult asyncResult)
   at System.Web.Mvc.Async.AsyncResultWrapper.WrappedAsyncResultBase`1.End()
   at System.Web.Mvc.Async.AsyncControllerActionInvoker.EndInvokeActionMethod(IAsyncResult asyncResult)
   at System.Web.Mvc.Async.AsyncControllerActionInvoker.AsyncInvocationWithFilters.<InvokeActionMethodFilterAsynchronouslyRecursive>b__3d()
   at System.Web.Mvc.Async.AsyncControllerActionInvoker.AsyncInvocationWithFilters.<>c__DisplayClass46.<InvokeActionMethodFilterAsynchronouslyRecursive>b__3f()
   at System.Web.Mvc.Async.AsyncControllerActionInvoker.<>c__DisplayClass33.<BeginInvokeActionMethodWithFilters>b__32(IAsyncResult asyncResult)
   at System.Web.Mvc.Async.AsyncResultWrapper.WrappedAsyncResult`1.CallEndDelegate(IAsyncResult asyncResult)
   at System.Web.Mvc.Async.AsyncResultWrapper.WrappedAsyncResultBase`1.End()
   at System.Web.Mvc.Async.AsyncControllerActionInvoker.EndInvokeActionMethodWithFilters(IAsyncResult asyncResult)
   at System.Web.Mvc.Async.AsyncControllerActionInvoker.<>c__DisplayClass21.<>c__DisplayClass2b.<BeginInvokeAction>b__1c()
   at System.Web.Mvc.Async.AsyncControllerActionInvoker.<>c__DisplayClass21.<BeginInvokeAction>b__1e(IAsyncResult asyncResult)

Parsing these kind of messages using current configuration will result in grok parsing error

and we won't be able to search against predefined fields. Fortunately Logstash allows you to configure something called input codecs which basically allows you to transform input data into some other form. One of those codes is multiline codec, which is responsible for "merging" multiline logs into one entry. Here is example of codec configuration

codec => multiline {
                       pattern => "^TimeStamp=%{TIMESTAMP_ISO8601}"
                       negate => true
                       what => "
}

The code above says that any line not starting with a TimeStamp=timestamp value should be merged with the previous line. Multiline coded can be added to a variety of inputs. Here is how you can apply it to file input

input {
    file {
        path => ["E:/Tomek/Programowanie/BlogSrc/ElasticStackParsingMultilineEntries/logs/*.log"]
        start_position => beginning
        ignore_older => 0
        sincedb_path => "NUL"
        codec => multiline {
                               pattern => "^TimeStamp=%{TIMESTAMP_ISO8601}"
                               negate => true
                               what => "previous"
        }
    }
}

Thanks to that change, Logstash is now able to correctly parse exceptions from our logs.

Source code for this post can be found here

Getting started with Elastic Stack

Wed, 02 Nov 2016 19:38:24 GMT

1. Introduction

In one of my previous post I've shown how to improve logging in an application by tracking the flow of incoming requests. Now it is time to show the basics of Elastic stack to make searching across multiple log files/sources a piece of cake. Elastic stack (previously called ELK stack) is set of three tools which allows you to parse (Logstash), query (Elasticsearch) and visualize (Kibana) logs with ease.

2. Installation

First of all (as usual) we have to get the tools, so go to elastic.co and download apps mentioned before. These are stand-alone applications so no installation is required. The only requirement is to have JAVA\HOME_ system variable pointing to your java directory. In my case, this looks as follows

C:\Program Files\Java\jre1.8.0_91\

3. Elasticsearch

Once all three applications are downloaded we can run Elasticsearch (as there is not additional configuration needed for basic usage) instance via an elasticsearch.bat file.

4. Logstash

Having our Elasticsearch instance up and running, now it is time configure Logstash so that it will be able to parse logs. Configuration provided in next sections will be able to parse logs with the following format

TimeStamp=2016-07-20 21:22:46.0079 CorrelationId=dc665fe7-9734-456a-92ba-3e1b522f5fd4 Level=INFO Message=About to start GET / request

4.1. Configuration

Logstash configuration is done via config file in specific format. You can read about that here. The very first step is to define input and output sections

input {
    file {
        path => ["C:/logs/*.log"]
        start_position => beginning
    }
}
output {
    elasticsearch {
        hosts => "localhost:9200"
    }
    stdout {}
}

As you can see the logs will be read from C:\logs directory and parsed content will be pushed to Elasticsearch instance and to the console output. We can verify correctness of configuration calling

logstash.bat -f  "Path\To\Config\File.conf" -t

If you are making your config file for the first time it is good idea to add additional properties to the file section

ignore_older => 0
sincedb_path => "NUL"

This will force Logstash to reparse entire file when restarted and will also make sure that older files are not ignored (by default files modified more than 24 hours ago are ignored).

At this point, Logstash can read the log file but it doesn’t do anything special with it. Next step is to configure a pattern which will be used for log parsing. Logstash uses grok for defining the patterns. Long story short it is kind of a regex which can use predefined patterns. The easiest way to play around with it is to use grokconstructor, for list of ready to use patterns take a look at this

For parsing logs shown in previous section I've ended up with this grok pattern

TimeStamp=%{TIMESTAMP_ISO8601:logdate} CorrelationId=%{UUID:correlationId} Level=%{LOGLEVEL:logLevel} Message=%{GREEDYDATA:logMessage}

Notice that you are able to give aliases for particular fields, for instance

TimeStamp=%{TIMESTAMP_ISO8601:logdate}

means that everything that matches TimeStamp=%{TIMESTAMP\ISO8601} will be stored in logdate field. Having defined our pattern, now we can add it to the config file. After modifications, it looks as follows

input {
    file {
        path => ["C:/logs/*.log"]
        start_position => beginning
    }
}
filter {
    grok {
        match => { "message" => "TimeStamp=%{TIMESTAMP_ISO8601:logdate} CorrelationId=%{UUID:correlationId} Level=%{LOGLEVEL:logLevel} Message=%{GREEDYDATA:logMessage}" }
    }
}
output {
    elasticsearch {
        hosts => "localhost:9200"
    }
    stdout {}
}

Once we run this config and start querying elastic search for list of all indices via

http://localhost:9200/_cat/indices?v

we will see that our logs were parsed and stored in index called logstash-2016.10.30

If we now go to

http://localhost:9200/logstash-2016.10.30

we will be able to see index information

4.2. Fixing the date fields

At this moment there are two main problems with our configuration. First of all, the indices are created based on read time from file. Second of all our logdate field is treated as string.

By default Logstash creates indices based on read time of the source. However in my opinion it is better to create index names based on time given event occurred. In order to do that, we have to tell the Logstash which field is responsible for holding timestamp. In my case, this field is called logdate. All we have to do is to map this field into field via date filter

date {
        match => [ "logdate", "yyyy-MM-dd HH:mm:ss.SSSS" ]
}

As you can see first argument is a filed name and rest of the arguments (you can specify more) are just date time formats. By default date filter maps a field from the match property into @timestamp field. So the config above equals this one

date {
        match => [ "logdate", "yyyy-MM-dd HH:mm:ss.SSSS" ]
        target => "@timestamp"
}

If we restart Logstash and get the indices, we will see something similar to that

Second problem can be handled in very similar way. We have to add second date filter and select as target longdate field

date {
        match => [ "logdate", "yyyy-MM-dd HH:mm:ss.SSSS" ]
        target => "logdate"
}

From now on logdate field will be treated as date so we will be able to filter the logs easily with Kibana

5. Running Kibana

Having all the configuration in place now we are ready to run Kibana. As in previous steps, no installation is needed so just run the Kibana.bat file

and go to

http://localhost:5601/

If you run the app for the first time you will be asked to configure the indices. You can use the default parameters and just click Create button. Once the indices are setup you can start writing queries against the logs. By default entire message is searched for the search terms, however the real power comes with queries written against specific fields. For example, you can search for any errors in the application with this simple query

logLevel: (FATAL OR ERROR)

Thanks to date type fields, you can combine this query with date range selector and narrow down time to specific values, just like that

logdate:[2016-07-20 TO 2016-10-31] AND logLevel: (FATAL OR ERROR)

These are just the basic queries you can run in Kibana, for more advanced scenarios please visit website. I also strongly encourage you guys to take a look at other feature Elastic stack provides. Source code for this post can be found here

PS Configuration presented in this post will not be able to parse multiline log entries e.g. exceptions. I will show you how to do it in the next post.

RedisSessionStateProvider - unknown command 'EVAL'

Sat, 29 Oct 2016 18:33:27 GMT

A couple of days ago I was trying to use Redis as session storage for one of my ASP .NET websites. Even though it seemed to be a rather straightforward task (Scott Hanselman wrote about that a while ago), I ended up with some weird exception while running the app: ERR unknown command 'EVAL'

This wasn’t for sure a connectivity issue, as I was able to connect to Redis server from Redis Client - redis-cli. For me it looked like my server is not able to "understand" EVAL command. I started digging around and it turned out that this command has been introduced in version 2.6.0 I've connected to the server using redis-cli and checked the version with info command and basically that revealed the problem.

As you can see I've accidentally installed version 2.4.6 (I have no idea how I ended up with so old version). After upgrading to the newest one, my problem was gone and I was able to successfully store session in Redis.

Visual Studio - restoring default exception window

Tue, 25 Oct 2016 19:22:33 GMT

I think everyone is familiar with this nice exception window we see once exception is thrown.

However today for some reasons my VisualStudio started showing some weird dialog.

This was pretty frustrating as I wasn’t able to see which line has thrown exception and basically after clicking Break or Continue application was terminated. After a while I found out that the default window is called Exception assistant and you can enable it in Visual Studio's options. So in order to restore default behavior, just go to Tools -> Options -> Debugging -> General and select Enable the exception assistant checkbox.

Fiddler - request redirection

Wed, 28 Sep 2016 20:25:12 GMT

As a back-end developer I am quite often contacted by front-end devs to take a look why certain UI calls to the server results in wrong data being returned by API. Usually I am provided with request payload so it is quite straightforward to reply it with Postman or Fiddler and see what is going on the backend. However for time to time, replying single request is not enough to reproduce the problem. In that case it is easier to just recreate the scenario on the UI and debug the API during that process. Unfortunately this approach requires backend devs to have UI up and running on their local machines and that is not always possible (e.g. you might not get access to UI repository). Fortunately with Fiddler it is quite easy to intercept outgoing front-end calls to the API and redirect them to your locally deployed version (so you can easily debug the API).

Let's assume we would like to redirect all simpletestspa.azurewebsites.net calls to localhost:50277. In order to do that run Fiddler and go to Tools -> Hosts…

Select "Enable remapping of requests for one host to a different host or IP, overriding DNS" checkbox

and enter following values in the editor

localhost:50277 simpletestspa.azurewebsites.net

From now every outgoing request to simpletestspa.azurewebsites.net will be redirected to your local instance of the server on localhost:50277.

Cake - Data at the root level is invalid

Thu, 08 Sep 2016 20:55:01 GMT

Couple of weeks ago I mentioned that in my current project we use Cake as a build mechanism. Recently we wanted to add simple functionality to our build script, which would allow us to modify one of the App.config's properties. According to the documentation it should be a straightforward tasks, as all the heavy lifting can be done via XmlPeek and XmlPoke aliases.

Our initial script looked as follows

Task("Update-Version")
.Does(()=>
{
    var appConfigPath = paths.Directories.Project + "/" + Context.File("App.config");
    var version = GetVersion(appConfigPath);
    Information("Current version: {0}", version);
    XmlPokeString(File(appConfigPath), xPathVersionSelector, (++version).ToString());
    version = GetVersion(appConfigPath);
    Information("Updated version: {0}", version);
});

private int GetVersion(string appConfigPath)
{
    return int.Parse(XmlPeek(appConfigPath, xPathVersionSelector));
}

And what was surprising for us, it didn't work.

We got a bit weird error "Data at the root level is invalid. Line 1, position 1". The exception suggested that there was something wrong with our App.config file. However if you look at the picture presented above, you will see that we were able to successfully read the file and retrieve value of Version with XmlPeek method. After a bit of digging it turned out that XmlPoke and XmlPokeString are not able to work with relative paths and we have to use absolute one in order to make it work. Fortunately there is an easy way to do that, namely MakeAbsolute method. Out script after modifications looks that way

Task("Update-Version")
.Does(()=>
{
    var appConfigPath = paths.Directories.Project + "/" + Context.File("App.config");
    var version = GetVersion(appConfigPath);
    Information("Current version: {0}", version);
    XmlPoke(MakeAbsolute(File(appConfigPath)), xPathVersionSelector, (++version).ToString());
    version = GetVersion(appConfigPath);
    Information("Updated version: {0}", version);
});

private int GetVersion(string appConfigPath)
{
    return int.Parse(XmlPeek(appConfigPath, xPathVersionSelector));
}

And now everything works fine

Source code for this post can be found here

Intercepting browser requests with Postman

Sun, 24 Jul 2016 22:39:19 GMT

If you are doing any kind of rest api development you probably have heard of Postman. Long story short, it is a Chrome extension which allows you to send http requests in a very easy and intuitive way. Apart from that (and many other features), it also allows you to intercept browser request. As this feature is very easy to overlook, here is a simple guide how to use it.

In the Postman window, click little satellite look-like button and toggle the Interceptor switch

Postman will ask you to install additional plugin called Postman Interceptor

Once you click Install you will be redirected to Chrome Web Store where you can add the plugin to the browser. After successful installation you will see additional icon in Chrome menu bar. Click it and toggle Request capture switch

When you go back to Postman and toggle again "Interceptor" button, it will be synchronized with Postman Interceptor plugin

and from now on, requests sent by browser will be visible in requests history

where you will be able to modify and resend them.

Generating PDB files with Resharper

Sun, 17 Jul 2016 10:40:59 GMT

The majority of the libraries developers use in their projects these days are open source. So in case something crashes inside third party library or you just want to know how it works, it is possible to get the PDB files from Microsoft Symbols Servers and debug it. If for some reasons PDB cannot be found on the servers, you can always grab the source code from GitHub and add to your project manually. Unfortunately when you use commercial libraries, it is impossible to do any of the previous steps. Luckily with Resharper you are able to generate PDB files from assembly and use it later in Visual Studio to debug it. Let's assume we would like to generate PDB files for EntityFramework. First of all, we have to locate EntityFramework assembly in Assembly Explorer. Go to Solution Explorer, RMB click on assembly you are interested in and select View in Assembly Explorer.

In Assembly Explorer once again RMB click on EntityFramework and select "Generate Pdb…"

In the opened window, select the destination folder for the files.

Once you click "Generate", Resharper will process the assembly and generate PDBs.

Once the files are generated we have to tell Visual Studio to use them. In order to do that, run the app and stop the execution with some breakpoint, then go to Debug->Windows-> Modules, locate EntityFramework.dll, click it with RMB, select Load Symbols and choose file(s) generated by Resharper.

At this point we have PDB files ready but we are not able to set any breakpoint as we don't have source code of EntityFramework. Fortunately Resharper once again saves the day as it is able to navigate to decompiled sources. Just make sure that your settings (Resharper->Options->External Sources) are the same as in the picture below

and you can navigate to external libraries' source code just like they were in your project. The very last step is to disable Enable Just My Code option in Tools->Options->Debugging->General

and from now on you can debug the external library

Debugging cake scripts

Sun, 10 Jul 2016 09:03:08 GMT

We've been using Cake in our project for quite some time and it has been working great. However for time to time lack of debugging support was really annoying for me. Fortunately it seems that these times are gone now. During NDC Oslo 2016 Gary Ewan Park showed that it is possible to attach debugger to the build process. Here are the steps to achieve that.

Let's assume that we have following simple cake script.

var target = Argument("target", "Default");
Task("Default")
    .Does(() =>
{
    MSBuild(Directory("../") + File("DebuggingCakeScript.sln"));
});

RunTarget(target);

In order to make the debugging possible it is necessary to add #break preprocessor directive to the task we want the debugger to stop.

var target = Argument("target", "Default");
Task("Default")
    .Does(() =>
{
    #break
    MSBuild(Directory("../") + File("DebuggingCakeScript.sln"));
});

RunTarget(target);

This operation doesn't affect the default build process, so if you run in console

.\build.ps1 -target Default

the build will run as usual. In order to be able to attach the debugger we have to call Cake with --debug flag. You can't do it directly via \build.ps1 script so assuming that you didn't change directory structure created by bootstrapper, go to Tools\Cake folder and run from PowerShell

.\Cake.exe ..\..\build.cake -target=Default --debug

where ..\..\build.cake is path to your cake script and Default is task you want to start. Once you run the command, cake will wait for attaching the debugger

Now launch Visual Studio, go to Debug-> Attach to Process…, find process id listed in console

and click Attach. After couple of seconds Visual Studio will load your cake script and you will be able to debug it like normal application.

NLog - tracking flow of requests using MappedDiagnosticsLogicalContext

Tue, 05 Jul 2016 20:38:53 GMT

1. Problem

Everyone who has ever had to analyze logs from production environment knows, that quite often it is not an easy task. Usually application flow is deduced by log entries matched by thread id, which is problematic when you deal with multithreading scenarios. Say for example we have following piece of code

public class HomeController : Controller
{
    private static readonly Logger Logger = LogManager.GetCurrentClassLogger();
    
    public async Task<ActionResult> Index()
    {
        await PreprocessRequest(nameof(Index));
        return View();
    }
    
    private static async Task PreprocessRequest(string actionName)
    {
        Logger.Info($"Log from {actionName} action, from thread={Thread.CurrentThread.ManagedThreadId}");
        
        await Task.Run(() => Logger.Info($"Log from {actionName}, from thread {Thread.CurrentThread.ManagedThreadId} assigned by scheduler"))
                  .ConfigureAwait(continueOnCapturedContext: false);
        Logger.Info($"Log from {actionName} action, from async continuation, from thread {Thread.CurrentThread.ManagedThreadId}");
               
        var thread =
            new Thread(() => Logger.Info($"Log from {actionName} action, from explicitly created thread {Thread.CurrentThread.ManagedThreadId}"));
        thread.Start();
        thread.Join();
    }
}

Default log file usually looks like that

TimeStamp=2016-07-03 11:56:02.2327 ThreadId=5 Level=INFO Message=About to start GET / request
TimeStamp=2016-07-03 11:56:02.3797 ThreadId=5 Level=INFO Message=Log from Index action, from thread=5
TimeStamp=2016-07-03 11:56:02.3797 ThreadId=6 Level=INFO Message=Log from Index, from thread 6 assigned by scheduler
TimeStamp=2016-07-03 11:56:02.3797 ThreadId=6 Level=INFO Message=Log from Index action, from async continuation, from thread 6
TimeStamp=2016-07-03 11:56:02.3917 ThreadId=14 Level=INFO Message=Log from Index action, from explicitly created thread 14
TimeStamp=2016-07-03 11:56:04.8250 ThreadId=8 Level=INFO Message=Request completed with status code: 200

Having multiple simultaneous Index requests, makes it almost impossible to figure out which log entry is part of which call. Fortunately with NLog it is possible to solve this problem without too much of a hassle.

2. Proposed solution

The whole idea is to leverage MappedDiagnosticsLogicalContext "storage" to keep some unique identifier of request for entire call. Note, that this identifier will be accessible also from other threads created from within given call. In order to set unique request id (also known as correlation id) I will use custom HttpModule. The very first implementation looks like that

public class LoggingHttpModule : IHttpModule
{
    private const string CorrelationIdKey = "correlationid";

    private static readonly Logger Logger = LogManager.GetCurrentClassLogger();

    public void Init(HttpApplication context)
    {
        context.BeginRequest += HandleBeginRequest;
        context.EndRequest += HandleEndRequest;
    }

    public void Dispose()
    {
    }

    private void HandleBeginRequest(object sender, EventArgs e)
    {
        var value = Guid.NewGuid().ToString();
        var httpApplication = (HttpApplication) sender;
        var httpContext = httpApplication.Context;
        MappedDiagnosticsLogicalContext.Set(CorrelationIdKey, value);
        Logger.Info($"About to start {httpContext.Request.HttpMethod} {httpContext.Request.RawUrl} request");
    }

    private void HandleEndRequest(object sender, EventArgs e)
    {
        var httpApplication = (HttpApplication) sender;
        var httpContext = httpApplication.Context;
        Logger.Info($"Request completed with status code: {httpContext.Response.StatusCode} ");
    }
}

Once the HttpModule is ready it is necessary to register it in web.config.

<!--rest of the code omitted -->
<system.webServer>
  <modules>
  <!--rest of the code omitted -->
    <add name="LoggingHttpModule" type="AspNetMvcLoggingWithCorrelationId.HttpModules.LoggingHttpModule"/>
  </modules>
</system.webServer>
<!--rest of the code omitted -->
<system.web>
<!--rest of the code omitted -->
  <httpModules>
  <!--rest of the code omitted -->
    <add name="ApplicationInsightsWebTracking" type="Microsoft.ApplicationInsights.Web.ApplicationInsightsHttpModule,Microsoft.AI.Web"/>
  </httpModules>
</system.web>

From now on, every request goes through LogginHttpModule and proper correlationId is set in MappedDiagnosticsLogicalContext. As we want to have correlationId included in log files it is necessary to modify Nlog.config. In my case it looks like that

<?xml version="1.0" encoding="utf-8" ?>
<nlog xmlns="http://www.nlog-project.org/schemas/NLog.xsd"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:schemaLocation="http://www.nlog-project.org/schemas/NLog.xsd NLog.xsd"
      autoReload="true"
      throwExceptions="false"
      internalLogLevel="Off" internalLogFile="c:\temp\nlog-internal.log" >

  <variable name="myvar" value="myvalue"/>
  <targets>
    <target xsi:type="File" name="f" fileName="${basedir}/logs/${shortdate}.log"
            layout="TimeStamp=${longdate} CorrelationId=${mdlc:item=correlationid} Level=${uppercase:${level}} Message=${message}" />
  </targets>

  <rules>
    <logger name="*" minlevel="Debug" writeTo="f" />
  </rules>
</nlog>

Note that we can access our correlationId variable via ${mdlc:item=correlationid} Log file after the changes looks like that

TimeStamp=2016-07-03 12:41:35.7292 CorrelationId=b322d1fa-47b2-4582-b7a9-c9463b7c0a47 Level=INFO Message=About to start GET / request
TimeStamp=2016-07-03 12:41:35.8752 CorrelationId=b322d1fa-47b2-4582-b7a9-c9463b7c0a47 Level=INFO Message=Log from Index action, from thread=6
TimeStamp=2016-07-03 12:41:35.8752 CorrelationId=b322d1fa-47b2-4582-b7a9-c9463b7c0a47 Level=INFO Message=Log from Index, from thread 7 assigned by scheduler
TimeStamp=2016-07-03 12:41:35.8752 CorrelationId=b322d1fa-47b2-4582-b7a9-c9463b7c0a47 Level=INFO Message=Log from Index action, from async continuation, from thread 7
TimeStamp=2016-07-03 12:41:35.8752 CorrelationId=b322d1fa-47b2-4582-b7a9-c9463b7c0a47 Level=INFO Message=Log from Index action, from explicitly created thread 9
TimeStamp=2016-07-03 12:41:38.4454 CorrelationId= Level=INFO Message=Request completed with status code: 200

This is almost perfect, however for some reasons correlationId is lost in EndRequest event handler. I am not sure if this is bug in NLog (I've posted question in Nlog's github) or it is by design, however there is easy workaround for that. We can store our correlationId in HttpContext.Items collection and reassign it to MappedDiagnosticsLogicalContext in EndRequest event handler.

private void HandleBeginRequest(object sender, EventArgs e)
{
    var value = Guid.NewGuid().ToString();
    var httpApplication = (HttpApplication) sender;
    var httpContext = httpApplication.Context;
    MappedDiagnosticsLogicalContext.Set(CorrelationIdKey, value);

    httpContext.Items[CorrelationIdKey] = value;
    Logger.Info($"About to start {httpContext.Request.HttpMethod} {httpContext.Request.RawUrl} request");
}

private void HandleEndRequest(object sender, EventArgs e)
{
    var httpApplication = (HttpApplication) sender;
    var httpContext = httpApplication.Context;

    var correlationId = httpContext.Items[CorrelationIdKey].ToString();
    MappedDiagnosticsLogicalContext.Set(CorrelationIdKey, correlationId);

    Logger.Info($"Request completed with status code: {httpContext.Response.StatusCode} ");
}

After these changes our log file finally looks OK

TimeStamp=2016-07-03 12:41:35.7292 CorrelationId=b322d1fa-47b2-4582-b7a9-c9463b7c0a47 Level=INFO Message=About to start GET / request
TimeStamp=2016-07-03 12:41:35.8752 CorrelationId=b322d1fa-47b2-4582-b7a9-c9463b7c0a47 Level=INFO Message=Log from Index action, from thread=6
TimeStamp=2016-07-03 12:41:35.8752 CorrelationId=b322d1fa-47b2-4582-b7a9-c9463b7c0a47 Level=INFO Message=Log from Index, from thread 7 assigned by scheduler
TimeStamp=2016-07-03 12:41:35.8752 CorrelationId=b322d1fa-47b2-4582-b7a9-c9463b7c0a47 Level=INFO Message=Log from Index action, from async continuation, from thread 7
TimeStamp=2016-07-03 12:41:35.8752 CorrelationId=b322d1fa-47b2-4582-b7a9-c9463b7c0a47 Level=INFO Message=Log from Index action, from explicitly created thread 9
TimeStamp=2016-07-03 12:41:38.4454 CorrelationId=b322d1fa-47b2-4582-b7a9-c9463b7c0a47 Level=INFO Message=Request completed with status code: 200

Source code for this post can be found here

Console2 - multiple tabs on startup

Sun, 24 Apr 2016 12:26:04 GMT

I've been using Console2 for quite some time and as for now it is my favorite command line terminal. The one thing I like the most is availability to use multiple tabs you can easily switch between. By default Console2 starts with only one tab opened, which was a bit of a pain for me. Mainly because I work a lot with Git and I also like to have a Visual Studio command prompt opened. So basically every time I launched command line I had to open one or two additional tabs. Fortunately it is quite easy to launch multiple tabs on startup. All you have to do is to create a shortcut to the Console2 with proper flags. Say for example I have following tabs defined

I can start Console2 with all these tabs opened on startup using following command.

PATH_TO_CONSOLE\Console.exe -t Git -t Cmd -t Powershell

Of course it is easier to define a shortcut to Console2 rather than remembering command above. My configuration looks like that

Mocking downstream services with Mountebank

Thu, 25 Feb 2016 20:44:35 GMT

1. Introduction

I'm a part of a team which creates large enterprise platform for the banking sector. Due to the fact that we operate in the financial area, our application consumes a high amount of downstream services. One of the major problems we are facing at the moment is the inaccessibility of those services on DEV and UAT environments. It often happens that one of those services is down for quite some time, so our development speed is impaired. The bigger problem, however, is the fact that our end-to-end tests are red. Having a red test on TeamCity for a long time is a really annoying thing because basically at this point, we just automatically assume that all of the failures are caused by issues with downstream systems. Fortunately, we finally decided to get rid of this problem and this is the solution we came up with.

2. Background

Before I go to the implementation details, take a look at a sample implementation of situation I described at the very beginning. Let's assume that we have WCF service which contains business logic of our application and it is consumed by the UI side

public class BookingFacade :  IBookingFacade
{
    public Response<Price> Price(Models.GetPriceRequest request)
    {
        // in real life scenario Pricer should be injected
        var pricerService = new Pricer();
        var response = new Response<Price>();
        try
        {
            var tradingDates = pricerService.GetTradingDates();
            var price = pricerService.GetPrice(new GetPriceRequest
            {
                IsAdvised = request.IsAdvised
            });

            // rest of the code omitted for brevity
            response.Result = new Price
            {
                TradingDates = new TradingDates
                {
                    MaturityDate = tradingDates.MaturityDate,
                    SettlementDate = tradingDates.SettlementDate
                }
            };
            // rest of the code omitted for brevity
        }
        catch (Exception ex)
        {
            // rest of the code omitted for brevity
        }
        return response;
    }
}

BookingFacade uses Pricer service which basically is just a wrapper for external/downstream service we have to use in order to retrieve some data (and we do not have an ownership of that service).

public class Pricer : IPricer
{
    public TradingDates GetTradingDates()
    {
        using (var webClient = new WebClient())
        {
            var result = webClient.DownloadString(ConfigurationManager.AppSettings["MockingDownstreamServices.Externals.Pricer.GetTradingDates"]);
            return JsonConvert.DeserializeObject<TradingDates>(result);
        }

    }

    public Price GetPrice(GetPriceRequest request)
    {
        using (var webClient = new WebClient())
        {
            var result = webClient.UploadString(ConfigurationManager.AppSettings["MockingDownstreamServices.Externals.Pricer.GetPrice"], JsonConvert.SerializeObject(request));
            return JsonConvert.DeserializeObject<Price>(result);
        }
    }
}

Very simple end-to-end test for BookingFacade can look like that

[TestFixture]
public class BookingFacadeTests
{
    [Test]
    public void CanSuccessfullyPriceTest()
    {
        var response = this.Price(new GetPriceRequest());
        Assert.IsNotNull(response);
        Assert.IsNotNull(response.Result);
        Assert.IsFalse(string.IsNullOrWhiteSpace(response.Result.Id));
        CollectionAssert.IsEmpty(response.Messages.Where(val => val.StatusCode == StatusCodes.Error));
    }
}

As I mentioned before, everything is fine as long as all of the downstream systems are working. The moment one of them is down, our tests start failing.

3. Implementation

General idea to fix this problem is to use fake downstream systems during end-to-end testing. In order to do that we use combination of custom compilation profile, app.config transformations and mountebank test doubles.

3.1 Setting up transformations

First of all we will create a custom compilation profile called test.integration which will be used for running tests with mocked downstream systems (we want to preserve the normal use of downstreams for Debug and Release mode). In order to do that, go to ConfigurationManager

and follow the steps presented in the pictures below

Now it is time to prepare our app.config for transformations. We can do it manually but for sake of simplicity I will use SlowCheetah extension. Go to Tools->Extensions and Updates and install SlowCheetah - XML Transforms. Once extension is installed you will see a Add Transform item in a config files' context menu.

Clicking Add Transform will create three files: App.Debug.config, App.Release.config and App.Test.Integration.config. What is more, some additional changes will be added to your csproj file, which will be responsible for applying transformations during a build process. These three additional files hold information about config transformations. The default App.config file looks like that

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <appSettings file="">
    <add key="commonKey" value="commonValue"/>
  </appSettings>
</configuration>

Nothing special in here but note the empty file attribute in appSettings node. The value of this attribute will be replaced with proper filename during transformation process. In order to do that let's implement tramsforms for every of three config files we use

<?xml version="1.0" encoding="utf-8" ?>
<!-- For more information on using transformations 
     see the web.config examples at http://go.microsoft.com/fwlink/?LinkId=214134. -->
<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
  <appSettings file="app.settings.debug" xdt:Transform="SetAttributes">
  </appSettings>
</configuration>

<?xml version="1.0" encoding="utf-8" ?>
<!-- For more information on using transformations 
     see the web.config examples at http://go.microsoft.com/fwlink/?LinkId=214134. -->
<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
  <appSettings file="app.settings.release" xdt:Transform="SetAttributes">
  </appSettings>
</configuration>

``<?xml version="1.0" encoding="utf-8" ?>
<!-- For more information on using transformations 
     see the web.config examples at http://go.microsoft.com/fwlink/?LinkId=214134. -->
<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
  <appSettings file="app.settings.tests.integration" xdt:Transform="SetAttributes">
  </appSettings>
</configuration>

As you can see I apply SetAttributes transform for appSettings node, which means that the transformation will replace appSettings node attributes from app.config file with appSettings node attributes from transform file. You can preview results of transformation by clicking Preview Transform context menu option available for every of our transform files

As you've probably already figured it out app.settings.debug and app.settings.release fileses contain real downstream endpoints and app.settings.tests.integration contains addresses of fake endpoints. Of course you have to create those files and copy them to output directory during the build (for instance by using Copy to Output directory option).

3.2. Creating fake downstreams with mountebank

Setting up fake downstream systems completely from scratch would be a very painful and time consuming process. Fortunately there are tools which can make this task easier. The tool I use is called mountebank - you can easily install it via npm

npm install -g mountebank

Having mountebank on board it is time to configure it, so that it acts as fake Pricer service. It can be done in couple of ways but I will go with file based configuration. You can run the tool using following command

mb --configfile impostors.ejs --allowInjection

Where impostors.ejs is a configuration file with following structure

{
  "imposters": [
    <% include pricer.json %>
  ]
}

<% include pricer.json %> is EJS syntax which (in this case) allows you to split configuration into multiple files. As you've probably already figured it out, Pricer.json contains the actual mock configuration for Pricer service. The initial mock object consists of couple of properties which setup the name, port and protocol for given mock.

{
  "port": 4545,
  "protocol": "http",
  "name": "pricer stub",
  "stubs": []
}

Note that we do not specify the address of mock but just a port. Mountebank by default runs on http://localhost:2525 and mocks listen on http://localhost:{port}. The actual magic happens in stubs property. Here is an example of stub/mock for GetTradingDates method.

{
    "responses": [
      {
        "is": {
          "body": {
            "MaturityDate": "2016-02-17",
            "SettlementDate": "2012-02-23"
          }
        }
      }
    ],
    "predicates": [
      {
        "equals": {
          "path": "/GetTradingDates",
          "method": "GET"
        },
      }
    ]
}

As you can see stub object consists of two properties

responses
predicates

responses property is an array of objects mountebank will be using to create a response. If you insert multiple items into array, they will be utilized using round robin algorithm. Note that you don't have to create a full response (with all the headers etc.) just use "is" property which will fill the default values for you. More about that topic can be found here but in most of the cases setting value for "body" property will be enough for you.

predicates property is an array of predicates which will be used during matching process. Predicate object can be quite complex, it supports lots of different matching techniques. In this case, for simple GET method I just use equals operator to match HTTP verb and HTTP method. The same technique can be used for stubbing POST methods. However, in this case, you can also perform matching against the body of the request. The one thing you have to remember is that body property is not an object but string. So in my case, if I want to make a stub for GetPrice which takes as params following request object

public class GetPriceRequest
{
    public bool IsAdvised { get; set; }
}

I can write for instance this stub

{
    "responses": [
      {
        "is": {
          "body": {
            "Id": "1",
            "Strike": "1"
          }
        }
      }
    ],
    "predicates": [
      {
        "equals": {
          "path": "/GetPrice",
          "method": "POST",
          "body": "{\"IsAdvised\":false}"
        }
      }
    ]
}

Of course for more complex request it is pointless to write every possible combination of params. Fortunately you can create fallback/default stub which will match everything

{
    "responses": [
      {
        "is": {
          "body": {
            "Id": "default",
            "Strike": "1"
          }
        }
      }
    ],
    "predicates": [
      {
        "equals": {
          "path": "/GetPrice",
          "method": "POST"
        }
      }
    ]
}

If you put this at the very end of stubs array it will not interfere with other stubs. This is of course just a tip of the iceberg when it comes to predicate matching. Explanation of all possible matching options can be found here

4. Results

From now on running tests against test.integration compilation profile and having mountebank working in the background, our tests will be green.

Source code for this post can be found here

Using async/await with IAsyncResult pattern

Fri, 12 Feb 2016 17:45:14 GMT

Even though in my current project we use .NET 4.5 we still have lots of references to internal libraries targeting .NET 4.0. Usually it is not a problem, however some of these libraries follow Asynchronous Programming Model pattern. This approach makes the code quite ugly because we end up with lots of nested callbacks.

// rest of the code omitted for brevity
private static void GetHostEntryIAsyncResultPattern()
{
    DnsService dnsService = new DnsService();
    dnsService.BeginGetHostEntry(GoogleHost, googleAsyncResult =>
    {
        var googleHostResult = dnsService.EndGetHostEntry(googleAsyncResult);
        Console.WriteLine($"Result from IAsyncResultPattern: {GoogleHost} - {FormatHostEntry(googleHostResult)}");
        dnsService.BeginGetHostEntry(YahooHost, yahooAsyncResult =>
        {
            var yahooHostResult = dnsService.EndGetHostEntry(yahooAsyncResult);
            Console.WriteLine($"Result from IAsyncResultPattern: {YahooHost} - {FormatHostEntry(yahooHostResult)}");
        }, null);
    }, null);
}
// rest of the code omitted for brevity

Fortunately thanks to Task.Factory.FromAsync method it is possible to quite easily make Begin/End methods work with async/await pattern. All you have to do is to pass Begin/End methods as an arguments to Task.Factory.FromAsync and you are good to go. The original code after refactoring looks like that

// rest of the code omitted for brevity
var dnsService = new DnsService();
var googleHostResult = await Task.Factory.FromAsync((callback, stateObject) => dnsService.BeginGetHostEntry(GoogleHost, callback, stateObject), dnsService.EndGetHostEntry, null);
Console.WriteLine($"Result from async/await: {GoogleHost} - {FormatHostEntry(googleHostResult)}");

var yahooHostResult = await Task.Factory.FromAsync((callback, stateObject) => dnsService.BeginGetHostEntry(YahooHost, callback, stateObject), dnsService.EndGetHostEntry, null);
Console.WriteLine($"Result from async/await: {YahooHost} - {FormatHostEntry(yahooHostResult)}");
// rest of the code omitted for brevity

I think everyone will agree with me that refactored version is much better than original one.

Source code for this post can be found here

EntityFramework - SQLException during database migration

Sun, 07 Feb 2016 13:10:54 GMT

Recently I've been doing some small refactoring of my pet project. Nothing too fancy - just namespace adjustment, variables and class renaming etc. However it turned out that even these minor changes can in fact be major ones. All of the sudden most of my integration tests started failing due to SQLException.

I am using Code First approach so I didn't take me too much time to realize that for some reasons EntityFramework wanted to create already existing tables. I started looking into the way EF keeps track of the changes in the model and it turned out that it creates special table called __MigratoinHistory

One of the most important columns in there is column called ContextKey, which identifies the class which describes migration policy. In my case this class originally looked that way

namespace EFAutoupgradeException.Data
{
    public class AutoupgradeExceptionMigrationConfiguration : DbMigrationsConfiguration<AutoupgradeExceptionDbContext>
    {
        public AutoupgradeExceptionMigrationConfiguration()
        {
            this.AutomaticMigrationsEnabled = true;
            this.AutomaticMigrationDataLossAllowed = true;
        }
    }
}

In that case value of the ContextKey column matches the full name of the class

EFAutoupgradeException.Data.AutoupgradeExceptionMigrationConfiguration

The class after refactoring was slightly changed and now it looks that way

namespace EFAutoupgradeExceptions.Data
{
    public class AutoupgradeExceptionMigrationConfiguration : DbMigrationsConfiguration<AutoupgradeExceptionDbContext>
    {
        public AutoupgradeExceptionMigrationConfiguration()
        {
            this.AutomaticMigrationsEnabled = true;
            this.AutomaticMigrationDataLossAllowed = true;
        }
    }
}

It is easy to overlook the change but now, full name of the class is

# Exceptions as in plural compared to singular previously
EFAutoupgradeExceptions.Data.AutoupgradeExceptionMigrationConfiguration

so EF loses the information about the migration and tries to migrate once again from the scratch. Fortunately there is an easy fix for that which doesn't require dropping the database. All you have to do is to write simple update statement which set the proper ContextKey value.

USE EFAutoupgradeException
UPDATE [__MigrationHistory]
SET
[ContextKey] = 'EFAutoupgradeExceptions.Data.AutoupgradeExceptionMigrationConfiguration'
WHERE [ContextKey] LIKE '%AutoupgradeExceptionMigrationConfiguration'

Source code for this post can be found here

Abusing collection initializers

Mon, 01 Feb 2016 18:03:10 GMT

Most of .NET developers are familiar with collection initializers syntax. Long story short, this language feature allows you to replace this ugly syntax

var numbers = new List<int>();
numbers.Add(1);
numbers.Add(2);
numbers.Add(3);
numbers.Add(4);

with much shorter and cleaner one

var numbers = new List<int> { 1, 2, 3, 4 };

The more interesting thing is the fact that you can leverage this syntax not only for build-in collections but also for your custom classes. In order to do that your class must implement IEnumerable interface and expose public Add method. Let's assume that we have some real case scenario and we have class which looks like that

public class StatusMessages : IEnumerable<StatusMessage>
{
    private List<StatusMessage> messages = new List<StatusMessage>();

    public IEnumerator<StatusMessage> GetEnumerator()
    {
        return this.messages.GetEnumerator();
    }

    IEnumerator IEnumerable.GetEnumerator()
    {
        return this.messages.GetEnumerator();
    }
}

public class StatusMessage
{
    public string Text { get; set; } = string.Empty;
    public string SourceSystem { get; set; } = string.Empty;
    public int StatusCode { get; set; }

    public StatusMessage()
    {
    }

    public StatusMessage(string text)
    {
        this.Text = text;
    }

    public override string ToString()
    {
        return $"Text: {this.Text} StatusCode: {this.StatusCode} SourceSystem: {this.SourceSystem}";
    }
}

This is a simple wrapper over the List. At this moment we can't use collection initializer when constructing objects of this classs. However by adding method Add

public class StatusMessages : IEnumerable<StatusMessage>
{
    // rest of the code omitted for brevity
    public void Add(StatusMessage message)
    {
        this.messages.Add(message);
    }
    // rest of the code omitted for brevity
}

we can create a new instance of that class just like we would do with List

var messagesAddInitializer = new StatusMessages
            {
                new StatusMessage("y"),
                new StatusMessage("x"),
            };

What is more, it is possible to have multiple overloads of Add method in our class, so for instance if we add

public class StatusMessages : IEnumerable<StatusMessage>
{
    // rest of the code omitted for brevity
    public void Add(string text)
    {
         this.Add(new StatusMessage(text));
    }
    // rest of the code omitted for brevity
}

we are able to use this syntax

var messagesAddStringInitializer = new StatusMessages
            {
                "y",
                "x"
            };

In addition it is even possible to use a mix of Add overloads

var messagesAddAndTextInitializers = new StatusMessages
            {
                new StatusMessage("y"),
                "x"
            };

Add method can also have multiple arguments

public class StatusMessages : IEnumerable<StatusMessage>
{
    // rest of the code omitted for brevity
    public void Add(int statusCode, string text)
    {
        this.Add(new StatusMessage(text) { StatusCode = statusCode });
    }
    
    public void Add(int statusCode, string text, string sourceSystem)
    {
        this.Add(new StatusMessage(text) { StatusCode = statusCode,SourceSystem = sourceSystem });
    }
    // rest of the code omitted for brevity
}

in that case we are able to use this syntax

var messagesMultipleArgumentsInitializers = new StatusMessages
            {
                { 1, "x" },
                {1,"x","source" }
            };

The last thing I would like to point out is that Add function doesn't have to be an instance method, we can easily implement it as an extension method and still leverage the collection initializer syntax.

namespace AbusingCollectionInitializers
{
    public static class StatusMessagesExtensions
    {
        public static void Add(this StatusMessages statusMessages, int statusCode)
        {
            statusMessages.Add(new StatusMessage() { StatusCode = statusCode });
        }
    }
}

Now with proper namespace import we can write this code

using AbusingCollectionInitializers;
// rest of the code omitted for brevity
var messagesExtensionInitializers = new StatusMessages { 1,2,3 };

Source code for this post can be found here

Easy way to suppress code analysis warnings

Mon, 10 Aug 2015 19:12:00 GMT

Everyone who has ever been using a code analysis knows that sometimes it is hard to follow the Microsoft coding guidelines and it is necessary to suppress some warnings. For me it always was a painful operation because I didn't know any automated way of doing that. So basically I had to find the warning in the MSDN, copy category, code and other necessary stuff and then manually add appropriate attribute in code. Fortunately a friend of mine yesterday showed me a simple trick to generate this attribute with couple of mouse clicks. All you have to do is to right-click on warning message and choose Suppress Message context menu ...

There are two options in there. The first option - In Source, will add attribute directly in the code

and the second one - In Suppression File, will create GlobalSuppressoins.cs file with assembly attribute which suppresses given warning in entire assembly

TPL - exception handling and UnobservedTaskException issue

Mon, 10 Aug 2015 19:12:00 GMT

1. Introduction

Working with Tasks is a modern way of writing asynchronous code in an easy and flexible manner. It is quite straightforward to start using them, so usually developers do not investigate thoroughly the topic. Unfortunately this often leads to unpleasant surprises - especially when it comes to exception handling. Having this in mind let's take a look how to handle exceptions in Task and what can happen if we do it wrong.

2. Exception handling

Because of the fact that Tasks are run asynchronously we can't just use a standard try catch block surrounding Task

public static void TryCatchBlockWrongWay()
{
    try
    {
        Task.Factory.StartNew(() => { throw new Exception("From method TryCatchBlockWrongWay"); });
    }
    catch (Exception ex)
    {
        // this will never be hit
        Console.WriteLine("Exception handled {0}", ex);
    }
}

In that case catch block is unreachable (I will describe later what happens with that exception), of course we could use try catch inside Task.Factory.StartNew lambda expression but this is not always the case. Usually we want to handle exception in the caller of the Task, not inside the Task itself. There are couple of ways of achieving that - depending on the situation you can use one of the following ways. Exception are propagated to caller once you start waiting for the result of Task. So basically you can use try catch block if you wait for a Task to finish - either by accessing Result property or using Wait method

public static void HandleExceptionTryCatchResult()
{
    try
    {
        var task = Task.Factory.StartNew(() =>
        {
            throw new Exception("From method HandleExceptionTryCatchResult");
            return 1;
        });
        // do more stuff while task is running
        // do more stuff while task is running
        // do more stuff while task is running
        var result = task.Result;
    }
    catch (Exception ex)
    {
        Console.WriteLine("HandleExceptionTryCatchResult: exception handled in try catch block. Exception is {0}", ex);
    }
}

public static void HandleExceptionTryCatchWait()
{
    try
    {
        var task = Task.Factory.StartNew(() => { throw new Exception("From method HandleExceptionTryCatchWait"); });
        // do more stuff while task is running
        // do more stuff while task is running
        // do more stuff while task is running
        task.Wait();
    }
    catch (Exception ex)
    {
        Console.WriteLine("HandleExceptionTryCatchWait: exception handled in try catch block. Exception is {0}", ex);
    }
}

However accessing Result or calling Wait method are blocking calls, so this might not be a perfect solution for every scenario. Fortunately we can also leverage ContinueWith method which gives you an ability to specify what should be done once Task finishes processing the operation. What is more important you can configure this method to only be called if exception occurs. Nonetheless there is one crucial thing you have to remember - in order to make exception handled or observed you have to access Exception property of Task...

public static void HandleExceptionContinueWith()
{
    Task.Factory.StartNew(() => { throw new Exception("From method HandleExceptionContinueWith"); })
                .ContinueWith(val =>
                {
                    // we need to access val.Exception property otherwise unobserved exception will be thrown
                    // ReSharper disable once PossibleNullReferenceException
                    foreach (var ex in val.Exception.Flatten().InnerExceptions)
                    {
                        Console.WriteLine("HandleExceptionContinueWith: exception handled in ContinueWith. Exception is {0}", ex);
                    }
                }, TaskContinuationOptions.OnlyOnFaulted);
}

or call Handle method from AggregateException object

public static void HandleExceptionContinueWithAndHandleMethod()
{
    Task.Factory.StartNew(() => { throw new Exception("From method HandleExceptionContinueWith"); })
                .ContinueWith(val =>
                {
                    val.Exception.Handle(ex =>
                    {
                        Console.WriteLine("HandleExceptionContinueWith: exception handled in AggregateException.Handle. Exception is {0}", ex);
                        return true;
                    });
                }, TaskContinuationOptions.OnlyOnFaulted);
}

Otherwise exception will not be handled which may cause a lot of troubles described in section 3 of this post. Lastly if you use .NET 4.5 you can also just use async await and try catch block

// called from Main
public static async void HandleExceptionTryCatchAwait()
{
    try
    {
        await HandleExceptionTryCatchAwaitInternal();
    }
    catch (Exception ex)
    {
        Console.WriteLine("HandleExceptionTryCatchAwait: exception handled in try catch block");
    }
}

private static async Task<int> HandleExceptionTryCatchAwaitInternal()
{
    return await Task.Factory.StartNew(() =>
    {
        throw new Exception();
        return 1;
    }, TaskCreationOptions.LongRunning);
}

3. Handling UnobservedTaskException

If it happens that exception thrown by Task is not handled, once the Task is garbage-collected, finalizer thread will throw UnobservedTaskException.

Task.Factory.StartNew(() => { throw new Exception("fire-and-forget no exception handling"); });
using (var autoresetEvent = new AutoResetEvent(false))
{
    //wait for task to run
    autoresetEvent.WaitOne(TimeSpan.FromSeconds(2));
}

Console.WriteLine("GC: Collecting");
GC.Collect();
GC.WaitForPendingFinalizers();
Console.WriteLine("GC: Collected");

The implication of this depends on framework we are running our application on. If you run your app on .NET 4.5 or later version, with default escalation policy, TaskScheduler.UnobservedTaskException event will be raised and basically that is all. No more further problems, so basically you may not even realize that there is something like UnobservedTaskException. However if we add this entry

<runtime>
    <ThrowUnobservedTaskExceptions enabled="true"/>
</runtime>

to app.config our process will be killed once UnobservedTaskExceptionis is thrown.

The problem arises in .NET 4.0 (if you run your app on .NET 4.0 not only compile it against this framework version), in this version of framework default escalation policy is very strict and will kill our process once the UnobservedTaskException is thrown by finalizer thread. Furthermore you cannot change this policy using app.config. Fortunately there is a one last chance to handle UnobservedExceptions and prevent our process from being killed. All you have to do is to wire up TaskScheduler.UnobservedTaskException static event handler and then set exception to observed state

TaskScheduler.UnobservedTaskException += TaskScheduler_UnobservedTaskException;
private static void TaskScheduler_UnobservedTaskException(object sender, UnobservedTaskExceptionEventArgs e)
{
    e.SetObserved();
}

There is one more thing to clarify. You can compile your library against .NET 4.0 but if you have .NET 4.5 installed on your machine, your application is launched and run on .NET 4.5. This means that escalation policy from .NET 4.5 will be used - so by default process will not be killed. In order to simulate pure .NET 4.0 behavior while having .NET 4.5 installed you have to add

<runtime>
    <ThrowUnobservedTaskExceptions enabled="true"/>
</runtime>

in your app.config as it was mentioned before. Otherwise you would have to uninstall .NET 4.5 in order to, for example reproduce production issue.

Source code for this post can be found here

C# - testing internal classes

Sun, 26 Jul 2015 09:23:00 GMT

I am currently involved in writing library which will be used by couple of external teams. In that library we have a quite a lot classes which are only used internally and won't be a part of public API. The natural way of keeping that code inaccessible for other assemblies is to use internal access modifier. However this makes the code also inaccessible directly for testing. Of course you can still test your internal code through public API but usually this is inconvenient and forces you to write a lot of additional code in test. This is particularly painful for me, because our build process requires 100% test coverage. Fortunately there is an easy way to make internal classes visible for certain assemblies without making them public. All you have to do is to use InternalsVisibleToAttribute and specify assembly name which is allowed to use code with internal access modifier. This attribute is most commonly added to AssemblyInfo.cs file. For example, assuming that my library is in TestingInternalClasses.Lib assembly and my tests are in TestingInternalClasses.Tests I should add

[assembly: InternalsVisibleTo("TestingInternalClasses.Tests")]

to AssemblyInfo.cs located in TestingInternalClasses.Lib project. However you can also use this attribute in a class definition file - just like that

using System;
using System.IO;
using System.Runtime.CompilerServices;
[assembly: InternalsVisibleTo("TestingInternalClasses.Tests")]

namespace TestingInternalClasses.Lib
{
    internal class VanillaSerializer : ISerializer
    {
        public Stream Serialize(object obj)
        {
            if (obj == null)
                throw new ArgumentNullException(nameof(obj));

            // rest of the code
            // ...
            // ...
        }

        public T Deserialize<T>(Stream stream)
        {
            if (stream == null)
                throw new ArgumentNullException(nameof(stream));

            // rest of the code
            // ...
            // ...
        }
    }
}

From now on I can easily test internal classes from TestingInternalClasses.Lib project in TestingInternalClasses.Tests. Source code for this post can be found here

WCF - exposing metadata over TCP

Sun, 28 Jun 2015 15:10:00 GMT

I think that everyone who has ever been working with WCF knows that we can enable metadata exchange by adding ServiceMetadataBehavior to App.config file

<behaviors>
     <serviceBehaviors>
       <behavior>
         <serviceMetadata httpGetEnabled="true"></serviceMetadata>
       </behavior>
     </serviceBehaviors>
</behaviors>

Up until yesterday the build in solution works fine for me. However recently I've had to expose metadata over TCP protocol. ServiceMetadataBehavior doesn't have something like TcpGetEnabled property so in order to expose metadata over other protocols (in my case TCP) it is necessary to add custom MEX endpoint.

<system.serviceModel>
    <services>
          <service name="AudioLib.Services.AudioService">
            <endpoint address="AudioService/MEX" binding="mexTcpBinding" contract="IMetadataExchange">
    <!-- application endpoints -->
            <host>
              <baseAddresses>
                <add baseAddress="net.tcp://localhost:8080"></add>
              </baseAddresses>
            </host>
          </endpoint>
        </service>
    </services> 
    <!-- rest of the config -->
</system.serviceModel>

The endpoint configuration has to have a specific binding - in my case mexTcpBinding (there are of course MEX bindings available for other protocols). What is more, the contract has to be set to IMetadataExchange. The address value is up to us, we can use full blown address as well as leverage base address. At this point if we run service we will get the exception

Even though we added custom endpoint for metadata exchange we still have to use ServiceMetadataBehavior. This time however we can skip httpGetEnabled property

<!-- rest of the config -->
<serviceBehaviors>
        <behavior>
          <serviceMetadata httpgetenabled="true"></serviceMetadata>
        </behavior>
</serviceBehaviors>
<!-- rest of the config -->

From now on we can access metadata over TCP

Source code for this post can be found here

Gulp - exluding type definitions files from TypeScript linting

Sat, 13 Jun 2015 16:35:00 GMT

I wanted to improve a code quality of my TypeScript project, so I decided to add linting to my gulp build process. My original build task looked pretty straightforward

function buildTypeScript() {
    return gulp.src(['app/**/*.ts','typings/**/*.ts'])
               .pipe(sourcemaps.init())
               .pipe(ts({
                   sortOutput: true,
                   noExternalResolve: true,
                   noEmitOnError: true,
                   target: 'ES5'
               }))
               .pipe(concat(constants.appall))
               .pipe(sourcemaps.write())
               .pipe(gulp.dest(paths.app));
}

and according to gulp-tslint manual adding linting requires including only two additional lines of code

.pipe(tslint())
.pipe(tslint.report('verbose'));

This works fine until you start using type definitions (d.ts files) from external resources (which is the usual way of combining TypeScript with existing JavaScript libraries). Usually these files have different code styling rules than our own, which means that our build will fail.

There are couple of ways of solving this problem. The obvious one is to split the task into two separate tasks, one for linting and one for building, but in my opinion a much cleaner way is to use gulp-filter. Gulp-filter has an ability to filter the stream on the fly, but what is more interesting it can also restore it to previous unfiltered state. Using these two features we can filter the stream from d.ts files before linting process begins and then restore the stream and pass it to TypeScript compiler. We can do it with two additional lines of code. Improved build script is presented below

function buildTypeScript() {
    // include all typescript files but exclude definitions
    var filter = gulpFilter(['**/*.ts', '!**/*d.ts']);

    return gulp.src(['app/**/*.ts','typings/**/*.ts'])
               .pipe(filter)    // use the filter
               .pipe(tslint())
               .pipe(tslint.report('prose', {
                   emitError: true
               }))
               .pipe(filter.restore()) // clear filter
               .pipe(sourcemaps.init())
               .pipe(ts({
                   sortOutput: true,
                   noExternalResolve: true,
                   noEmitOnError: true,
                   target: 'ES5'
               }))
               .pipe(concat(constants.appall))
               .pipe(sourcemaps.write())
               .pipe(gulp.dest(paths.app));
}

Source code for this post can be found here

C# - dynamic type can be useful

Sat, 16 May 2015 09:29:00 GMT

I am not a big fan of dynamic type in C#, however there are certain situations in which it can be handy. Let's assume that we have following piece of code (which I encounter quite often at my work)

public abstract class Weapon
{
    //some properties
}

public class Gun : Weapon
{
     //some properties
}

// more derived types

var weaponService = new WeaponService();
IList<TransferObjects.Weapon> data = weaponService.GetWeapons();
List<Models.Weapon> weapons = data.Select(WeaponConverter.Convert).ToList();

As you can see we have to convert DTO objects into normal objects using some kind of converter. This is not a problematic when you can use some auto-mappings libraries (Automapper,FastMapper) however I am not allowed to do that in a company I work for. So the question is how to write WeaponConverter.Convert method in some elegant way. The obvious way (but definitely not elegant) is just to use lots of if statements

public static Models.Weapon ConvertOld(TransferObjects.Weapon weapon)
{
    if (weapon == null)
        return null;
        
    if (weapon is TransferObjects.Gun)
        return ConvertInternal((TransferObjects.Gun) weapon);
        
    if (weapon is TransferObjects.Sword)
        return ConvertInternal((TransferObjects.Sword) weapon);
        
    throw new ArgumentException("Unknown weapon", nameof(weapon));
}
// ConvertInternal implementation goes here for every derived type

But this is really ugly, much better idea (at least from my point of view) is to leverage dynamic keyword introduced in .NET 4. Thanks to it our Convert method can be reduced to this

public static Models.Weapon Convert(TransferObjects.Weapon weapon)
{
    return weapon != null ? ConvertInternal((dynamic)weapon) : null;
}

// ConvertInternal implementation goes here for every derived type

Source code for this post can be found here

Nested properties initialization - syntactic sugar

Sat, 18 Apr 2015 19:11:00 GMT

I think most of developers are familiar with the object syntax initializer, which basically allows you to set up values of properties just like that

var webClient = new CustomWebClient
            {
                Settings = new CustomWebClientSettings
                {
                    Encoding = "UTF-8",
                    Method = "POST"
                }
            };

In this example the Settings property is assigned with new instance of CustomWebClientSettings class. However for time to time we only want to change particular property of given nested property and leave rest of the object intact. Of course we can write it usual way

// we assume that CustomWebClient initialized Settings property in constructor
var webClient = new CustomWebClient();
webClient.Settings.Encoding = "UTF-8";
webClient.Settings.Method = "POST";

but there is a much cooler syntax for that. The code above can be rewritten to

var webClient = new CustomWebClient
            {
                 Settings = {Encoding = "UTF-8", Method = "POST"}
            };

Note that there is no new keyword in the assignment of Settings property, which means that the Settings object is updated with the values of properties in braces. Of course this syntax can be safely used only if the nested property(in this case Settings) is initialized up front in constructor, otherwise you will get NullReferenceException.

Source code for this post can be found here

Using ECMAScript6 today

Sun, 12 Apr 2015 10:48:00 GMT

1. Introduction

Although ECMAScript6 has not been officially released yet, we can play around with new language features today. There are tools such as Traceur or Babel which are able to convert ECMAScript6 into ECMASciprt5, thus we are able to run the code in every browser. So let's try to run the snippet below, which leverages destructuring assignment using those tools

(function () {
    var obj = {
        firstProp: 1,
        secondProp: 2
    }, array = [1, 2, 3];

    //Destructuring array
    var [x,y,z] = array;

    console.log('Destructuring array');
    console.log('Value of x = ' + x);
    console.log('Value of y = ' + y);
    console.log('Value of z = ' + z);

    console.log('Destructuring object');
    var { secondProp: b,firstProp: a } = obj;
    console.log('Value of firstProp = ' + a);
    console.log('Value of secondProp = ' + b);

}());

2. Using `Traceur`

I'll start from Traceur first. First of all we have to install it, so run in console (I am using gulp as my build system)

npm install gulp-traceur --save-dev

Then we have to write simple gulp task which:

grabs all of our js files
runs the code analysis using JsHint
transpiles source files into valid ECMAScript5
concatenates the result into single file
generates source maps (for debugging proposes)

var gulp = require('gulp');
var sourcemaps = require('gulp-sourcemaps');
var traceur = require('gulp-traceur');
var concat = require('gulp-concat');
var jshint = require('gulp-jshint');

return gulp.src('app/*.js')
           .pipe(jshint())
           .pipe(jshint.reporter('jshint-stylish'))
           .pipe(jshint.reporter('fail'))
           .pipe(sourcemaps.init())
           .pipe(traceur())
           .pipe(concat('app.all.js'))
           .pipe(sourcemaps.write('.'))
           .pipe(gulp.dest('dest'));

Having our result file ready, now we can add a script tag in html pointing to app.all.js. However at this point in the runtime we will get an error.

$traceurRuntime is not defined

Quick look at the generated app.all.js file reveals the problem

"use strict";
(function() {
  var $__1,
      $__2;
  var obj = {
    firstProp: 1,
    secondProp: 2
  },
      array = [1, 2, 3];
  var $__0 = array,
      x = ($__1 = $__0[$traceurRuntime.toProperty(Symbol.iterator)](), ($__2 = $__1.next()).done ? void 0 : $__2.value),
      y = ($__2 = $__1.next()).done ? void 0 : $__2.value,
      z = ($__2 = $__1.next()).done ? void 0 : $__2.value;
  console.log('Destructuring array');
  console.log('Value of x = ' + x);
  console.log('Value of y = ' + y);
  console.log('Value of z = ' + z);
  console.log('Destructuring object');
  var $__3 = obj,
      b = $__3.secondProp,
      a = $__3.firstProp;
  console.log('Value of firstProp = ' + a);
  console.log('Value of secondProp = ' + b);
}());

//# sourceMappingURL=app.all.js.map

Transpiled code has references to $traceurRuntime objects, so in order to make our code work, we have to add additional script tag pointing to traceur-runtime.js. You can easily get the sources with bower, just run in console

npm install bower --save-dev
bower install  traceur-runtime

Now everything should work and in console we'll get expected result

As you could see in example above Traceur generates overcomplicated code which makes debugging of the original sources (using source maps) a painful process. Just take a look at the following screenshot

fortunately Babel doesn't seem to have these drawbacks.

3. Using `Babel`

Let's modify our gulp build script to use Babel instead of Traceur

npm install gulp-babel --save-dev

var gulp = require('gulp');
var sourcemaps = require('gulp-sourcemaps');
var babel= require('gulp-babel');
var concat = require('gulp-concat');
var jshint = require('gulp-jshint');

return gulp.src('app/*.js')
           .pipe(jshint())
           .pipe(jshint.reporter('jshint-stylish'))
           .pipe(jshint.reporter('fail'))
           .pipe(sourcemaps.init())
           .pipe(babel())
           .pipe(concat('app.all.js'))
           .pipe(sourcemaps.write('.'))
           .pipe(gulp.dest('dest'));

And basically that all, we are ready to go. Babel doesn't require any runtime dependencies, generated code is simple

'use strict';

(function () {
    var obj = {
        firstProp: 1,
        secondProp: 2
    },
        array = [1, 2, 3];

    //Destructuring array
    var x = array[0];
    var y = array[1];
    var z = array[2];

    console.log('Destructuring array');
    console.log('Value of x = ' + x);
    console.log('Value of y = ' + y);
    console.log('Value of z = ' + z);

    console.log('Destructuring object');
    var b = obj.secondProp;
    var a = obj.firstProp;

    console.log('Value of firstProp = ' + a);
    console.log('Value of secondProp = ' + b);
})();
//# sourceMappingURL=app.all.js.map

and even source maps seem to work correctly.

So when it comes to me I choose Babel.

Source code for this post can be found here

Azure - connecting to Windows 10 virtual machine

Wed, 11 Mar 2015 19:15:00 GMT

Today just a quick tip, which may save you some time. If you want to connect to virtual machine with Windows 10 Technical Preview, make sure that you include DNS name in user name field. So instead of default combination of username and password

which worked for me for every virtual machine (except for the one with Windows 10). You should use something like that

If You don't know the DNS name for virtual machine, you can easily check it in Virtual Machines pane

AngularJS - extending existing services using decorator

Wed, 25 Feb 2015 23:24:00 GMT

One of the features I miss the most in AngularJS is ability to easy unsubscribe event handlers. There is no convenience function opposed to $on, so in order to unsubscribe event, we have to call method returned by $on function

(function () {
    angular.module('app.download', [])
        .controller('downloadCtrl', downloadController);

    function downloadController($scope) {
        // keep the unsubscribe function in local variable
        var afterRenderUnsubscribe = $scope.$on('afterRender', onAfterRender);

        function onAfterRender() {
            console.log('CallingonAfterRender');
            // unsubscribe form event
            afterRenderUnsubscribe();
        }
    }
}());

However in my opinion this approach fails in real life scenarios, because usually we are subscribed to more than one event - thus we have to have multiple local variables for detaching listeners. Fortunately AngularJS provides an easy way to extend existing services with some new functionalities - we can achieve that by using $provide service. This service exposes decorator method, which is able to intercept creation of any service, so we are able to augment it with some new functions. The best moment to call $provide.decorator method is during module configuration, thanks to this approach we are sure that our custom logic is invoked before module is started.

angular.module('app.common', [])
       .config(extendServices);

/*ngInject*/
function extendServices($provide) {
    $provide.decorator('serviceName', function ($delegate) {
     /*some interception logic*/
    });
}

In my case I wanted to extend $rootScope with new method $un for unsubscribing events, so I called method decorator with parameter '$rootScope' (note single quotation marks) - this tells Angular that I will be modifying $rootScope service

angular.module('app.common', [])
    .config(extendServices);

/*ngInject*/
function extendServices($provide) {
    $provide.decorator('$rootScope', extendRootScope);
}

/*ngInject*/
function extendRootScope($delegate) {
}

Because I passed '$rootScope' as a first argument of $provide.decorator method, the $delegate parameter in extendRootScope function is actually a $rootScope service. Now having access to the service I can augment it with my custom logic for detaching event handlers.

/*ngInject*/
function extendRootScope($delegate){
    $delegate.$un=function(name,listener){
        var namedListeners=this.$$listeners[name],
            idx;
        if(namedListeners&&(idx=namedListeners.indexOf(listener))>-1){
            namedListeners.splice(idx,1);
        }
    };
    return $delegate;
}

Entire code listing looks then as follows

(function () {
    angular.module('app.common', [])
           .config(extendServices);

    /*ngInject*/
    function extendServices($provide)
    {
        $provide.decorator('$rootScope', extendRootScope);
    }

    /*ngInject*/
    function extendRootScope($delegate)
    {
        $delegate.$un = function (name, listener) {
            var namedListeners = this.$$listeners[name],
                idx;
            if (namedListeners && (idx = namedListeners.indexOf(listener)) > -1) {
                namedListeners.splice(idx, 1);
            }
        };
        return $delegate;
    }
}());

From now on, you can unsubscribe events handlers simply by calling $un method

(function () {
    angular.module('app.download', ['app.common'])
        .controller('downloadCtrl', downloadController);

    function downloadController($scope) {
        $scope.$on('afterRender', onAfterRender);

        function onAfterRender() {
            console.log('Calling afterRender handler');
            $scope.$un('afterRender', onAfterRender);
        }
    }
}());

and our listener will react only once

console.log('Broadcasting afterRender event for the first time');
$rootScope.$broadcast('afterRender');
console.log('Broadcasting afterRender event for the second time');
$rootScope.$broadcast('afterRender');

Source code for this post can be found here

WinJS - AuthenticateAndContinue and "remote procedure call failed" exception

Thu, 19 Feb 2015 22:11:00 GMT

A while ago I started playing around a bit with JavaScript on Windows Phone. I wanted to create very simple app using AngularJS but of course I also had to use some WinJS features (for integration with device ). One of the things I needed to implement was authentication/authorization using OAuth. According to WinJS documentation it should be pretty straightforward - just use Windows.Security.Authentication.Web.WebAuthenticationBroker.authenticateAndContinue method with appropriate URLs. Of course I wanted authentication/authorization to be called before navigating to any screen, so I slightly modified default WinJS template and my code looked like that

// rest of code omitted for brevity
var activation = Windows.ApplicationModel.Activation,
    app = WinJS.Application,
    nav = WinJS.Navigation,
    sched = WinJS.Utilities.Scheduler,
    ui = WinJS.UI;

 app.addEventListener("activated", function (args) {
        if (args.detail.kind === activation.ActivationKind.launch) {
            if (args.detail.previousExecutionState !== activation.ApplicationExecutionState.terminated) {
                // TODO: This application has been newly launched. Initialize
                // your application here.
            } else {
                // TODO: This application has been reactivated from suspension.
                // Restore application state here.
            }

            nav.history = app.sessionState.history || {};
            nav.history.current.initialPlaceholder = true;

            var p = ui.processAll().then(function() {
                Windows.Security.Authentication.Web.WebAuthenticationBroker.authenticateAndContinue(
                        requestUrl, // for instance facebook auth url
                        callbackUrl // for instance facebook auth callback url
                    );
            });
            args.setPromise(p);
        }
    });
// rest of code omitted for brevity

Unfortunately all I got was this strange exception

The exception itself originated somewhere from WinJS framework so I wasn't able to debug it at all. It took me a while to figure this out but after all it turned out, that all you have to do, to make it work is to schedule call of AuthenticateAndContinue method using WinJS.Utilities.Scheduler

WinJS.Utilities.Scheduler.schedule(function(){ //your code in here});

After this change entire code listing looks like that

// rest of code omitted for brevity
var activation = Windows.ApplicationModel.Activation,
   app = WinJS.Application,
   nav = WinJS.Navigation,
   sched = WinJS.Utilities.Scheduler,
   ui = WinJS.UI;

app.addEventListener("activated", function (args) {
       if (args.detail.kind === activation.ActivationKind.launch) {
           if (args.detail.previousExecutionState !== activation.ApplicationExecutionState.terminated) {
               // TODO: This application has been newly launched. Initialize
               // your application here.
           } else {
               // TODO: This application has been reactivated from suspension.
               // Restore application state here.
           }
           
           nav.history = app.sessionState.history || {};
           nav.history.current.initialPlaceholder = true;
           
           var p = ui.processAll().then(function() {
               return sched.schedule(function() {
                   Windows.Security.Authentication.Web.WebAuthenticationBroker.authenticateAndContinue(
                       requestUrl, // for instance facebook auth url,
                       callbackUrl // for instance facebook auth callback url
                   );
               });
           });
           
           args.setPromise(p);
       }
   });
// rest of code omitted for brevity

After this procedure we should be successfully redirected to the requestUrl, in my case to Facebook login page

AngularJS - dependency injection

Mon, 16 Feb 2015 19:39:00 GMT

There are couple of ways of injecting dependencies into AngularJS components. The most common one is just to specify the dependency name in the function's argument list

(function() {
    angular
        .module('app')
        .controller('shellCtrl', function ($scope, $http) {
            $scope.title = "Title";
        });
})();

However this technique fails in real life scenarios, because for production we usually (or rather always) minify and uglify javascript files. Uglify proces renames our variables and due to the fact that dependencies are resolved by name, AngularJS is not able to find appropriate services, directives etc. To overcome this limitation, we can enclose our function definition into an array, and specify dependencies as a string literals. Our original code becomes then

(function () {
    angular.module('app')
           .controller('shellCtrl', ['$scope', '$http', function ($scope, $http) {
               $scope.title = "Title";
           }]);
})();

Although this works fine even after minifying and uglifiyng js files, for me this code is hard to read. That is why I like to use yet another technique. This technique leverages variable hoisting and $inject property

(function(){
    angular.module('app')
           .controller('shellCtrl',shellController);

    shellController.$inject=['$scope','$http'];

    function shellController($scope,$http){
        $scope.title='title';
    }
})();

As You can see I extracted controller function into separate variable shellController and listed all necessary dependencies in $inject array

shellController.$inject= ['$scope','$http']

It is even possible to enhance a bit this example and make it a little less error prone. With the current implementation we have to make sure that order of properties in $inject array is the same as in function declaration. It is easy to keep track of that if we have just a couple of dependencies, but it might be a bit of a pain if we start to add, remove or edit them. Fortunately we can automate this task and basically autogenerate $inject array. In order to do that I like to use Gulp (although it is also possible to use Grunt). First of all we have to install Gulp. There is great tutorial how to do that in here. Having Gulp on board we have to install additional packages: gulp-rename and gulp-ng-annotate. In order to do that type into command line

npm install gulp-ng-annotate --save-dev
npm install gulp-rename --save-dev

Now we can create gulp.js file which should look more or less like that

var rename = require('gulp-rename'),
    ngAnnotate = require('gulp-ng-annotate');

gulp.task('annotate', function () { //create new task 'annotate'
    return gulp.src('app/layout/controllers/shellController.js') //select files to process
        .pipe(ngAnnotate()) // add angularjs dependeny injection annotation
        .pipe(rename('app.all.js')) //rename in-memory stream to app.all.js
        .pipe(gulp.dest('.build'));//save stream to new location
})

We can run this task typing into command line

gulp annotate

And as a result our original code (notice lack of dependeny annotations - no $inject arrray)

(function() {
    angular.module('app')
           .controller('shellCtrl', shellController);

    function shellController($scope, $http) {
        $scope.title = 'title';
    }
})();

Will be transformed into

(function(){
    angular.module('app')
           .controller('shellCtrl',shellController);

    function shellController($scope,$http){
    }
    
shellController.$inject=["$scope","$http"];
})();

Fixing empty SQL server list in "Entity Data Model Wizard"

Mon, 10 Nov 2014 15:23:00 GMT

I consider myself as a quite experienced user of Nhibernate, that is why I decided to check what is going on on the other side of barricade and started playing with Entity Framework. I followed the steps of some tutorial and I stuck at the very beginning of it. I was about to generate model classes using Entity Data Model Wizard but it turned out that the wizard could not find my SQL server (despite the fact that server itself was up and running).

I remember having similar issue a while back, but at that time I wasn't able to solve it (I ended up creating connections string manually). This time I wanted to give this issue a closer look. After a bit of digging I found the problem - the SQL server wasn't broadcasting information about itself. In order to fix it and make the server visible to other computers and applications it is necessary to start SQL Server Browser service. To do that go to Start -> Run and type Services.msc

Then in newly opened window find SQL Server Browser service

Double click it and set up startup type to Automatic. You can also click Start button to make sure that service starts immediately

From now on SQL servers should be visible in Entity Data Model Wizard

T-SQL - syntactic sugar for updating current row in cursor

Sat, 01 Nov 2014 20:05:00 GMT

I am not a big fan of cursors, however for time to time I have to write one. In my case cursor usually is responsible for some complicated updates. Until yesterday I've been writing my update statements within the cursor the standard way

-- cursor code omitted for brevity
-- some complicated update
UPDATE Person.Person set FirstName = 'some logic goes here' where Person.BusinessEntityID = @Id
where @Id variable is set by cursor. 
-- cursor code omitted for brevity

There is nothing wrong with that, however we can do the same thing using specialized syntax - current of keyword(s)

UPDATE Person.Person set FirstName = 'some logic goes here' where current of personCursor

The entire cursor statement then looks that way

DECLARE personCursor CURSOR FOR SELECT top 1000 * FROM Person.Person
OPEN personCursor
FETCH NEXT FROM personCursor
WHILE @@FETCH_STATUS = 0
BEGIN
   -- some complicated update goes here
   UPDATE Person.Person set FirstName = 'some logic goes here' where current of personCursor
   FETCH NEXT FROM personCursor
END
CLOSE personCursor
DEALLOCATE personCursor

T-SQL - executing query multiple times

Mon, 27 Oct 2014 21:56:00 GMT

For time to time during my everyday work I have to do some SQL query optimization. The simplest way of measuring whether my changes improved the performance or not, is simply measure the execution time of given query (I know that this is not the best way of doing that, but let's leave aside execution plans for now). However measuring time of single executin is not very meaningfull. Thats why I like execute query multiple times by using this simple trick

GO 100

and then calculate an average time of execution by dividing the total time by execution count. As You can see, all You have to do is to specify execution count after the GO statment. Despite the fact that Management Studio indicates that there is an error in the SQL, this is perfectly valid code. Of course You should hide execution results in order to measure only the time of execution, not the time of rendering data. To do that, right click on query window and choose Query Options...

then select Results node and check Discard results after execution

INotifyPropertyChange - notifying about change of all properties at once

Sun, 24 Aug 2014 09:40:00 GMT

Today, working on a new feature for my pet project, I realized that I have to notify the view, that all properties in view model have changed. The most obvious way to achieve that would, of course be to rise PropertyChange event a bunch of times.

protected virtual void OnPropertyChanged(Expression<Func<object>> propertyExpression)
{
   //..
   //implementation
   //..
}

protected virtual void OnPropertyChanged(string propertyName)
{
   //..
   //implementation
   //..
}

public void Refresh()
{
   OnPropertyChanged(() => FirstProperty);
   OnPropertyChanged(() => SecondProperty);
   OnPropertyChanged(() => ThirdProperty);
   //and so on ...
}

This is good solution for one time usage, however I was interested in something more general, something which could be extracted to base view model. Fortunately, it turns out that there is a simple trick to do that. All You have to do is use an empty string or null as a property name. So in my case this comes down to this one-liner

public void Refresh()
{
   OnPropertyChanged(string.Empty);
}

NHibernate - generating WHERE IN … OR … queries

Mon, 18 Aug 2014 10:08:00 GMT

Let's assume that we have a simple table GL_Task which looks like this

I was asked to rewrite simple SQL query

SELECT Id,Name,IdProject FROM GL_Task WHERE Name = 'First task' OR Id IN (3,4 /*more id's to come*/)

using NHibernate's QueryOver API. As simple as it may seem, solution for this particular problem is not straightforward. My first (not so clever) attempt was simply combining WhereRestrictionOn and Where clause

var result = session.QueryOver<Task>().Where(val=> val.Name == "First task")
                                      .WhereRestrictionOn(val=> val.Id)
                                      .IsIn(new []{3,4})
                                      .List();

Of course this query returns wrong data because of the fact, that NHiberante by default "joins" queries using AND operator. So above query will result in generating something like that

SELECT Id,Name,IdProject FROM GL_Task WHERE Name = 'First task' AND Id IN (3,4 /*more id's to come*/)

After a little digging I managed to write appropriate query

var orRestriction = Restrictions.Or(
                         Restrictions.Where<Task>(val => val.Name == "First task"),
                         Restrictions.On<Task>(val => val.Id).IsIn(new[] { 3,4 }));

var result = session.QueryOver<Task>()
                    .Where(orRestriction)
                    .List();

Although this code generates correct SQL, it is hard to use it in case of many OR statements. For example, adding one more OR force us to write

var orRestriction = Restrictions.Or(
      Restrictions.Or(
            Restrictions.Where<Task>(val => val.Name == "First task"),
            Restrictions.On<Task>(val => val.Id).IsIn(new[] {3, 4}) 
       ),
       Restrictions.On<Task>(val => val.Name).IsIn(new[] {"FirstTask", "SecondTask"})
);

var result = session.QueryOver<Task>()
                    .Where(orRestriction)
                    .List();

In my opinion this is a little bit hard to read, so I continued my searching to find more elegant solution. My third attempt was based on Restrictions.Disjunction

var disjunctinos = Restrictions.Disjunction()
                           .Add(Restrictions.Where<Task>(val => val.Name == "First task"))
                           .Add(Restrictions.On<Task>(val => val.Id).IsIn(new[] { 3,4 }));
                           
var result = session.QueryOver<Task>()                    
                    .Where(disjunctinos)                    
                    .List();

This was almost perfect solution. Adding new OR statements do not require us to do function nesting

var disjunctinos = Restrictions.Disjunction()
                          .Add(Restrictions.Where<Task>(val => val.Name == "First task"))
                          .Add(Restrictions.On<Task>(val => val.Id).IsIn(new[] { 3,4 }))
                          .Add(Restrictions.On<Task>(val => val.Name).IsIn(new[] { "FirstTask", "SecondTask" }));

var result = session.QueryOver<Task>()
                    .Where(disjunctinos)
                    .List();

However the ultimate solution is to just add NHibernate.Criterion namespace and use IsIn extension method. This operation simplify our query into single lambda expression

var result = session.QueryOver<Task>()
                    .Where(val => val.Name == "First task" || val.Id.IsIn(new[] { 3,4 }))
                    .List();

Source code for this post can be found here

Resharper - localizable string literals

Sun, 17 Aug 2014 13:17:00 GMT

Everyone who has ever tried to create multilingual application knows, that this is very tedious task. The most repetitive work is usually moving hard-coded strings to resource files. Fortunately with Resharper this is definitelly less painfull than usuall. In order to point out localizable parts of application , it is necessary to decorate classes with System.ComponentModel.LocalizableAttribute.

However, usually we want to localize an entire program, so more universal solution is to set appropriate project configuration in properties window. To bring up this window, select project file and then press F4 button.

From now on, Resharper shows warnings indicating that our hard-coded strings might be moved to resource file. Pressing ALT+ENTER on these strings will bring up the context menu action, where new option - Move to resource is available.

Choosing this option will bring up the Move to Resource window. However if we do not have any resource files in our project, we will get this message.

In order to create these files, right click on project and choose Add->New Item. Now, select Resource.resx file and name it for example LocalizableStrings.resx.

In this resource file we will store values for our default language. Supporting more languages require us to create additional LocalizableString files with appropriate LETF tags suffixes.

Now, we are able to move our hard-coded string to resource files.

By default Resharper adds hard-coded strings to default resource file, so we have to specify values for localizable string for other languages. In order to do that, first navigate to resource entry in LocalizableStrings.resx file by holding CTRL and clicking property Program_Main_This_is_localizable_string

and then press ALT+ENTER and choose Override 'PropertyName…'. This operation brings up Edit Resource window where You can easily navigate between resource files and update given resource property

Resharper not only is able to move strings to resource files but also can use existing ones. This basically means that if we use hard-coded string which already has been added to resource file, Resharper will suggest to use predefined resource

NHhibernate - multiple queries in one roundtrip to server

Sun, 27 Apr 2014 22:14:00 GMT

Usually when we need to retrieve data from database server, we write code which looks like that

using (var session = DataAccesLayer.Instance.OpenSession())
{
    using (var transaction = session.BeginTransaction())
    {
        var projects = session.QueryOver<Project>().Where(val => val.Name == "Project").List();
        var tasks = session.QueryOver<Task>().Where(val => val.Name == "First task").List();
        //more queries           
        //more queries             
        //exception handling etc.
    }
}

This code will execute two queries,each of them in separate roundtrip to the server.

This is the most popular way of getting data for multiple tables etc. However it is possible to enhance the code above and execute several queries in only one roundtrip to the database server. NHibernate provides us with three different mechanisms to accomplish this goal:

MultiQuery

First way to execute several queries at once is MultiQuery. In my opinion this is not very handy mechanism because of the fact, that we must use HQL. Here is an example of usage

var projectQuery = session.CreateQuery("FROM Project as prj where prj.Name= :projectName")
                          .SetParameter("projectName", "Project");

var taskQuery = session.CreateQuery( "FROM Task as tsk where tsk.Name=:taskName" )
                       .SetParameter("taskName","First task");
 
var multiQueryByIndex = session.CreateMultiQuery( )
                               .Add<Project>( projectQuery )
                               .Add<Task>( taskQuery );

As You can see thanks to CreateMultiQuery method we are able to aggregate multiple queries. In order to get access to results, we have to execute code below

var result = multiQueryByIndex.List();

Now we can get result of specific query using indexer

var projects = result[0] as List<Project>;
var tasks = result[1] as List<Task>;

If we don't like this approach, the CreateMultiQuery method has an overload which allows to give "names" to queries. Thanks to this we can get result of query by its name.

var multiQueryByKey = session.CreateMultiQuery( )
                             .Add<Project>( "project", projectQuery )
                             .Add<Task>( "task", taskQuery );
 
var projects = multiQueryByKey.GetResult( "project" ) as List<Project>;
var tasks = multiQueryByKey.GetResult( "task" ) as List<Task>;

MultiCriteria

Much better way of creating multiple queries is MultiCriteria. In this case we can use QueryOver API, so we don't have to rely on HQL query strings.

var projectQuery = session.QueryOver<Project>().Where(val => val.Name == "Project");
var taskQuery = session.QueryOver<Task>( ).Where(val => val.Name == "First task");
var multiCriteriaByIndex = session.CreateMultiCriteria( )
                                  .Add( projectQuery )
                                  .Add( taskQuery );

var multiCriteriaByKey = session.CreateMultiCriteria( )
                                .Add( "project", projectQuery )
                                .Add( "task", taskQuery );

IList result = multiCriteriaByIndex.List( );
var projects = result[0] as List<Project>;
var tasks = result[1] as List<Task>;

projects = multiCriteriaByKey.GetResult( "project" ) as List<Project>;
tasks = multiCriteriaByKey.GetResult( "task" ) as List<Task>;

As You can see the usage of CreateMultiCriteria method is pretty consistent with CreateMultiQuery. Unfortunately we still have to retrieve data from specific query by index or by query name.

Future

My personal favorite for creating multi queries is Future. The usage is pretty straightforward

var projects = session.QueryOver<Project>().Where(val => val.Name == "Project").Future<Project>();
var tasks = session.QueryOver<Task>().Where(val => val.Name == "First task").Future<Task>();

As You can see, we can leverage QueryOver API and instead of calling List we call Future. NHibernate will aggregate our queries and will execute them once we start to iterate over one of them.

Despite the fact that all three mechanism has completely different syntax ,SQL created by all of them is the same and looks like that

Resharper - "Go to Everything"

Thu, 17 Apr 2014 19:50:00 GMT

In Resharper 8 JetBrains introduced new command called Go to Everything. You can use it by hitting the CTRL + N keys (CTRL + T with Visual Studio keyboard shortcuts layout) This command is basically combination of three features known from previous versions of Resharper, namely: Go to Class, Go to Type and Go to Symbol. Most common usage of this functionality is just to search classes, properties or functions.

However not everyone knows, that we can narrow down search criteria and find methods or properties in given class

What is even more interesting, is the fact that it is possible to go to specific line in searched type

Resharper - annotation attributes

Sun, 02 Mar 2014 16:39:00 GMT

1. Introduction

I think one of the most important features of Resharper is on-the-fly code quality analysis. Basically, every time Resharper finds possible pitfall in code, it indicates this with appropriate warning. The most common warning is "Possible System.NullReferenceException". You can easily reproduce it by writing this code

List<object> objlList = new List<object>( );
var result = objlList.SingleOrDefault( );
Console.WriteLine( result.GetHashCode( ) );

As you can see R# is able to figure out, that LINQ SingleOrDefault function can return null. However there is no warning if we try to do something like that

private static void DisplayHashCode()
{
    var result = Foo();
    Console.WriteLine( result.GetHashCode( ) );
}

private static object Foo()
{
    return null;
}

So it got me thinking, how Resharper recognizes whether or whether not to show warnings. It turned out, that it uses annotation attributes, which describe behavior of functions, properties, classes and interfaces.

2. Source code annotations

In order to use these attributes we have to place them in our project. First of all, let's create Annotation.cs file and then copy default implementation of annotations into this file. The default implementation can be found in Code annotation option (Resharper->Options->Code Inspections->Code Annotations) under the button Copy default implementation to clipboard.

From now on we can decorate our functions with e.g. CanBeNull attribute

private static void DisplayHashCode()
{
    var result = Foo();
    Console.WriteLine( result.GetHashCode( ) );
}
       
[CanBeNull]
private static object Foo()
{
    return null;
}

and we will get warning if necessary

Of course there are a lot more of attributes to use. My favorites are:

StringFormatMethodAttribute

PathReferenceAttribute

NotifyPropertyChangedInvocatorAttribute

3. External code annotations

In case we do not have access to source code, we still are able to use annotation attributes. However we have to define annotations in xml configuration file. Let's say we want to decorate NHibernte's SaveOrUpdate function with NotNullAttribute. First of all we have to create xml file with appropriate declaration (This is standard XML Document Comment file. You can read specification here and here)

<assembly name="NHibernate">
    <member name="M:NHibernate.ISession.SaveOrUpdate(System.Object)">
        <parameter name="obj">
            <attribute ctor="M:JetBrains.Annotations.NotNullAttribute.#ctor" />
        </parameter>
    </member>
</assembly>

Having prepared configuration file, we need to place it in appropriate location in order for Resharper to use it. It can be stored in

[ReSharper install directory]\Bin\ExternalAnnotations\[Assembly name].xml
[ReSharper install directory]\Bin\ExternalAnnotations\[Assembly name][Any name].xml.

So in my case the location is C:\Program Files (x86)\JetBrains\ReSharper\v8.1\Bin\ExternalAnnotations\NHibernateNHibernate.xml

After restarting Visual Studio, Resharper should load the file and show warning messages.

4. Generating initial XML annotation files

Creating xml annotation file for large library is very tedious task, fortunately Resharper have a hidden feature which can help us with generating initial xml file. First of all we have to run Visual Studio with /ReSharper.Internal parameter. In this mode we have an access to undocumented/hidden features of Resharper. Now, in the Resharper menu there is one additional menu item - Internal, where You can find Annotator submenu in which resides Annotate item.

Now You can specify for which dll Resharper should generate xml annotation file.

and after a while You should get complete xml declaration.

[!WARNING] Please bear in mind, that Annotator is not official R# feature, so there is no guarantee that generating annotation files will succeed.

Source code for this post can be found here

Implementing INotifyPropertyChanged without lambda expressions and "magic" strings

Sun, 19 Jan 2014 20:31:00 GMT

I think almost every .NET developer is familiar with INotifyPropertyChanged interface. Typical implementation of this interface looks more or less like that:

public class NotifyPropertyBase : INotifyPropertyChanged
{
    public event PropertyChangedEventHandler PropertyChanged;
    protected virtual void OnPropertyChanged( Expression<Func<object>> propertyExpression )
    {
        PropertyChangedEventHandler handler = PropertyChanged;
        if (handler != null) handler( this, new PropertyChangedEventArgs( GetPropertyName( propertyExpression ) ) );
    }

    private string GetPropertyName( Expression<Func<object>> propertyExpression )
    {
        var unaryExpression = propertyExpression.Body as UnaryExpression;
        var memberExpression = unaryExpression == null ? (MemberExpression)propertyExpression.Body : (MemberExpression)unaryExpression.Operand;
        var propertyName = memberExpression.Member.Name;
        return propertyName;
    }
}

Thanks to lambda expressions we can get rid of so called "magic" strings when rising PorpertyChange event.

private int _myProperty;
public int MyProperty
{
    get { return _myProperty; }
    set
    {
        if (_myProperty == value) return;
        _myProperty = value;
        OnPropertyChanged( ( ) => MyProperty );
    }
}

However, with .NET 4.5 we can even get rid of lambda expressions itself. Everything thanks to CallerMemberNameAttribute, which provides us information about caller of given method. Now we can rewrite NotifyPropertyBase class as follows

public class NotifyPropertyBase : INotifyPropertyChanged
{
    public event PropertyChangedEventHandler PropertyChanged;
    protected virtual void OnPropertyChanged( [CallerMemberName] string propertyName = null )
    {
        PropertyChangedEventHandler handler = PropertyChanged;
        if (handler != null) handler( this, new PropertyChangedEventArgs( propertyName));
    }
}

From this moment we can call OnPropertyChanged method without any arguments

private int _myProperty;
public int MyProperty
{
    get { return _myProperty; }
    set 
    {
      if (_myProperty == value) return;
      _myProperty = value;
      OnPropertyChanged();
    }
}

and thanks to CallerMemberName attribute, argument propertyName will be filled with appropriate value.

Source code for this post can be found here

How to check if one function calls another function

Sun, 01 Dec 2013 18:12:00 GMT

An application which I'm currently developing has quite complicated authorization system. That is why, we can not use role based authorization, and basically every developer is obliged to call appropriate security check method in every controller action he or she writes. As You probably know it is quite easy to forget about that, therefore I decided to write a test which would check whether all controller's action invokes this security critical function. After hours of searching for some anchor point, I came across this article in which author creates so called "reflection based ILReader". ILReader is a class which allows You to iterate over IL instructions of every object of type RuntimeMethodInfo or RuntimeConstructorInfo. One of these instructions is InlineMethodInstruction which indicates method call. That is why, in order to get all methods which are called by given method, we have to simply select all instructions of type InlineMethodInstruction

public static class MethodInvokerCrawler
{
    public static IEnumerable<MethodBase> GetMethods(MethodBase caller)
    {
        ILReader reader = new ILReader(caller);
        return reader.OfType<InlineMethodInstruction>().Select(method => method.Method);
    }
}

We can go a bit further and create a recursive version of this function to iterate over entire function execution chain

public static class MethodInvokerCrawler
{
    public const string DefaultPrefix = "GeneralLearning";
    public static IEnumerable<MethodBase> GetMethods(MethodBase caller, bool recursive = false, string namespacePrefix = DefaultPrefix)
    {
        ILReader reader = new ILReader(caller);
        foreach (InlineMethodInstruction method in
            reader.OfType<InlineMethodInstruction>())
        {
            yield return method.Method;
            if (recursive && method.Method.DeclaringType != null && method.Method.DeclaringType.FullName.StartsWith(namespacePrefix, StringComparison.InvariantCultureIgnoreCase))
            {
                foreach (var innerMethod in GetMethods(method.Method))
                {
                    yield return innerMethod;
                }
            }
        }
    }
}

Please notice, that I limited recursion depth to methods from user defined namespace, otherwise we would end up iterating over .NET's native functions.

Now it is time to show some results. Here is a sample program which demonstrate possibilities of MethodInvokerCrawler class

internal class Program
{
    public class FooClass
    {
        public FooClass()
        {
            this.X();
            this.Foo();
            this.Bar();
        }

        public void Foo(){}

        public void Bar()
        {
            this.Z();
            this.Foo();
        }

        public string X()
        {
            return null;
        }

        public void Y(){ }

        public void Z()
        {
            this.Y();
        }
    }

    public static void Main(string[] args)
    {
        Console.WriteLine("=== execution chain of Bar function no recursion ===");
        foreach (var s in MethodInvokerCrawler.GetMethods(typeof(FooClass).GetMethod("Bar")))
        {
            Console.WriteLine("{0}.{1}", s.DeclaringType.FullName, s.Name);
        }

        Console.WriteLine();
        Console.WriteLine("=== execution chain of Bar function with recursion ===");
        foreach (var s in MethodInvokerCrawler.GetMethods(typeof(FooClass).GetMethod("Bar"), true))
        {
            Console.WriteLine("{0}.{1}", s.DeclaringType.FullName, s.Name);
        }

        Console.WriteLine();
        Console.WriteLine("execution chain of FooClass default constructor no recursion");
        foreach (var s in MethodInvokerCrawler.GetMethods(typeof(FooClass).GetConstructors().Single()))
        {
            Console.WriteLine("{0}.{1}", s.DeclaringType.FullName, s.Name);
        }

        Console.WriteLine();
        Console.WriteLine("execution chain of FooClass default constructor with recursion");
        foreach (var s in MethodInvokerCrawler.GetMethods(typeof(FooClass).GetConstructors().Single(), true))
        {
            Console.WriteLine("{0}.{1}", s.DeclaringType.FullName, s.Name);
        }
        Console.ReadKey();
    }
}

At this point checking whether function or constructor calls another function is limited to simple LINQ query

MethodInvokerCrawler.GetMethods(typeof(FooClass).GetMethod("Bar")).Any(val => val.Name == "Foo");

Source code for this post can be found here

Extjs - vertical header in grid and locked columns

Sun, 10 Nov 2013 21:09:00 GMT

A while ago I wrote an article where I described how to create a plugin, which can flip header of Ext.panel.Grid vertically. I've been using this plugin for a couple of months in a company I work for, however in the last week it turned out that this extension does not work for grid with locked columns. After digging into Extjs source code I found out that when You use locked columns, the grid is created as a combination of two grids: normalGrid and lockedGrid. Therefore it is necessary to apply vertical-header plugin to these two grids separately. In order to do that, I improved this extension to detect if grid has locked columns or not. The main change is in init function which now looks that way

init: function (grid) {
      var me = this;
      me.grid = grid;
      me.grid.addCls('v-vertical-header-grid');
      me.textMetric = new Ext.util.TextMetrics();

      if (me.isLocked()){
          var normalGridPlugin = Ext.create('GeneralLearning.ux.VerticalHeader',me.extraCfg),
              lockedGridPlugin = Ext.create('GeneralLearning.ux.VerticalHeader',me.extraCfg);
              normalGridPlugin.init(me.grid.normalGrid);
              lockedGridPlugin.init(me.grid.lockedGrid);
              me.grid.normalGrid.plugins.push(normalGridPlugin);
              me.grid.lockedGrid.plugins.push(lockedGridPlugin);
      } else {
          me.grid.on({
              afterlayout: {
                  scope: me,
                  fn: me.handleAfterLayout
              }
          });
      }
}

In the first step I check if columns are locked. The method for do that is pretty straightforward

isLocked: function () {
          var me = this;
          return me.grid.normalGrid && me.grid.lockedGrid;
}

Afterward I do create two instances of vertical-header plugin and initialize them with appropriate partial grid (lockedGrid or normalGrid). Entire code listing is presented below

Ext.define('GeneralLearning.ux.VerticalHeader', {
    alias: 'plugin.verticalheader',
    grid: null,
    extraCfg:null,
    textMetric: null,
    init: function (grid) {
        var me = this;
        me.grid = grid;
        me.grid.addCls('v-vertical-header-grid');
        me.textMetric = new Ext.util.TextMetrics();

        if (me.isLocked()) {
            var normalGridPlugin = Ext.create('GeneralLearning.ux.VerticalHeader',me.extraCfg),
                lockedGridPlugin = Ext.create('GeneralLearning.ux.VerticalHeader',me.extraCfg);
                normalGridPlugin.init(me.grid.normalGrid);
                lockedGridPlugin.init(me.grid.lockedGrid);
                me.grid.normalGrid.plugins.push(normalGridPlugin);
                me.grid.lockedGrid.plugins.push(lockedGridPlugin);

        } else {
            me.grid.on({
                afterlayout: {
                    scope: me,
                    fn: me.handleAfterLayout
                }
            });
        }
    },

    constructor: function (cfg) {
        var me = this;
        me.extraCfg = cfg;
        Ext.apply(this, cfg);
        me.callParent(arguments);
    },

    handleAfterLayout: function (cmp) {
        var me = this,
            maxWidth = 0,
            headerItems = cmp.headerCt.items,
            curremtWidth;

        headerItems.each(function (item) {
            if ((curremtWidth = me.textMetric.getWidth(item.text)) > maxWidth) {
                maxWidth = curremtWidth + 10;
            }
        });

        cmp.headerCt.el.select('.x-column-header-text').each(function (el) {
            el.setSize(maxWidth, maxWidth);
        });
    },

    isLocked: function () {
        var me = this;
        return me.grid.normalGrid && me.grid.lockedGrid;
    }

});

Source code for this post can be found here

Generating string consisting of the same character

Sun, 03 Nov 2013 14:45:00 GMT

Recently I've been asked by friend of mine, how to generate string consisting of 50 commas. I came up with these three code snippets:

var repeat = string.Join(string.Empty, Enumerable.Repeat(",", 50));
var aggregate = Enumerable.Range(1, 50).Aggregate(new StringBuilder(), 
                                                 (acc, seed) => acc.Append(",")).ToString();
var usingArray = string.Join(",", new string[51]);//must be 51, separator is not inserted after last index

Although all of these lines produce appropriate outcome, it's seemed to me that there is some simpler way to accomplish this task. After a little bit of searching, it turned out, that it is possible to generate string consisting of same characters using one of string's constructors

var usingConstructor = new string(',', 50);

NHibarnate - using event listeners to set entity modification date

Sat, 24 Aug 2013 23:04:00 GMT

I think, that it is a common practice to store information about creation and modification date of entities. However keeping appropriate columns up to date manually is error prone. We must remember that every time we modify entity, we also have to change its modification date. Fortunately thanks to event listeners, NHibernate can do all of this boring stuff for us. Let's start from creating class which implements two interfaces:

IPreInsertEventListener
IPreUpdateEventListener

public class NHListener : IPreInsertEventListener, IPreUpdateEventListener
{
    public bool OnPreInsert(PreInsertEvent @event)
    {
        throw new NotImplementedException();
    }

    public bool OnPreUpdate(PreUpdateEvent @event)
    {
        throw new NotImplementedException();
    }
}

As You probably guessed OnPreInsert method is invoked before insert, and OnPreUpdate is called before update of entity. Having prepared the basic skeleton of class, it is time to configure NHibernate to use our event listeners. The basic configuration is taken from my previous post about NHibernate automappings, so I will only extend it by appending event listeners

Fluently.Configure().Database(
                    MsSqlConfiguration.MsSql2008.ConnectionString(
                        @"YourConnectionString"))
                    .Mappings(val => val.AutoMappings.Add(CreateAutomappings))
                    .ExposeConfiguration(val =>
                    {
                        val.AppendListeners(ListenerType.PreUpdate, new IPreUpdateEventListener[] { new NHListener() });
                        val.AppendListeners(ListenerType.PreInsert, new IPreInsertEventListener[] { new NHListener() });
                    })
                    .BuildSessionFactory();

Now we can put some logic into OnPreInsert and OnPreUpdate functions. First of all we have to somehow identify entities which hold information about creation and modification time. In order to do that I created simple interface IDateInfo

public interface IDateInfo
{
    DateTime ModificationDate { get; set; }
    DateTime CreationDate { get; set; }
}

In the next step we have to modify OnPreInsert and OnPreUpdate methods, so that they can set creation and modification date of entities which implement IDateInfo interface.

public class NHListener : IPreInsertEventListener, IPreUpdateEventListener
{
    public bool OnPreInsert(PreInsertEvent @event)
    {
        IDateInfo dateInfo;
        if ((dateInfo = @event.Entity as IDateInfo) != null)
        {
            var currentDate = DateTime.Now;
            dateInfo.CreationDate = dateInfo.ModificationDate = currentDate;
        }
        return false;
    }

    public bool OnPreUpdate(PreUpdateEvent @event)
    {
        IDateInfo dateInfo;
        if ((dateInfo = @event.Entity as IDateInfo) != null)
        {
            var currentDate = DateTime.Now;
            dateInfo.ModificationDate = currentDate;
        }
        return false;
    }
}

Unfortunately at this moment saving entity (which implements IDateInfo interface) will throw exception

Despite the fact that we set values of ModificationDate and CreationDate properties , NHiberante seems not to notice that. That is why we have to manually update values of State object from PreInsertEvent and PreUpdateEvent. According to the documentation State object from class PreInsertEvent holds values which should be inserted and State object from class PreUpdateEvent holds values which should be updated. Function which update values of state object might look like that

private void SetState(IEntityPersister persister, object[] state, string propertyName, object value)
{
    var index = Array.IndexOf(persister.PropertyNames, propertyName);
    if (index == -1)
        return;
    state[index] = value;
}

Updated NHListener class now looks like that

using System;
using System.Linq.Expressions;
using NHibernate.Event;
using NHibernate.Impl;
using NHibernate.Persister.Entity;

namespace DataAccessLayer
{
    public class NHListener : IPreInsertEventListener, IPreUpdateEventListener
    {
        private static readonly string ModificationDatePropertyName = GetPropertyName<IDateInfo>(val => val.ModificationDate),
                                       CreationDatePropertyName = GetPropertyName<IDateInfo>(val => val.CreationDate);

        public bool OnPreInsert(PreInsertEvent @event)
        {
            IDateInfo dateInfo;
            if ((dateInfo = @event.Entity as IDateInfo) != null)
            {
                var currentDate = DateTime.Now;
                dateInfo.CreationDate = dateInfo.ModificationDate = currentDate;
                SetState(@event.Persister, @event.State, ModificationDatePropertyName, currentDate);
                SetState(@event.Persister, @event.State, CreationDatePropertyName , currentDate);
            }
    
            return false;
        }
    
        public bool OnPreUpdate(PreUpdateEvent @event)
        {
            IDateInfo dateInfo;
            if ((dateInfo = @event.Entity as IDateInfo) != null)
            {
                var currentDate = DateTime.Now;
                dateInfo.ModificationDate = currentDate;
                SetState(@event.Persister, @event.State, ModificationDatePropertyName, currentDate);
            }
            return false;
        }
        
        private void SetState(IEntityPersister persister, object[] state, string propertyName, object value)
        {
            var index = Array.IndexOf(persister.PropertyNames, propertyName);
            if (index == -1)
                return;
            state[index] = value;
        }
    
        private static string GetPropertyName<TType>(Expression<Func<TType, object>> expression)
        {
            return ExpressionProcessor.FindPropertyExpression(expression.Body);
        }
    }
}

As You can see, after setting values of IDateInfo I also call function SetState and update state of appropriate properties. From now everything works fine and our entities can be saved without problems.

Source code for this post can be found here

Extjs - vertical header in grid

Sun, 30 Jun 2013 10:55:00 GMT

Extjs doesn't provide us with any build-in mechanism for flipping text vertically in grid's header. Fortunately we can achieve this effect by using a mixture of CSS rules and some javascript code. In order to make code more reusable, I'll write it as a plugin for grid. Let's start from creating CSS rules responsible for text rotation

.v-vertical-header-grid .x-column-header  .x-column-header-text {
   display:block;
   margin-left:auto;
   margin-right:auto;
   text-align: left;
   -webkit-transform: rotate(-90deg);     
   -moz-transform: rotate(-90deg);     
   -o-transform: rotate(-90deg);    
   -ms-transform: rotate(-90deg); /* IE  */                             
}

.x-column-header .x-column-header-text is a selector for header text in every Extjs grid. It is obvious that we want only certain grids to have vertical headers, that is why I extended selector with additional custom class .v-vertical-header-grid. Having CSS class prepared, now we can write actual plugin.

Ext.define('GeneralLearning.ux.VerticalHeader', {
    alias: 'plugin.verticalheader',
    grid: null,
    textMetric: null,
    init: function (grid) {
        var me = this;
        me.grid = grid;
        me.grid.addCls('v-vertical-header-grid');
        me.textMetric = new Ext.util.TextMetrics();
        me.grid.on({
            afterlayout: {
                scope: me,
                fn: me.handleAfterLayout
            }
        });
    },

    constructor: function (cfg) {
        Ext.apply(this, cfg);
    },

    handleAfterLayout: function (cmp) {
        var me = this,
            maxWidth = 0,
            headerItems = cmp.headerCt.items,
            curremtWidth;

        headerItems.each(function (item) {
            if ((curremtWidth = me.textMetric.getWidth(item.text)) > maxWidth) {
                maxWidth = curremtWidth + 10;
            }
        });

        cmp.headerCt.el.select('.x-column-header-text').each(function (el) {
            el.setSize(maxWidth, maxWidth);
        });
    }
});

At the very beginning .v-vertical-header-grid class is added to the grid. Thanks to this, CSS selector created in the first step is able to select text in header. At this point text is rotated, however it can't fit into header - its size didn't change. That is why in function handleAfterLayout I manually measure text height using Ext.util.TextMetrics and change height of header. Solution presented above works fine in IE10, Opera, Firefox and Chrome. There were some problems in IE9, however extending CSS class with these rules

.v-vertical-header-grid .x-column-header {
    background-image: -ms-linear-gradient(rgb(249, 249, 249), rgb(227, 228, 230)) !important;
    filter: progid:DXImageTransform.Microsoft.gradient(GradientType=0,startColorstr='#F9F9F9', endColorstr='#E3E4E6');

}
  
.v-vertical-header-grid .x-grid-header-ct {
    background-image: -ms-linear-gradient(rgb(249, 249, 249), rgb(227, 228, 230)) !important;
    filter: progid:DXImageTransform.Microsoft.gradient(GradientType=0,startColorstr='#F9F9F9', endColorstr='#E3E4E6');
}

did the trick. Here is the result

Source code for this post can be found here

[!WARNING] There is a problem with this plugin and locked columns, please see the updated version of this plugin here

Extjs - drag-and-drop between tables

Wed, 22 May 2013 22:08:00 GMT

Extjs framework provides us with two helper classes responsible for performing drag-drop operation:

Ext.dd.DragZone

The most important element of this class is getDragData function, which provides data for drag operation. It is necessary for this method to return object with ddel property containing DOM element, from which draging operation was originated.
Ext.dd.DropZone

This class has two important methods. The first one is getTargetFromEvent which informs if drop operation should be performed. The other one is onNodeDrop which is responsible for actual drop operation.

Having covered the basics, let's try to implement drag-drop operation. Let's start from creating simple container with two tables.

Ext.define('GeneralLearning.views.DragAndDropView', {
    extend:'Ext.container.Container',
    renderTpl:Ext.create('Ext.Template',
     '<div id="table_container">',
        '<table id="leftTable" style="margin: 20px 20px">',
             '<tr>',
                '<th>a</th>',
                '<th>b</th>',
             '</tr>',
            '<tr>',
                '<td>1</td>',
                '<td>2</td>',
            '</tr>',
            '<tr>',
                '<td>4</td>',
                '<td>9</td>',
            '</tr>',
            '<tr>',
                '<td>16</td>',
                '<td>25</td>',
            '</tr>',
        '</table>',
        '<table id="rightTable" style="margin: 20px 20px">',
             '<tr>',
                '<th>a</th>',
                '<th>b</th>',
             '</tr>',
             '<tr>',
                '<td>1</td>',
                '<td>2</td>',
            '</tr>',
            '<tr>',
                '<td>4</td>',
                '<td>9</td>',
            '</tr>',
            '<tr>',
                '<td>16</td>',
                '<td>25</td>',
            '</tr>',
        '</table>',
    '</div>')
})

In the next step we will create DragZone and DropZone.

createDragDropZones:function () {
    var me = this,
        rightTable = me.el.select('#rightTable').first(),
        leftTable = me.el.select('#leftTable').first();
    Ext.create('Ext.dd.DragZone', rightTable, {
        getDragData:function (e) {
            if (e.target.nodeName == 'TD') {
                var sourceEl = e.target;
                var d = sourceEl.cloneNode(true);
                d.id = Ext.id();
                return {
                    ddel:d,
                    sourceEl:sourceEl,
                    repairXY:Ext.fly(sourceEl).getXY()
                }
            }

        },
        getRepairXY:function () {
            return this.dragData.repairXY;
        }
    });

    Ext.create('Ext.dd.DropZone', leftTable, {
        getTargetFromEvent:function (e) {
            if (e.target.nodeName == 'TD')
                return e.target;
        },
        onNodeEnter:function (target, dd, e, data) {
            Ext.fly(target).addCls('drop-target-hover');
        },
        onNodeOut:function (target, dd, e, data) {
            Ext.fly(target).removeCls('drop-target-hover');
        },
        onNodeOver:function (target, dd, e, data) {
            return Ext.dd.DropZone.prototype.dropAllowed;
        },
        onNodeDrop:function (target, dd, e, data) {
            target.parentNode.replaceChild(dd.dragData.ddel, target)
            return true;
        }
    })
}

As You cas see DragZone was created on the right table. I want to be able to drag only td elements, that is why function getDragData returns null, if drag operation was originated from other HTML element. Extjs will take care of showing approperiate animation, if drag-drop is available. I also overrode getRepairXY method, which is responsible for providing X and Y coordinates for animation, which is fired in case of invalid drop off. The code responsible for handling drop operation is a little bit more complicated. After creating a DropZone from left table, I ovverode getTargetFromEvent method, so as to drop could be performed only to td elements of table. What is more, using onNodeEnter and onNodeOut methods I changed target elements of the drop, to show user where given element will be placed. Actual drop is performed in onNodeDrop method, in my case I just replace HTML node form original one to dropped. Here is a result:

Entire code listing looks like that:

 #table_container table { border: 1px solid black;float:left;width:400px;}
 #table_container td, #table_container th   { border: 1px solid black;}
 
 td.drop-target-hover {
     border-color: yellow !important;
     border-width: 3px !important;
 }

Ext.define('GeneralLearning.views.DragAndDropView', {
    extend:'Ext.container.Container',
    renderTpl:Ext.create('Ext.Template',
     '<div id="table_container">',
        '<table id="leftTable" style="margin: 20px 20px">',
             '<tr>',
                '<th>a</th>',
                '<th>b</th>',
             '</tr>',
            '<tr>',
                '<td>1</td>',
                '<td>2</td>',
            '</tr>',
            '<tr>',
                '<td>4</td>',
                '<td>9</td>',
            '</tr>',
            '<tr>',
                '<td>16</td>',
                '<td>25</td>',
            '</tr>',
        '</table>',
        '<table id="rightTable" style="margin: 20px 20px">',
             '<tr>',
                '<th>a</th>',
                '<th>b</th>',
             '</tr>',
             '<tr>',
                '<td>1</td>',
                '<td>2</td>',
            '</tr>',
            '<tr>',
                '<td>4</td>',
                '<td>9</td>',
            '</tr>',
            '<tr>',
                '<td>16</td>',
                '<td>25</td>',
            '</tr>',
        '</table>',
    '</div>'),

    initComponent:function () {
        var me = this;
        me.callParent(arguments);
        me.on('afterrender', me.createDragDropZones, me);
    },

    createDragDropZones:function () {
        var me = this,
            rightTable = me.el.select('#rightTable').first(),
            leftTable = me.el.select('#leftTable').first();
        Ext.create('Ext.dd.DragZone', rightTable, {
            getDragData:function (e) {
                if (e.target.nodeName == 'TD') {
                    var sourceEl = e.target;
                    var d = sourceEl.cloneNode(true);
                    d.id = Ext.id();
                    return {
                        ddel:d,
                        sourceEl:sourceEl,
                        repairXY:Ext.fly(sourceEl).getXY()
                    }
                }
            },
            getRepairXY:function () {
                return this.dragData.repairXY;
            }
        });

        Ext.create('Ext.dd.DropZone', leftTable, {
            getTargetFromEvent:function (e) {
                if (e.target.nodeName == 'TD')
                    return e.target;
            },
            onNodeEnter:function (target, dd, e, data) {
                Ext.fly(target).addCls('drop-target-hover');
            },
            onNodeOut:function (target, dd, e, data) {
                Ext.fly(target).removeCls('drop-target-hover');
            },
            onNodeOver:function (target, dd, e, data) {
                return Ext.dd.DropZone.prototype.dropAllowed;
            },
            onNodeDrop:function (target, dd, e, data) {
                target.parentNode.replaceChild(dd.dragData.ddel, target)
                return true;
            }
        })
    }
})

Source code for this post can be found here

Fixing missing semicolon issue using WebStorm

Sun, 14 Apr 2013 11:44:00 GMT

Recently in the company I work for, we've been trying to improve Javascript code quality. After hooking up JSlint into our build script, it turned out that the most common issue with our code is missing semicolon at the end of statements. Fixing all warnings manually would be very boring task, that is why I started searching for alternative solution. Fortunatelly once again, WebStorm came for the rescue. As you probably know WebStorm has it's own code inspection tool which indicates problems with code. However except that, this tool can also fix these problems automatically. Here is a little demonstration. Let us start with simple code.

Ext.define('GeneralLearning.controllers.ImageCachingController',{
    extend:'Ext.app.Controller',
    viewInstance:null,
    launch:function(){
        var me = this;
        me.viewInstance = Ext.create('GeneralLearning.views.ImageCachingView');
    },

    getView:function(){
        var me = this
        return me.viewInstance
    }
});

In the listing above, there are two lines with missing semicolon (in function getView). Let fix them using Webstorm code inspection tool. First of all, we have to make sure that appropriate inspection options are selected. In order to do that, let's choose Settings from menu File. In the opened window, go to Settings and select options presented in the picture below.

In the next step, from menu Code choose Inspect code

In the opened window, we can change inspection profile or inspection scope, but usually we can go with default settings

After inspection is done, at the bottom of the screen you will see results

Now, we can quickly fix them by using context menu and clicking Terminate statement

Here is the result of fixing operation

Fluent Nhibernate - automappings

Mon, 25 Mar 2013 18:38:00 GMT

1. Introduction

Writing mappings for models in large application is quite boring task. Fortunatelly, Fluent NHibernate provides possibility for automatic mapping creation - so called automappings.

2. Creating database and model

In order to show you, how to configure automappings in Fluent NHibernate, let's create simple database along with model classes. The database structure is presented in the picture below.

Model classes which represent database tables look this way

public abstract class ModelBase
{
    public virtual int Id { get; set; }
}

public class Project : ModelBase
{
    public virtual string Name { get; set; }
    public virtual User User { get; set; }
    public virtual IList<Task> Tasks { get; set; }
}

public class Task : ModelBase
{
    public virtual string Name { get; set; }
    public virtual Project Project { get; set; }
}

public class User : ModelBase
{
    public virtual string Name { get; set; }
    public virtual string Surname { get; set; }
}

3. Automappings configuration

Having our database and models prepared, now we can create and configure SessionFactory to use automappings.

var factory = Fluently.Configure().Database(MsSqlConfiguration.MsSql2008.ConnectionString("YourConnectionString"))
                      .Mappings(val => val.AutoMappings.Add(AutoMap.AssemblyOf<Project>))
                      .BuildSessionFactory();

As You can see I used the static AutoMap.AssemblyOf method. This method takes a generic type parameter from which Fluent NHibernate can deduce which assembly to look in for mappable entities. From now all classes defined in the assemlby of Project are mapped using build-in convention.

4. Mapping only specified classes

Mapping all classes from specyfic assembly may not be very useful. That is why, we need to "tell" Automapper which classes should be mapped. It can be achieved by creating custom configuration class which implements IAutomappingConfiguration interface or which is subclass of DefaultAutomappingConfiguration. IAutomappingConfiguration interface has quite a lot of functions, that is why I decided to craete class which inherits from DefaultAutomappingConfiguration and override only one method - ShouldMap

public class AutomappingConfiguration : DefaultAutomappingConfiguration
{
    public override bool ShouldMap(Type type)
    {
        return type.IsSubclassOf(typeof (ModelBase));
    }
}

As You can see by overriding ShouldMap function,I specified that only classes which inherit from ModelBase class should be mapped. To use our new configuration, we need to pass an instance of it to AutoMap setup

var factory = Fluently.Configure().Database(MsSqlConfiguration.MsSql2008.ConnectionString("YourConnectionString"))
                      .Mappings(val => val.AutoMappings.Add(AutoMap.AssemblyOf<Project>(new  DefaultAutomappingConfiguration())))
                      .BuildSessionFactory();

5. Defining custom conventions

It is rather obvious that default automapping conventions may not come along with our database naming conventions. Fortunately we can create custom conventions(which override default ones), and pass them to AutoMap configuration. Here are examples of conventions I use IClassConvention - gives us access to properties and functions which allow us to change a default table name format for our entities.

public class DefaultTableNameConvention : IClassConvention
{
    public void Apply(IClassInstance instance)
    {
        instance.Table(string.Format("{0}{1}", "GL_", instance.EntityType.Name));
    }
}

IIdConvention is used for altering default identity conventions.

public class DefaultPrimaryKeyConvention : IIdConvention
{
    public void Apply(IIdentityInstance instance)
    {
        instance.Column("Id");
        instance.GeneratedBy.Native();
    }
}

IPropertyConvention - allows us to modify properties mappings (lazy load, nullability,length etc)

public class DefaultStringLengthConvention : IPropertyConvention
{
    public void Apply(IPropertyInstance instance)
    {
        instance.Length(50);
    }
}

IReferenceConvention - allows us to modify entities relationship convention

public class DefaultReferenceConvention : IReferenceConvention
{
    public void Apply(IManyToOneInstance instance)
    {
        instance.Column(string.Format(instance.Class.Name.StartsWith("Id") ? "{1}" : "{0}{1}", "Id",
                                      instance.Class.Name));
        instance.LazyLoad();
    }
}

IHasManyConvention - allow us to modify default has-many relationship convention

public class DefaultHasManyConvention : IHasManyConvention
{
    public void Apply(IOneToManyCollectionInstance instance)
    {
        instance.Key.Column(string.Format("{0}{1}", "Id", instance.EntityType.Name));
        instance.LazyLoad();
    }
}

In order to use new conventions we need to pass them into AutoMap configuration.

Fluently.Configure()
                .Database(
                    MsSqlConfiguration.MsSql2008.ConnectionString("YourConnectionString"))
                .Mappings(val => val.AutoMappings.Add(AutoMap.AssemblyOf<Project>(new DefaultAutomappingConfiguration()).Conventions.Setup(con =>
                                                                           {
                                                                               con.Add<DefaultTableNameConvention>();
                                                                               con.Add<DefaultPrimaryKeyConvention>();
                                                                               con.Add<DefaultStringLengthConvention>();
                                                                               con.Add<DefaultReferenceConvention>();
                                                                               con.Add<DefaultHasManyConvention>();
                                                                           })))
                .BuildSessionFactory();

6. Overriding mappings

Sometimes it is necessary to slightly modify entity mapping. It can be achieved by creating class which implements IAutoMappingOverride interface

public class ProjectMapping: IAutoMappingOverride<Project>
{
    public void Override(AutoMapping<Project> mapping)
    {
        mapping.IgnoreProperty(val=>val.SomeIgnoredProperty);
    }
}

Override method gives us access to all actions known from fluent mappings. After creating class map, we have to call function UseOverridesFromAssemblyOf in our automapping configuration

var factory = Fluently.Configure()
                      .Database(MsSqlConfiguration.MsSql2008.ConnectionString("YourConnectionString"))
                      .Mappings(val => val.AutoMappings.Add(AutoMap.AssemblyOf<Project>(new DefaultAutomappingConfiguration()).UseOverridesFromAssemblyOf<Project>()
                                  .Conventions.Setup(con => 
                                  {
                                       con.Add<DefaultTableNameConvention>();
                                       con.Add<DefaultPrimaryKeyConvention>();
                                       con.Add<DefaultStringLengthConvention>();
                                       con.Add<DefaultReferenceConvention>();
                                       con.Add<DefaultHasManyConvention>();
                                  }))).BuildSessionFactory();

7. It works

Here just couple of screens from NHibernateProfiler with basic queries

Source code for this post can be found here

Extjs - Changing style of items in dropdownlist

Tue, 19 Mar 2013 18:58:00 GMT

I've recently been asked to create ComboBox with custom styled drop-down list. Colors of items of drop-dow list should be picked based on values of record bounded to given item. After reading some post on Extjs forum, I decided to overwrite default template of drop-down list.

Ext.create('Ext.XTemplate',
                     '<tpl for=".">',
                       '<div class="{[this.getClass(values)]}">{abbr} - {name}</div>',
                     '</tpl>',{
                            getClass: function (rec) {
                                return rec.name == 'Arizona' ? 'x-boundlist-item x-highlighted-item' : 'x-boundlist-item';
                        }
                    }
    )

As You can see I decided to use XTemplate, which (to the contrary to Template) allows to call user defined function. Function getClass from XTemplate will be called for each element in ComboBox's store. The result of this function will be inserted into class attribute of div element, which is resposible for displaying single item in drop-down list. Please notice, that in order to maintain ability to select items from drop-down list, it is necessary to specify x-boundlist-item class in template. Here is example of usage

div.x-highlighted-item {
    background: blue !important; 
}


var states = Ext.create('Ext.data.Store', {
            fields: ['id', 'abbr', 'name'],
            data: [
                { id: 1, abbr: "AL", name: "Alabama" },
                { id: 2, abbr: "AK", name: "Alaska" },
                { id: 3, abbr: "AZ", name: "Arizona" },
                { id: 4, abbr: "AZ", name: "Arizona" },
                { id: 5, abbr: "AZ", name: "Arizona" }
            ]
        });

  Ext.create('Ext.form.ComboBox', {
       fieldLabel: 'Choose State',
       store: states,
       queryMode: 'local',
       valueField: 'abbr',
       displayField: 'name',
       renderTo: Ext.getBody(),
       tpl: Ext.create('Ext.XTemplate',
                '<tpl for=".">',
                  '<div class="{[this.getClass(values)]}">{abbr} - {name}</div>',
                 '</tpl>',
                    {
                        getClass: function (rec) {
                            return rec.name == 'Arizona' ? 'x-boundlist-item x-highlighted-item' : 'x-boundlist-item';
                        }
                    }
    )
});

and the result

Source code for this post can be found here

StringBuilder - removing trailing characters

Sun, 17 Mar 2013 00:03:00 GMT

Today just quick tip about StringBuilder I used to remove last character(s) from StringBuilder using Remove method.

 StringBuilder builder = new StringBuilder("some long text with comma,");
 builder.Remove(builder.Length - 1, 1);

However, recently I've came accross even simpler solution. You just need to lessen the Length property of StringBuilder, in order to get rid of last characters

StringBuilder builder = new StringBuilder("some long text with comma,");
builder.Length--;

Resharper - custom snippet

Sat, 05 Jan 2013 10:28:00 GMT

I think all Resharper users are familiar with snippets. Resharper's snippet basically generates a piece of code, which can be easily customised on the fly. All you have to do is to press TAB, and you can change names of auto-generated variables etc. Today, I decided to write my own snippet, which would make writing unit tests easier. In general, all my unit test methods looks like this

[Test]
public void MethodName_Scenario_ExpectedResult_Test()
{
    // test logic goes in here            
}

So let's write a snippet which will generate a method with this signature. In order to do this, let's choose a Templates Explorer... from the Resharper’s menu.

In the opened window, click on the plus sign and a new tab should appear.

Let's name our snippet test and paste the following code into the main editor.

[Test]
public void MethodName_Scenario_ExpectedResult_Test()
{
           
}

Now, we've created a simplified snippet for generating our test function signature. However, this snippet is not really useful as its user cannot navigate through the underscored chunks. In order to employ the Resharper’s navigation features, we have to slightly modify our snippet. Let's replace the previous code with this one:

[Test]
public void $MethodName$_$Scenario$_$ExpectedResult$_Test()
{
    $END$
}

Please notice that now some parts of the method’s name are written between dollar signs. Thanks to this syntax, the Resharper is able to iterate over these parts and lets us change their names on the fly. $END$ is a special control sequence which tells the Resharper where to stop iteration over variables. At this moment, our snippet is fully functional and we can use it by typing the word test and hitting the TAB button.

ASP.NET MVC - Custom ActionResult - PDFResult

Wed, 26 Dec 2012 15:01:00 GMT

1. Introduction

In the company I'm currently working for, it is a common practice to use Devexpress XtraReports to create all kind of reports. Usually these reports are embedded into html page and used along with DevexpressReportViewer. However, lately I have been asked to open a report as a PDF file, without putting a viewer into a html page.

2. First approach

After some digging, I created an action in controller which looks like this

public void ExportToPdf()
{
    using (MemoryStream stream = new MemoryStream())
    {
        var testReport = new TestReport();
        testReport.CreateDocument();
        testReport.ExportToPdf(stream);
        Response.Clear();
        Response.ContentType = "application/pdf"
        Response.BinaryWrite(stream.ToArray());
    }
}

In the first step I made a new instance of a devexpress report(TestReport), then I called a method CreateDocument which is responsible for creating a content of report. Having prepared the report, I could use the ExportToPdf function which creates a stream in a PDF format. In the last step, I cleared Response property and added an array of bytes into it. I also had to change Response.ContentType to application/pdf in order to inform a browser that I'm sending a PDF file.

3. Second approach - custom ActionResult

The solution presented above works fine, however, I wanted to create something more reusable, that is why I decided to create a custom ActionResult - PDFActionResult. In order to create my own ActionResult, I created a PDFActionResult class which inherits from an abstract ActionResult class.

public class PDFActionResult : ActionResult
{
    private readonly byte[] _byteArray;
    private const string ContentType = "application/pdf";
    
    public PDFActionResult(byte[] byteArray)
    {
        _byteArray = byteArray;
    }
    
    public PDFActionResult(XtraReport report)
    {
        using(MemoryStream stream = new MemoryStream())
        {
            report.CreateDocument();
            report.ExportToPdf(stream);
            _byteArray = stream.ToArray();
        }
    }
    
    public override void ExecuteResult(ControllerContext context)
    {
        var response = context.HttpContext.Response;
        response.Clear();
        response.ContentType = ContentType;
        response.BinaryWrite(_byteArray);
    }
}

As you can see, all logic from the ExportToPdf action was transferred to the PDFActionResult class. Now, all you have to do to return PDF from DevexpressReport is to return the PDFActionResult from your controller action.

public PDFActionResult ExportToPdfUsingCustomResult()
{
    var testReport = new TestReport();
    return new PDFActionResult(testReport);
}

Source code for this post can be found here

Argument validation with attributes and Ninject interceptor

Sun, 21 Oct 2012 15:13:00 GMT

1. Introduction

It is a common practice to validate function arguments before running actual code. Usually validation looks like that:

public  void Update(Car entity)
{
    if(entity ==null)
        throw new ArgumentNullException("entity");
}

There is nothing wrong with this code, however we have to repeat this piece of code in every function. Of course we could create some helper class for argument validation and call approperiate validation function before launching rest of the code

public static class ValidationHelper
{
    public static void CheckNotNull(object entity, string argumentName)
    {
        if (entity == null)
            throw new ArgumentNullException(argumentName);
    }
}

public  void Update(Car entity)
{
    ValidationHelper.CheckNotNull(entity, "entity");
    //rest of the code
}

However I was searching for more universal way for argument validation. That is why, I decided to try function interceptors and attributes.

2. Creating validation attributes

Let's start for creating base attribute

[AttributeUsage(AttributeTargets.Parameter)]
public abstract class ArgumentValidationAttribute : Attribute
{
    public abstract void ValidateArgument(object value, string argumentName);
}

In the next step let's create specialized attribute for "not null" validation. This argument may look this way:

public class NotNullAttribute : ArgumentValidationAttribute
{
    public override void ValidateArgument(object value,string argumentName)
    {
        if (value == null)
            throw new ArgumentNullException(argumentName, string.Format("Value {0} can not be null", argumentName));
    }
}

3. Using IInterceptor interface

That was an easy part, now it's necessary to somehow intercept function execution and run attribute validation. In .NET there is no build-in mechanism to do that,that is why I'll use extension for Ninject - Ninject Interception. First of all we have to add to our project three dll's

Ninject
Ninject.Extensions.Interception
Ninject.Extensions.Interception.LinFu

You can easily add them using NuGet. Having all necessary files added to solution,let's create function interceptor - ValidaitionInterceptor.

public class ValidationInterceptor : IInterceptor
{
    public void Intercept(IInvocation invocation)
    {
        var parameters = invocation.Request.Method.GetParameters();
        for (int index = 0; index < parameters.Length; index++)
        {
            foreach (ArgumentValidationAttribute attr in parameters[index].GetCustomAttributes(typeof(ArgumentValidationAttribute), true))
                attr.ValidateArgument(invocation.Request.Arguments[index], parameters[index].Name);
        }
        invocation.Proceed();       
    }
}

As You can see ValidationInterceptor implements interface IInterceptorwhich belongs to Ninject.Extensions.Interception. This interface has one method Intercept which is called before function from registered component is called. In this function I iterate over all function attributes of type ArgumentValidationAttribute and call ValidateArgument function. If validation passess function invocation.Proceed() is called, which continues execution of original function.

4. Example of usage

In order to take advantage of benefits of function interceptors, we have to resolve objects from Ninject container. First of all I'll create some examplorary classes

public interface IRepository<T> where T:class
{
    List<T> GetAll();
    void Update([NotNull] T entity);
}

public class Car
{
    public int Id { get; set; }
    public string Model { get; set; }
}

public class CarRepository : IRepository<Car>
{
    public  List<Car> GetAll()
    {
        return null;
    }

    public  void Update(Car entity)
    {
            
    }
}

In the next step I'll create simple wrapper for Ninject container and register CarRepository in Kernel

public static class IOCContainer
{
    private static readonly IKernel Kernel;
    static IOCContainer()
    {
        Kernel = new StandardKernel();
    }

    public static void Configure()
    {
        Kernel.Bind(typeof(IRepository<Car>)).To(typeof(CarRepository)).Intercept().With<ValidaitionInterceptor>();
    }

    public static T Get<T>()
    {
        return Kernel.Get<T>();
    }
}

Please, notice that registration of CarRepository was used with option Intercept().With(). Thanks to this configuration, everytime we call method from CarRepository, Intercept method from ValidaitionInterceptor will be called first. Now, it is time to use our repository,we could do that this way

class Program
{
    static void Main(string[] args)
    {
        IOCContainer.Configure();
        var carRepository = IOCContainer.Get<IRepository<Car>>();
        carRepository.Update(null);
    }
}

Argument entity in method Update from interface IRepository was decorated with NotNull, that is why our validation mechanism should throw exception.

5. Validation of return value

Using IInterceptor we could go one step further and also validate return value of method. In order to do that, we have to slightly modify Intercept method in ValidaitionInterceptor class.

public class ValidaitionInterceptor : IInterceptor
{
    public void Intercept(IInvocation invocation)
    {
        var parameters = invocation.Request.Method.GetParameters();
        for (int index = 0; index < parameters.Length; index++)
        {
            foreach (ArgumentValidationAttribute attr in parameters[index].GetCustomAttributes(typeof(ArgumentValidationAttribute), true))
                attr.ValidateArgument(invocation.Request.Arguments[index], parameters[index].Name);
        }

        invocation.Proceed();

        foreach (ArgumentValidationAttribute attr in invocation.Request.Method.ReturnTypeCustomAttributes.GetCustomAttributes(typeof(ArgumentValidationAttribute), true))
        {
            attr.ValidateArgument(invocation.ReturnValue, "return value");
        }
    }
}

We also have to change attribute usage of ArgumentValidationAttribute to

[AttributeUsage(AttributeTargets.Parameter | AttributeTargets.ReturnValue)]

Now, we can decorate function GetAll with NotNullattribute

[return: NotNull]
List<T> GetAll();

Since this moment, everytime function GetAll returns null, the ArgumentNullException will be thrown.

6. Drawbacks

Unfortunately using attributes for argument validation have some drawbacks. First of all, argument validation is based on function interceptors, and as I mentioned before only function, which are in objects, which are resolved from IoC container can be intercepted. What is more, interceptors allow us to intercept only functions marked as virtual or inhirited from interface.

Source code for this post can be found here

ASP.NET MVC javascript debugging using WebStorm

Mon, 17 Sep 2012 08:26:00 GMT

I've been working with ASP .NET combined with Extjs for about half a year. All this time for debugging I've been using Firebug in Firefox, or Developer Tools in Chrome. Although both of these tools are great, I decided to try to use build in WebStorm debugger. According to documentation this debugger should work with Firefox as well as with Chrome. However I've only managed to run it correctly with Firefox. In order to start debugging session, we have to make some preparation. Let's choose option Debug... from Run menu

In opened small window, we have to choose first option - Edit configurations...

In the next window we can create new debugging profile. In order to do that, click on + sign in the left upper corner of window, then choose JavascriptDebug and Remote option

This is the final step of the configuration. The most important fields in configuration window is URL to open field, in which we specify adress of our site. In my case it is localhost on port 8142. We also have to specify mapping from remote host direcotry structure to our directory structure. Sample configuration is presented below

We also have a possibility to choose browser in which our site will be displayed. I decided to choose Firefox because of the fact, that WebStorm debugger had some problems with Chrome. Now we can try to run debugging session by pressing ALT+F9. If we choose Firefox, in the very first time we run debugger, we will see this window

which informs us that WebStorm must install extension to Firefox. Clicking OK button starts Firefox

which warns us that external program is trying to install extension. Clicking continue button will finish configuration process, and WebStorm will successfully attach debugger.

Extjs 4.1.1 - how to fix row resize phenomena

Sat, 15 Sep 2012 23:17:00 GMT

Recently I've encountered annoying problem with Extjs grid. After hiding columns with long wrapped text, height of rows was dramatically increased. Here are some screens presenting this particular situation. Grid with all columns shown

and grid with one column hidden

The code responsible for rendering this grid is shown below

.x-grid-cell-inner { white-space: normal; }

Ext.onReady(function () {
        Ext.QuickTips.init();
        var store = Ext.create('Ext.data.Store', {
            fields: ['Id', 'firstname', 'lastname'],
            data: {
                items: [{
                    Id: 1,
                    firstname: 'some long text some long text some long text some long text some long text some long text some long text some long text some long textareasome long textareasome long textarea',
                    lastname: 'Smith'
                },{
                    Id: 1,
                    firstname: 'Mat'
                },{
                    Id: 1,
                    firstname: 'Kate',
                    lastname: 'Smith'
                },{
                    Id: 1,
                    firstname: 'Richard',
                    lastname: 'Smith'
                }]
            },
            proxy: {
                type: 'memory',
                reader: {
                    type: 'json',
                    root: 'items'
                }
            }
        });

       var visible = true;
       var grid = Ext.create('Ext.grid.Panel', {
            store: store,
            renderTo: Ext.getBody(),
            columns: [
                      { text: 'Id', dataIndex: 'Id' },
                      { text: 'First name', dataIndex: 'firstname' },
                      { text: 'Last name', dataIndex: 'lastname' }]});

        Ext.create('Ext.button.Button', {
            text: 'click',
            renderTo: Ext.getBody(),
            handler: function() {
                visible = !visible;
                grid.columns[1].setVisible(visible);
                grid.validate();
            }
        });
    });

After some digging, it turned out that Extjs hides columns by setting their width to 0px. In order to solve this problem and preverse text wrap in cells, I implemented small workaround. Let's start from creating CSS class which disables word wrapping in grid cells.

.noWrap .x-grid-cell-inner {white-space: nowrap;}

Next, we have to start listening for two events

columnhide
columnshow

In handlers of these events, we have to modify tdCls property of hidden column - add noWrap class, if column is hidden and delete this class otherwise.

grid.headerCt.on({
            columnhide: function (headerCt, column) {
                column.tdCls = "noWrap";
                this.getView().refresh();
            },
            columnshow: function (headerCt, column) {
                column.tdCls = "";
                this.getView().refresh();
            },
            scope: grid
        });

From now hiding and showing columns works fine

Entire code listing is presented below

``Ext.onReady(function () {
        Ext.QuickTips.init();
        var store = Ext.create('Ext.data.Store', {
            fields: ['Id', 'firstname', 'lastname'],
            data: {
                items: [{
                    Id: 1,
                    firstname: 'some long text some long text some long text some long text some long text some long text some long text some long text some long textareasome long textareasome long textarea',
                    lastname: 'Smith'
                },{
                    Id: 1,
                    firstname: 'Mat'
                },{
                    Id: 1,
                    firstname: 'Kate',
                    lastname: 'Smith'
                },{
                    Id: 1,
                    firstname: 'Richard',
                    lastname: 'Smith'
                }]
            },
            proxy: {
                type: 'memory',
                reader: {
                    type: 'json',
                    root: 'items'
                }
            }
        });

       var visible = true;
       var grid = Ext.create('Ext.grid.Panel', {
            store: store,
            renderTo: Ext.getBody(),
            columns: [
        { text: 'Id', dataIndex: 'Id' },
        { text: 'First name', dataIndex: 'firstname' },
        { text: 'Last name', dataIndex: 'lastname' }]});

        grid.headerCt.on({
            columnhide: function (headerCt, column) {
                column.tdCls = "noWrap";
                this.getView().refresh();
            },
            columnshow: function (headerCt, column) {
                column.tdCls = "";
                this.getView().refresh();
            },
            scope: grid
        });

        Ext.create('Ext.button.Button', {
            text: 'click',
            renderTo: Ext.getBody(),
            handler: function() {
                visible = !visible;
                grid.columns[1].setVisible(visible);
                grid.validate();
            }
        });
    });

Extjs 4.1.1 - validatable grid

Sun, 02 Sep 2012 14:08:00 GMT

In this post I will present a simple plugin to Ext.panel.Grid which displays validation errors on a grid. The validation mechanism is based on the model validation - useful feature of Extjs framework. Let's start from creating a simple model:

Ext.define('CustomerModel', {
    extend: 'Ext.data.Model',
    fields: [
        {name: 'id',  type: 'int'},
        { name: 'lastname', type: 'string' },
        {name: 'firstname',type:'string'}
    ],
    validations: [{type: 'presence', field: 'lastname', message:'Required field'}]
});

As we can see, this model has a validation field where we can define a validation mechanism for every field in our model. In this example the lastname field is required, I use build in Extjs validator of the presence type. More build-in validation types might be found here. Of course, it is possible to define custom validation types, simple example can be found on Stackoverflow. Having defined model validation, let's create ValidatableGridplugin. The main function of ValidatableGrid plugin is function called validate which is attached to grid component. This function looks this way:

validate: function(){
       var me = this, view = this.getView(),isValid = true;
       var columnLength = me.columns.length;
       me.getStore().each(function(record,idx){
           // remove existing validation errors
           for (var j = 0; j < columnLength; j++) {
               var cell = view.getCellByPosition({row: idx, column: j});
               cell.removeCls(me.clsInvalidField);
           }
           var validationResult = record.validate();
           if(!validationResult.isValid()){
               isValid= false;
               for(var i =0;i < validationResult.items.length;i++){
                   for (var j = 0; j < columnLength; j++) {
                       var cell = view.getCellByPosition({row: idx, column: j});
                       if(validationResult.items[i].field == me.columns[j].dataIndex){
                           cell.addCls("x-form-invalid-field");
                           cell.set({'data-errorqtip': validationResult.items[i].message});
                       }
                   }
               }
           }
       })
       return isValid;
   }

This function iterates through every model in grid's store and runs validation method. As a result, we get a validationResult object which holds information about errors of model. This object has a function isValid which returns true if there is no errors or false otherwise. Having checked the model, we have to show errors on the grid. In order to do that, we have to find a cell, in which invalid field is displayed using getCellByPosition function. In the last step, we only have to modify CSS classes of cell. That is why, I added x-form-invalid-field class to show red line in cell and also data-errorqtip class to show validation error tooltip. The entire listing looks this way:

Ext.define('ValidatableGrid', {
    grid:null,
    init: function (grid) {
        var me = this;
        me.grid = grid;
        me.grid.validate = me.validate;
    },

   validate: function(){
        var me = this, view = this.getView(),isValid = true;
        var columnLength = me.columns.length;
        me.getStore().each(function(record,idx){
            //remove existing validation errors
            for (var j = 0; j < columnLength; j++) {
                var cell = view.getCellByPosition({row: idx, column: j});
                cell.removeCls(me.clsInvalidField);
            }
            var validationResult = record.validate();
            if(!validationResult.isValid()){
                isValid= false;
                for(var i =0;i < validationResult.items.length;i++){
                    for (var j = 0; j < columnLength; j++) {
                        var cell = view.getCellByPosition({row: idx, column: j});
                        if(validationResult.items[i].field == me.columns[j].dataIndex){
                            cell.addCls("x-form-invalid-field");
                            cell.set({'data-errorqtip': validationResult.items[i].message});
                        }
                    }
                }
            }
        })
        return isValid;
    }
})

here is example of usage;

Ext.QuickTips.init();

var store = Ext.create('Ext.data.Store', {
    model: 'CustomerModel'
});
store.add([{
    id: 1,
    firstname: 'John'
}, {
    id: 1,
    firstname: 'Mat'
}, {
    id: 1,
    firstname: 'Kate',
    lastname:  'Smith'
}, {
    id: 1,
    firstname: 'Richard',
    lastname:  'Smith'
}, {
    id: 1,
    firstname: 'Nick'
}]);

vGrid = Ext.create('Ext.grid.Panel', {
    store: store,
    plugins: [Ext.create('ValidatableGrid')],
    columns: [ { text: 'Id', dataIndex: 'id' },
               { text: 'First name', dataIndex: 'firstname' },
               { text: 'Last name', dataIndex: 'lastname' }]});

vGrid.validate();

and the result

Source code for this post can be found here

Extjs 4.1.1 - multiselectable datepicker as plugin

Sun, 02 Sep 2012 12:32:00 GMT

A couple of weeks ago I wrote a post about creating a mutiselectable datepicker. The idea of creating this component was to use the object inheritance. Today, I would like to show how to create a multiselectable datepicker as a plugin to Ext.date.Picker. The code responsible for selecting dates is almost the same, the only thing which must be changed is the component initialization and access to the datepicker component. In order to make a plugin to any Ext.Component class, you must implement the init method which takes as argument a reference to the component - so let's change the existing code to meet this requirement. We need to rename initComponent function to init. In addition to, we should delete the extend property from our code. After these changes the init function looks like this:

init:function(datePicker){
        var me = this;
        me.datePicker = datePicker;
        // me.callParent(arguments);
        me.datePicker.on('select',me.handleSelectionChanged,me);
        me.datePicker.on('afterrender',me.higlighDates,me);
}

Please notice, that the init function takes as an argument the datepicker component - and from now on this is our only way to access this component. The rest of the code also requires some modifications - it's necessary to change all references to the datepicker (from the variable me to me.datePicker). The entire code listing is presented below.

Ext.define('Multiselect', {
    selectedDates : {},
    clsHigligthClass :'x-datepicker-selected',
    datePicker:null,
    init:function(datePicker){
        var me = this;
        me.datePicker = datePicker;
       // me.callParent(arguments);
        me.datePicker.on('select',me.handleSelectionChanged,me);
        me.datePicker.on('afterrender',me.higlighDates,me);
    },
    
    higlighDates: function(){
        var me = this;
        if(!me.datePicker.cells)
            return;
        me.datePicker.cells.each(function(item){
            var date = new Date(item.dom.firstChild.dateValue).toDateString();
            if(me.selectedDates[date]){
                if(item.getAttribute('class').indexOf(me.clsHigligthClass)=== -1){
                    item.addCls(me.clsHigligthClass)
                }
            }else{
                item.removeCls(me.clsHigligthClass);
            }
        })
    },

    handleSelectionChanged:function(cmp,date){
        var me = this;
        if(me.selectedDates[date.toDateString()])
            delete me.selectedDates[date.toDateString()]
        else
            me.selectedDates[date.toDateString()] = date;
        me.higlighDates();
    }
})

Here is example of usage;

var picker = Ext.create('Ext.picker.Date', {
                    plugins: [Ext.create('Multiselect')]
                });

and the result

Source code for this post can be found here

Windows Phone - skinnable application

Fri, 20 Jul 2012 08:38:00 GMT

1. Introduction

Today, I would like to present my concept of making skinnable application in Windows Phone 7.1. Making a skinnable application in Windows Phone might be a little bit tricky. Unfortunately, WP7 doesn't support DynamicResource keyword which is a basic tool for making skins in WPF. In order to overcome this inconvenience I decided to write a SkinManager for WindowsPhone.

2. Base view

As I mentioned before, there is no support for using dynamic resources in WP7, therefore, in order to force a control to change style, we have to assign this style in code behind. It is rather obvious that in a single window/control there might be quite a lot of other controls whose style also should be changed. That is why, I decided to write controls iterator first.

public class ViewsEnumerator : IEnumerator<FrameworkElement>
{
    private Stack<FrameworkElement> _frameworkElementsStack = new Stack<FrameworkElement>();
    private FrameworkElement _current;
    private readonly FrameworkElement _startingElement;
    
    public ViewsEnumerator(FrameworkElement stargingElement)
    {
        _startingElement = stargingElement;
    }
    
    public void Dispose()
    {
        _current = null;
        _frameworkElementsStack.Clear();
        _frameworkElementsStack = null;
    }
 
    #region Implementation of IEnumerator

    public bool MoveNext()
    {
        if (_current == null)
        {
            _current = _startingElement;
            for (int i = 0; i < VisualTreeHelper.GetChildrenCount(_current); i++)
                _frameworkElementsStack.Push((FrameworkElement)VisualTreeHelper.GetChild(_current, i));
        }
        else
        {
            if (_frameworkElementsStack.Count == 0) return false;
            _current = _frameworkElementsStack.Pop();

            for (int i = 0; i < VisualTreeHelper.GetChildrenCount(_current); i++)
                _frameworkElementsStack.Push((FrameworkElement)VisualTreeHelper.GetChild(_current, i));
            return true;
        }
        return true;
    }

    public void Reset()
    {
        _current = null;
        _frameworkElementsStack.Clear();
        _frameworkElementsStack = null;
    }

    public FrameworkElement Current
    {
        get { return _current; }
    }

    object IEnumerator.Current
    {
        get { return Current; }
    }

    #endregion
}

In this iterator I used DFS algorithm for searching elements in a tree. Thanks to this piece of code I can take advantage of LINQ's benefits. In the next step I created base classes for views.

public interface IViewBase : IEnumerable<FrameworkElement>
{
}

public class ViewBase : UserControl, IViewBase
{
   #region Implementation of IEnumerable

    /// <summary>
    /// Returns an enumerator that iterates through the collection.
    /// </summary>
    /// <returns>
    /// A <see cref="T:System.Collections.Generic.IEnumerator`1"/> that can be used to iterate through the collection.
    /// </returns>
    public IEnumerator<FrameworkElement> GetEnumerator()
    {
        return new ViewsEnumerator(this);
    }

    /// <summary>
    /// Returns an enumerator that iterates through a collection.
    /// </summary>
    /// <returns>
    /// An <see cref="T:System.Collections.IEnumerator"/> object that can be used to iterate through the collection.
    /// </returns>
    IEnumerator IEnumerable.GetEnumerator()
    {
        return GetEnumerator();
    }

    #endregion
}

3. SkinManager class

Having prepared basis for skinnable control, let me introduce a custom attribute called the SkinnablePartAttribute

[AttributeUsage(AttributeTargets.Class)]
public class SkinnablePartAttribute : Attribute
{
    public string ThemePartName { get; set; }
}

This attribute should decorate custom controls which should have an ability to change theme/skin. As you can see, the SkinnablePartAttribute has a ThemePartName property which holds information about a name of ResourceDictionary where styles for the given control ought to be searched. Now, it is time to take a look at a SkinManager class. The SkinManager class has one public function - ApplySkin

public static void ApplySkin<TView>(TView view, string skinName)
           where TView : FrameworkElement, IViewBase
{
    foreach (IViewBase control in view.Where(val => val.ImplementsInterfaceOf<IViewBase>()))
    {
        var assemblyName = control.GetType().Assembly.FullName;
        Uri parsedUri;
        var attribute = control.GetType().GetCustomAttributes(typeof(SkinnablePartAttribute), true).SingleOrDefault();
        if (attribute != null && Uri.TryCreate(string.Format("/{0};component/Themes/{1}/{2}.xaml",assemblyName.Substring(0, assemblyName.IndexOf(",", StringComparison.Ordinal)), skinName,(attribute as SkinnablePartAttribute).ThemePartName), UriKind.Relative, out parsedUri))
            ApplySkin(control, parsedUri);
        else
            Debug.WriteLine(string.Format("Could not find {0}/{1}", skinName,(attribute as SkinnablePartAttribute).ThemePartName));
    }
}

This function iterates through all controls which implement a IViewBase interface - in other words, the function iterates through our custom controls. If a control is decorated with the SkinnablePartAttribue, a new Uri is created based on the information from the ThemePartName property and from the skinName parameter(I assumed that all dictionaries are located in the Themes directory). In the final step, private function also known as the AppySkin function is called. This function looks this way:

private static void ApplySkin<TView>(TView view, Uri uri, int mergedDictionaryIndex = 0)
            where TView :  IViewBase
{
    var castedView = view as FrameworkElement;
    if(castedView == null) return;

    var resourceMergedDictionary = castedView.Resources.MergedDictionaries[mergedDictionaryIndex];
    var beforeClearDictionary = resourceMergedDictionary.ToDictionary(key => key.Value, val => new { key = val.Key, value = val.Value });
    castedView.Resources.MergedDictionaries.Remove(resourceMergedDictionary);
    resourceMergedDictionary.Clear();

    var newStyleDictionary = new ResourceDictionary
    {
        Source = uri
    };

    castedView.Resources.MergedDictionaries.Insert(mergedDictionaryIndex, newStyleDictionary);
    foreach (var control in view.Where(val => val.Style != null && !val.ImplementsInterfaceOf<IViewBase>()).Where(control =>
        beforeClearDictionary.ContainsKey(control.Style) && newStyleDictionary[beforeClearDictionary[control.Style].key] != null))
        control.Style = newStyleDictionary[beforeClearDictionary[control.Style].key] as Style;

    beforeClearDictionary.Clear();
}

Here, all the magic begins. In the first step, current ResourceDictionary is transformed into the standard dictionary. The key of this dictionary is a value of style – a reference to the style object. In the next step, I created a new ResourceDictionary based on the Uri parameter passed to this function. In the last step, another loop over controls is performed. However, this time only controls with the assigned Style property are taken into consideration. Then, if the newStyleDictionary contains a key of given control style we are ready to swap styles.

control.Style = newStyleDictionary[beforeClearDictionary[control.Style].key] as Style;

Entire listing of SkinManager is presented below

public static class SkinManager
{
    private static void ApplySkin<TView>(TView view, Uri uri, int mergedDictionaryIndex = 0)
        where TView :  IViewBase
    {
        var castedView = view as FrameworkElement;
        if(castedView == null) return;

        var resourceMergedDictionary = castedView.Resources.MergedDictionaries[mergedDictionaryIndex];
        var beforeClearDictionary = resourceMergedDictionary.ToDictionary(key => key.Value, val => new { key = val.Key, value = val.Value });
        castedView.Resources.MergedDictionaries.Remove(resourceMergedDictionary);
        resourceMergedDictionary.Clear();

        var newStyleDictionary = new ResourceDictionary
        {
            Source = uri
        };

        castedView.Resources.MergedDictionaries.Insert(mergedDictionaryIndex, newStyleDictionary);
        foreach (var control in view.Where(val => val.Style != null && !val.ImplementsInterfaceOf<IViewBase>()).Where(control =>
            beforeClearDictionary.ContainsKey(control.Style) && newStyleDictionary[beforeClearDictionary[control.Style].key] != null))
            control.Style = newStyleDictionary[beforeClearDictionary[control.Style].key] as Style;

        beforeClearDictionary.Clear();

    }
    
    public static void ApplySkin<TView>(TView view, string skinName)
       where TView : FrameworkElement, IViewBase
    {

        foreach (IViewBase control in view.Where(val => val.ImplementsInterfaceOf<IViewBase>()))
        {
            var assemblyName = control.GetType().Assembly.FullName;
            Uri parsedUri;
            var attribute = control.GetType().GetCustomAttributes(typeof(SkinnablePartAttribute), true).SingleOrDefault();
            if (attribute != null && Uri.TryCreate(string.Format("/{0};component/Themes/{1}/{2}.xaml",assemblyName.Substring(0, assemblyName.IndexOf(",", StringComparison.Ordinal)), skinName,(attribute as SkinnablePartAttribute).ThemePartName), UriKind.Relative, out parsedUri))
                ApplySkin(control, parsedUri);
            else
                Debug.WriteLine(string.Format("Could not find {0}/{1}", skinName,(attribute as SkinnablePartAttribute).ThemePartName));
            
        }
    }
}

4. Example of usage

In order to use the SkinManager it is essential to make some preparation. First of all, you have to create Themes directory in a project. In this directory there must be separate subdirectories for every skin you would like to use. What is more, in these subdirectories you should place all ResourceDictionaries specified in the SkinnablePartAttribute. A sample directory structure is shown in the picture below:

The very last step is to make controls (which should be skinnable) inherit from ViewBase. Here is example of usage

namespace Joomanji.Chat.Client.Views
{
    [SkinnablePart(ThemePartName = "ChatWindowSkin")]
    public partial class ChatWindowView : ViewBase
    {
        public ChatWindowView()
        {
            SkinManager.ApplySkin(this, "Red"); // change skin
        }
    }   
}

and screenshots of the same view with different skin

5. Controls with dynamically changing content

After some test, it turned out that the mechanism presented above has problems with controls which change their content dynamically. Let me clarify - styling grids, list boxes etc. work fine, however changing row styles and listboxitem styles are not working properly. In order to overcome this problem you must define a style for a specific target type. Here is an example of usage with the listbox:

<Style TargetType="ListBox">
    <Setter Property="HorizontalContentAlignment" Value="Stretch"/>
    <Setter Property="VerticalAlignment" Value="Stretch"/>
    <Setter Property="ItemTemplate" Value="{StaticResource GeneralChatMessageTemplate}"/>
</Style>`

Extjs 4.1.1 - multiselectable datepicker

Thu, 19 Jul 2012 21:31:00 GMT

Recently, I have been given a task to make extjs datepicker allowing for selection of multiple dates. Unfortunately afters hours of searching for some build-in function, it turned out that this kind of functionality is not supported by default. Finaly, I decided to extend datepicker by creating component called highlightableDatePicker. I started from creating a class which inhierits from Ext.picker.Date. First draft of class looked this way

Ext.define('HighlightableDatePicker', {
    extend: 'Ext.picker.Date',
    selectedDates:{},
    clsHighlightClass:'x-datepicker-selected',
    initComponent: function(){
        var me = this;
        me.callParent(arguments);
    },

    highlightDates: function(){
        var me = this;
    }
})

In this class I created additional function highlightDates which is responsible for highlighting dates. Moreover, I added some additional config elements:

selectedDates - object keeping track of dates which should be selected
clsHighlightClass - CSS class defining selected cell style

The most important part of HighlightableDatepicker class is function highlightDates which is responsible for highlighting dates. The body of this method looks like this

highlightDates: function(){
      var me = this;
       if(!me.cells)
           return;
       me.cells.each(function(item){
           var date = new Date(item.dom.firstChild.dateValue).toDateString();
           if(me.selectedDates[date]){
               if(item.getAttribute('class').indexOf(me.clsHighlightClass)=== -1){
                   item.addCls(me.clsHighlightClass)
               }
           }else{
               item.removeCls(me.clsHighlightClass);
           }
       })
}

As You can see, this function simply compares date in cell with dates stored in selectedDates. If there is a match, cell style is modified by adding extra CSS class into class attribute of cell (see addCls function of Extjs), otherwise CSS class responsible for highlighting is removed. Having defind highlightDates function,I also had to attach an event handler to select event, in order to modify collection of selected dates. This handler looks this way

handleSelectionChanged: function(cmp, date){
   var me = this;
       if(me.selectedDates[date.toDateString()])
           delete me.selectedDates[date.toDateString()]
       else
           me.selectedDates[date.toDateString()] = date;
       me.highlightDates();
}

The final step to make this control work is to attach event handlers and call highlightDates function during initialization of component.

initComponent: function() {
        var me = this;
        me.callParent(arguments);
        me.on('select',me.handleSelectionChanged,me);
        me.on('afterrender',me.highlightDates,me);
}

Please, notice that highlightDates is called after component is rendered, because there is no rendered cells before that moment. Entire code listing is presented below

Ext.define('HighlightableDatePicker', {
    extend: 'Ext.picker.Date',
    selectedDates : {},
    clsHighlightClass :'x-datepicker-selected',
    
    initComponent: function(){
        var me = this;
        me.callParent(arguments);
        me.on('select',me.handleSelectionChanged,me);
        me.on('afterrender',me.highlightDates,me);

    },
    
    highlightDates: function(){
        var me = this;
        if(!me.cells)
            return;
        me.cells.each(function(item){
            var date = new Date(item.dom.firstChild.dateValue).toDateString();
            if(me.selectedDates[date]){
                if(item.getAttribute('class').indexOf(me.clsHighlightClass)=== -1){
                    item.addCls(me.clsHighlightClass)
                }
            }else{
                item.removeCls(me.clsHighlightClass);
            }
        })
    },

    handleSelectionChanged: function(cmp, date){
        var me = this;
        if(me.selectedDates[date.toDateString()])
            delete me.selectedDates[date.toDateString()]
        else
            me.selectedDates[date.toDateString()] = date;
        me.highlightDates();
    }
})

and the result

Source code for this post can be found here

Extjs 4.1 - zmiana stylu konkretnej komórki w gridzie

Fri, 13 Jul 2012 20:42:00 GMT

Witam Dzisiejszy post nie będzie związany z platformą .NET, lecz z javascriptowym frameworkiem Extjs w wersji 4.1. Jako, że ostatnio w pracy poświęcam dużo czasu na pisanie w wyżej wymienionej technologii postanowiłem zaprezentować, w jaki sposób zmienić styl konkretnej komórki w gridzie. Zacznijmy od przygotowania danych do wyświetlenia - zdefiniujmy zatem stora, który będzie przechowywał informacje mające zostać zaprezentowane na gridzie.

Ext.create('Ext.data.Store', {
    storeId:'itemsStore',
    fields:['name', 'email', 'change'],
    data:{'items':[
        { 'name': 'LCD PLAYER',    "change":100  },
        { 'name': 'DVD PLAYER', "change":-20  },
        { 'name': 'CD PLAYER',   "change":23   },
        
    ]},
    proxy: {
        type: 'memory',
        reader: {
            type: 'json',
            root: 'items'
        }
    }
});

Następnie podepnijmy stora pod grida w wersji podstawowej - bez zmiany stylu konkretnych komórek.

Ext.create('Ext.grid.Panel', {
    store: Ext.data.StoreManager.lookup('itemsStore'),
    columns: [
        { header: 'Name',  dataIndex: 'name' },
        { header: 'Change', dataIndex: 'change'}
    ],
    height: 200,
    width: 400,
    forceFit:true,
    renderTo: Ext.getBody()
});

W celu zmiany parametrów poszczególnych komórek grida posłużymy się tzw. rendererem. Renderer jest to funkcja, której zadaniem jest modyfikacją komórek w danej kolumnie grida. Dzięki rendererowi możemy nie tyko zmienić zawartość komórki, ale również przypisać jej osobny styl lub klasę CSS. Myślę, że renderer można porównać do conwertera znanego z technologii WPF. Funkcję renderera podłączymy pod ostatnią kolumnę. Kod po modyfikacjach będzie wyglądał w następujący sposób:

Ext.create('Ext.grid.Panel', {
    store: Ext.data.StoreManager.lookup('itemsStore'),
    columns: [
        { header: 'Name',  dataIndex: 'name' },
        { header: 'Change', dataIndex: 'change', renderer: function(value, metaData, record, row, col, store, gridView){
            if(value>0)
              metaData.tdCls = 'price-rise'
            else
              metaData.tdCls = 'price-fall'
                  
             return value;
        }}
    ],
    height: 200,
    width: 400,
    
    renderTo: Ext.getBody()
});

.price-fall  {
    background-color: red !important;
    
}
.price-rise {
    background-color: #B0FFC5;
    color:green;
}

Zauważmy, że funkcja renderer przyjmuje kilka parametrów. Najważniejsze z nich to

value - wartość wyświetlona w komórce grida
metaData- obiekt dający nam dostęp do parametrów komórki (np. tdCls)
record - record grida

W moim przypadku na podstawie wartości wyświetlanej w komórkach kolumny Change, określam czy dana komórka powinna być czerwona czy zielona. Wygląd grida przed oraz po zastosowaniu renderera przedstawiają poniższe screeny

Windows Phone - własny DataTemplateSelector

Sat, 09 Jun 2012 22:55:00 GMT

Pisząc moją małą aplikację pod Windows Phone po raz kolejny natknąłem się na problem. Pod WP7 nie ma tak przydatnej rzeczy jaką jest DataTemplateSelector znany nam bardziej, lub mniej z Silverlighta oraz WPF-a. Na szczęście napisane własnego DataTemplateSelector-a nie jest specjalnie skomplikowane. Nasz customowy DataTemplateSelector zostanie oparty o kontrolkę ContentControl. Po pierwsze stwórzmy klasę bazową DataTemplateSelectora dziedziczącą po ContentControl, w której przeciążamy funkcję OnContentChanged,

public abstract class AbstractDataTemplateSelector : ContentControl
{
    public abstract DataTemplate SelectTemplate(object item, DependencyObject container);
    
    protected override void OnContentChanged(object oldContent, object newContent)
    {
        base.OnContentChanged(oldContent, newContent);
        ContentTemplate = SelectTemplate(newContent, this);
    }
}

Klasa ta będzie klasą z której będą wywodzić się wszystkie nasze TemplateSelectory. Załóżmy, że chcemy zbudować DataTemplateSelector, który będzie obsługiwał aplikację chata. Powinien on zatem reagować na dwa typy elementów:

wiadomości przychodzące
wiadomości wychodzące

Stwórzmy zatem "wyspecjalizowany" DataTemplateSelector, który w zależności od typu wiadomości zwróci odpowiedni DataTemplate.

public class ChatMessageTemplateSelector : AbstractDataTemplateSelector
{
    public DataTemplate Out { get; set; }
    public DataTemplate In { get; set; }

    public override DataTemplate SelectTemplate(object item, DependencyObject container)
    {
        ChatMessage message = item as ChatMessage;
        if (message != null)
        {
            switch (message.MessageDirection)
            {
                case MessageDirection.In:
                    return In;
                case MessageDirection.Out:
                    return Out;
                default:
                    return Out;
            }
        }
        return In;
    }
}

W klasie ChatMessageTemplateSelector przeciążyliśmy metodę SelectTemplate. W metodzie tej, na podstawie zbindowanego obiektu (parametr item) określamy jaki template powinniśmy zwrócić. Templaty do wiadomości przychodzących oraz wychodzących zostały zdefiniowane jako propertisy.

Out - template wiadomości wychodzącej
In - template wiadomości przychodzącej

Pozostaje nam tylko zdefiniować wymienione wyżej templaty. Nie będziemy robić tego w kodzie, ale w XAML-u. Nasz nowo stworzony DataTemplateSelector wykorzytamy w ListBox-ie

<ListBox  ItemsSource="{Binding MessageList,Mode=TwoWay}" Grid.ColumnSpan="2" HorizontalContentAlignment="Stretch" VerticalAlignment="Stretch"
                     ItemTemplate="{StaticResource GeneralChatMessageTemplate}" />

Jako, że nasz ChatMessageTemplateSelector jest tak naprawdę obiektem typu ContentControl, zatem możemy go zbindować do właściwości ItemTemplate ListBox-a. Zasób GeneralChatMessageTemplate wygląda w następujący sposób

<DataTemplate x:Key="GeneralChatMessageTemplate">
            <Client:ChatMessageTemplateSelector HorizontalContentAlignment="Stretch" Content="{Binding}" In="{StaticResource IncomingChatMessageTemplate}" Out="{StaticResource OutcomingChatMessageTemplate}">
            </Client:ChatMessageTemplateSelector>
</DataTemplate>

Jak widać jest to obiekt typu ChatMessageTemplateSelector, którego właściwość Content jest zbindowana do aktualnego kontekstu (pojedyncze słowo kluczowe Binding). Widzimy również, że ustawiliśmy wartości właściwości odpowiadających za templaty poszczególnych wiadomości (In="{StaticResource IncomingChatMessageTemplate}" Out="{StaticResource OutcomingChatMessageTemplate}"). Wspomniane templaty wyglądają w następujący sposób

<DataTemplate x:Key="IncomingChatMessageTemplate">
            <Border BorderThickness="0,0,0,1" BorderBrush="#2d3550" >
                <Grid Background="#181c2a" HorizontalAlignment="Stretch">
                    <Grid.ColumnDefinitions>
                        <ColumnDefinition />
                        <ColumnDefinition />
                    </Grid.ColumnDefinitions>
                    <Grid.RowDefinitions>
                        <RowDefinition></RowDefinition>
                        <RowDefinition></RowDefinition>
                    </Grid.RowDefinitions>
                    <StackPanel Orientation="Horizontal">
                        <Border BorderThickness="1" BorderBrush="White" Margin="5,5,0,0">
                            <Image Stretch="None"  Width="30" Height="30" MaxWidth="30" MinHeight="30" MaxHeight="30"  Source="..avatar_4934.bmp"></Image>
                        </Border>
                        <TextBlock Padding="5,5,5,0" Foreground="White" FontFamily="Segoe UI, Tahoma" FontSize="12" FontWeight="Bold" TextTrimming="WordEllipsis"  TextAlignment="Left" VerticalAlignment="Center" HorizontalAlignment="Left"  Text="{Binding Sender.UserName,Mode=TwoWay}"></TextBlock>
                    </StackPanel>
                    <TextBlock FontFamily="Segoe UI, Tahoma" FontSize="10" Padding="5,5,5,0" Foreground="#8e929f" TextTrimming="WordEllipsis"  Grid.Column="1" TextAlignment="Right" VerticalAlignment="Center" HorizontalAlignment="Right" Text="{Binding SendTime, Mode=TwoWay, StringFormat='{0:dd.MM HH:mm:ss}'}"></TextBlock>
                    <TextBlock FontFamily="Segoe UI, Tahoma" FontSize="12" Margin="5,0,0,0" TextWrapping="Wrap" Grid.ColumnSpan="2" Grid.Row="1" Text="{Binding Message,Mode=TwoWay}" ></TextBlock>
                </Grid>
            </Border>
</DataTemplate>

<DataTemplate x:Key="OutcomingChatMessageTemplate">
            <Border BorderThickness="0,0,0,1" BorderBrush="#2d3550">
                <Grid HorizontalAlignment="Stretch">
                    <Grid.ColumnDefinitions>
                        <ColumnDefinition />
                        <ColumnDefinition />
                    </Grid.ColumnDefinitions>
                    <Grid.RowDefinitions>
                        <RowDefinition></RowDefinition>
                        <RowDefinition></RowDefinition>
                    </Grid.RowDefinitions>
                    <StackPanel Orientation="Horizontal">
                        <Border BorderThickness="1" BorderBrush="White" Margin="5,5,0,0">
                            <Image Stretch="None"  Width="30" Height="30" MaxWidth="30" MinHeight="30" MaxHeight="30"  ></Image>
                        </Border>
                        <TextBlock Padding="5,5,5,0" Foreground="#8e929f" FontFamily="Segoe UI, Tahoma" FontSize="12" FontWeight="Bold" TextTrimming="WordEllipsis"  TextAlignment="Left" VerticalAlignment="Center" HorizontalAlignment="Left"  Text="{Binding Sender.UserName,Mode=TwoWay}"></TextBlock>
                    </StackPanel>
                    <TextBlock FontFamily="Segoe UI, Tahoma" FontSize="10" Padding="5,5,5,0" Foreground="#8e929f" TextTrimming="WordEllipsis"  Grid.Column="1" TextAlignment="Right" VerticalAlignment="Center" HorizontalAlignment="Right" Text="{Binding SendTime, Mode=TwoWay, StringFormat='{0:dd.MM HH:mm:ss}'}"></TextBlock>
                    <TextBlock FontFamily="Segoe UI, Tahoma" FontSize="12" Margin="5,0,0,0" TextWrapping="Wrap" Grid.ColumnSpan="2" Grid.Row="1" Text="{Binding Message,Mode=TwoWay}" ></TextBlock>
                </Grid>
            </Border>
</DataTemplate>

Od teraz gdy do ListBox-a zostanie dodany nowy item, pierwszą rzeczą jaka się odpali będzie funkcja OnContentChanged. W funkcji tej AbstractDataTemplateSelector na podstawie nowo przybyłego itemu ustawi właściwość ContentTemplate, na taki template jaki zwróci mu funkcja SelectTemplate. Wynik działania ChatMessageTemplateSelector wygląda w następujący sposób

Windows Phone - wyświetlanie błędów walidacji

Sat, 09 Jun 2012 22:55:00 GMT

Kilka miesięcy temu w tym poście przedstawiałem różne sposoby walidacji jakie są dostępne na platformie Silverlight. Jako, że ostatnio mam więcej czasu aby pisać jakieś proste aplikacje pod Windows Phonem potrzebowałem mechanizmu walidacji działającego pod tą platformą. Według MSDN-a wszystkie metody walidacji przedstawione we wspomnianym wcześniej poście powinny działać. Niestety po przerzuceniu mechanizmu z Silverlighta na Windows Phona okazało się, że błędy walidacji nie zostają wyświetlone na interfejsie. Po przeszukaniu kilku for oraz blogów dowiedziałem się, że przyczyną takiego stanu rzeczy jest brak obsługi reakcji na błędy w templacie TextBoxów (i innych elementów typu input). Zatem aby wyświetlić błędy walidacji, pozostaje nam zmodyfikować istniejący template TextBox-a. Zacznijmy od wyciągnięcia standardowego templatu TextBox-a z Windows Phona. W tym celu możemy użyć aplikacji Expression Blend. Otwórzmy w niej jakikolwiek projekt typu Windows Phone Application, w którym na kontrolce mamy naniesionego Textboxa. W moim przypadku, po wczytaniu projektu do Blenda ekran wygląda w następujący sposób

Następnie zaznaczamy w Blendzie TextBox-a i z opcji znajdujących się w lewym górnym rogu aktualnej zakładki wybieramy TextBox->Edit Template-> Edit Copy.

W oknie, które się pojawi klikamy OK. Następnie możemy przejść do widoku XAML-a, w sekcji phone:PhoneApplicationPage.Resources powinien pojawić się nam nowy styl wyglądający w ten sposób

<ControlTemplate x:Key="PhoneDisabledTextBoxTemplate" TargetType="TextBox">
   <ContentControl x:Name="ContentElement" BorderThickness="0" HorizontalContentAlignment="Stretch" Margin="{StaticResource PhoneTextBoxInnerMargin}" Padding="{TemplateBinding Padding}" VerticalContentAlignment="Stretch"/>
   </ControlTemplate>
   <Style x:Key="TextBoxStyle1" TargetType="TextBox">
      <Setter Property="FontFamily" Value="{StaticResource PhoneFontFamilyNormal}"/>
      <Setter Property="FontSize" Value="{StaticResource PhoneFontSizeMediumLarge}"/>
      <Setter Property="Background" Value="{StaticResource PhoneTextBoxBrush}"/>
      <Setter Property="Foreground" Value="{StaticResource PhoneTextBoxForegroundBrush}"/>
      <Setter Property="BorderBrush" Value="{StaticResource PhoneTextBoxBrush}"/>
      <Setter Property="SelectionBackground" Value="{StaticResource PhoneAccentBrush}"/>
      <Setter Property="SelectionForeground" Value="{StaticResource PhoneTextBoxSelectionForegroundBrush}"/>
      <Setter Property="BorderThickness" Value="{StaticResource PhoneBorderThickness}"/>
      <Setter Property="Padding" Value="2"/>
      <Setter Property="Template">
       <Setter.Value>
        <ControlTemplate TargetType="TextBox">
         <Grid Background="Transparent">
          <VisualStateManager.VisualStateGroups>
           <VisualStateGroup x:Name="CommonStates">
            <VisualState x:Name="Normal"/>
            <VisualState x:Name="MouseOver"/>
            <VisualState x:Name="Disabled">
             <Storyboard>
              <ObjectAnimationUsingKeyFrames Storyboard.TargetProperty="Visibility" Storyboard.TargetName="EnabledBorder">
               <DiscreteObjectKeyFrame KeyTime="0">
                <DiscreteObjectKeyFrame.Value>
                 <Visibility>Collapsed</Visibility>
                </DiscreteObjectKeyFrame.Value>
               </DiscreteObjectKeyFrame>
              </ObjectAnimationUsingKeyFrames>
              <ObjectAnimationUsingKeyFrames Storyboard.TargetProperty="Visibility" Storyboard.TargetName="DisabledOrReadonlyBorder">
               <DiscreteObjectKeyFrame KeyTime="0">
                <DiscreteObjectKeyFrame.Value>
                 <Visibility>Visible</Visibility>
                </DiscreteObjectKeyFrame.Value>
               </DiscreteObjectKeyFrame>
              </ObjectAnimationUsingKeyFrames>
             </Storyboard>
            </VisualState>
            <VisualState x:Name="ReadOnly">
             <Storyboard>
              <ObjectAnimationUsingKeyFrames Storyboard.TargetProperty="Visibility" Storyboard.TargetName="EnabledBorder">
               <DiscreteObjectKeyFrame KeyTime="0">
                <DiscreteObjectKeyFrame.Value>
                 <Visibility>Collapsed</Visibility>
                </DiscreteObjectKeyFrame.Value>
               </DiscreteObjectKeyFrame>
              </ObjectAnimationUsingKeyFrames>
              <ObjectAnimationUsingKeyFrames Storyboard.TargetProperty="Visibility" Storyboard.TargetName="DisabledOrReadonlyBorder">
               <DiscreteObjectKeyFrame KeyTime="0">
                <DiscreteObjectKeyFrame.Value>
                 <Visibility>Visible</Visibility>
                </DiscreteObjectKeyFrame.Value>
               </DiscreteObjectKeyFrame>
              </ObjectAnimationUsingKeyFrames>
              <ObjectAnimationUsingKeyFrames Storyboard.TargetProperty="Background" Storyboard.TargetName="DisabledOrReadonlyBorder">
               <DiscreteObjectKeyFrame KeyTime="0" Value="{StaticResource PhoneTextBoxBrush}"/>
              </ObjectAnimationUsingKeyFrames>
              <ObjectAnimationUsingKeyFrames Storyboard.TargetProperty="BorderBrush" Storyboard.TargetName="DisabledOrReadonlyBorder">
               <DiscreteObjectKeyFrame KeyTime="0" Value="{StaticResource PhoneTextBoxBrush}"/>
              </ObjectAnimationUsingKeyFrames>
              <ObjectAnimationUsingKeyFrames Storyboard.TargetProperty="Foreground" Storyboard.TargetName="DisabledOrReadonlyContent">
               <DiscreteObjectKeyFrame KeyTime="0" Value="{StaticResource PhoneTextBoxReadOnlyBrush}"/>
              </ObjectAnimationUsingKeyFrames>
             </Storyboard>
            </VisualState>
           </VisualStateGroup>
           <VisualStateGroup x:Name="FocusStates">
            <VisualState x:Name="Focused">
             <Storyboard>
              <ObjectAnimationUsingKeyFrames Storyboard.TargetProperty="Background" Storyboard.TargetName="EnabledBorder">
               <DiscreteObjectKeyFrame KeyTime="0" Value="{StaticResource PhoneTextBoxEditBackgroundBrush}"/>
              </ObjectAnimationUsingKeyFrames>
              <ObjectAnimationUsingKeyFrames Storyboard.TargetProperty="BorderBrush" Storyboard.TargetName="EnabledBorder">
               <DiscreteObjectKeyFrame KeyTime="0" Value="{StaticResource PhoneTextBoxEditBorderBrush}"/>
              </ObjectAnimationUsingKeyFrames>
             </Storyboard>
            </VisualState>
            <VisualState x:Name="Unfocused"/>
           </VisualStateGroup>
          </VisualStateManager.VisualStateGroups>
          <Border x:Name="EnabledBorder" BorderBrush="{TemplateBinding BorderBrush}" BorderThickness="{TemplateBinding BorderThickness}" Background="{TemplateBinding Background}" Margin="{StaticResource PhoneTouchTargetOverhang}">
           <ContentControl x:Name="ContentElement" BorderThickness="0" HorizontalContentAlignment="Stretch" Margin="{StaticResource PhoneTextBoxInnerMargin}" Padding="{TemplateBinding Padding}" VerticalContentAlignment="Stretch"/>
          </Border>
          <Border x:Name="DisabledOrReadonlyBorder" BorderBrush="{StaticResource PhoneDisabledBrush}" BorderThickness="{TemplateBinding BorderThickness}" Background="Transparent" Margin="{StaticResource PhoneTouchTargetOverhang}" Visibility="Collapsed">
           <TextBox x:Name="DisabledOrReadonlyContent" Background="Transparent" Foreground="{StaticResource PhoneDisabledBrush}" FontWeight="{TemplateBinding FontWeight}" FontStyle="{TemplateBinding FontStyle}" FontSize="{TemplateBinding FontSize}" FontFamily="{TemplateBinding FontFamily}" IsReadOnly="True" SelectionForeground="{TemplateBinding SelectionForeground}" SelectionBackground="{TemplateBinding SelectionBackground}" TextAlignment="{TemplateBinding TextAlignment}" TextWrapping="{TemplateBinding TextWrapping}" Text="{TemplateBinding Text}" Template="{StaticResource PhoneDisabledTextBoxTemplate}"/>
          </Border>
         </Grid>
        </ControlTemplate>
       </Setter.Value>
      </Setter>
   </Style>
</ControlTemplate>

W ten oto sposób udało nam się wydobyć domyślny styl oraz template TextBoxa w Windows Phonie. W kolejnym kroku musimy zmodyfikować ten template w taki sposób, aby zaczął reagować na zmiany stanu walidacji. Zacznijmy od sprawdzenia jakie stany wizualne może obsługiwać TextBox. W tym celu musimy przeglądnąć metadane TextBoxa - możemy to zrobić klikając PPM na klasie TextBox-a i wybierając Go To Definition. Naszym oczom powinno ukazać się coś takiego.

Widzimy, że klasa TextBox jest opatrzona atrybutami TemplateVisualState, nas interesują najbardziej trzy z tych atrybutów:

[TemplateVisualState(GroupName = "ValidationStates", Name = "Valid")\]
[TemplateVisualState(GroupName = "ValidationStates", Name = "InvalidFocused")\]
[TemplateVisualState(GroupName = "ValidationStates", Name = "InvalidUnfocused")\]

Mówią nam one, że w przypadku gdy wystąpią błędy walidacji nasza kontrolka przechodzi w stan InvalidFocused lub InvalidUnfocused. Natomiast, w przypadku gdy nie ma błędów znajduje się ona w stanie Valid. Analizując kod domyślnego templatu TextBoxa widzimy, że stany z grupy ValidationStates nie są obsługiwane - czas zatem to zmienić. Po pierwsze do templatu musimy dorzucić elementy, które będą wyświetlały błędy walidacji. Zmieńmy zatem opakowujący wszystko element Grid na StackPanel, a następnie dodajmy element typu TextBlock oraz Border. Elementy wyświetlające błędy walidacji musimy umieścić w jednym kontenerze z elementami odpowiadającymi za wyświetlanie tekstu. Zatem musimy je opakować w Grida. Po zastosowaniu powyższych wskazówek nasz template będzie wyglądał w następujący sposób

<StackPanel>
...
...
...
    <Grid>
       <Grid.RowDefinitions>
           <RowDefinition Height="Auto"></RowDefinition>
           <RowDefinition Height="Auto"></RowDefinition>
       </Grid.RowDefinitions>
       <Border x:Name="EnabledBorder" BorderBrush="{TemplateBinding BorderBrush}" BorderThickness="{TemplateBinding BorderThickness}" Background="{TemplateBinding Background}" Margin="{StaticResource PhoneTouchTargetOverhang}">
             <ContentControl x:Name="ContentElement" BorderThickness="0" HorizontalContentAlignment="Stretch"   Padding="{TemplateBinding Padding}" VerticalContentAlignment="Stretch"/>
       </Border>
       <Border x:Name="DisabledOrReadonlyBorder" BorderBrush="{StaticResource PhoneDisabledBrush}" BorderThickness="{TemplateBinding BorderThickness}" Background="Transparent" Margin="{StaticResource PhoneTouchTargetOverhang}" Visibility="Collapsed">
          <TextBox x:Name="DisabledOrReadonlyContent" Background="Transparent" Foreground="{StaticResource PhoneDisabledBrush}" FontWeight="{TemplateBinding FontWeight}" FontStyle="{TemplateBinding FontStyle}" FontSize="{TemplateBinding FontSize}" FontFamily="{TemplateBinding FontFamily}" IsReadOnly="True" SelectionForeground="{TemplateBinding SelectionForeground}" SelectionBackground="{TemplateBinding SelectionBackground}" TextAlignment="{TemplateBinding TextAlignment}" TextWrapping="{TemplateBinding TextWrapping}" Text="{TemplateBinding Text}" Template="{StaticResource PhoneDisabledTextBoxTemplate}"/>
       </Border>
       <Border x:Name="ValidationBorder" Grid.RowSpan="2" BorderBrush="Red" BorderThickness="2" Visibility="Collapsed"  >
       </Border>
       <TextBlock x:Name="ValidationMessage" Foreground="Red" FontSize="16" Visibility="Collapsed" Grid.Row="1" Text="{Binding (Validation.Errors)[0].ErrorContent, RelativeSource={RelativeSource TemplatedParent}}"  Padding="0,0,0,2" Margin="10,-14,0,0"  />
    </Grid>
</StackPanel>

Dodanie elementów wyświetlających błędy to nie wszystko, musimy jeszcze określić kiedy nasze elementy mają być widoczne. W chwili obecnej ich właściwość Visibility jest ustawiona na Collapsed. Zatem elementy te nie będą widoczne, jak również nie będą zajmowały miejsca na interfejsie. Jak już wcześniej wspomniałem kontrolka TextBoxa w przypadku wystąpienia błędów walidacji przejdzie do stanów InvalidFocused lub InvalidUnfocused. Pozostaje nam zatem zareagować na przejście kontrolki w te stany i odpowiednio zmodyfikować właściwość Visibility bordera oraz textblocka. W tym celu posłużymy się VisualStateManagerem oraz animacjami. Do naszego templatu dodajmy następujący wpis

<VisualStateGroup x:Name="ValidationStates">
                                <VisualState x:Name="Valid" >
                                    <Storyboard>
                                        <ObjectAnimationUsingKeyFrames Storyboard.TargetProperty="Visibility" Storyboard.TargetName="ValidationBorder">
                                            <DiscreteObjectKeyFrame KeyTime="0" Value="Collapsed" />
                                        </ObjectAnimationUsingKeyFrames>
                                        <ObjectAnimationUsingKeyFrames Storyboard.TargetProperty="Visibility" Storyboard.TargetName="ValidationMessage">
                                            <DiscreteObjectKeyFrame KeyTime="0" Value="Collapsed" />
                                        </ObjectAnimationUsingKeyFrames>
                                    </Storyboard>
                                </VisualState>
                                <VisualState x:Name="InvalidFocused" >
                                    <Storyboard>
                                        <ObjectAnimationUsingKeyFrames Storyboard.TargetProperty="Visibility" Storyboard.TargetName="ValidationBorder">
                                            <DiscreteObjectKeyFrame KeyTime="0" Value="Visible" />
                                        </ObjectAnimationUsingKeyFrames>
                                        <ObjectAnimationUsingKeyFrames Storyboard.TargetProperty="Visibility" Storyboard.TargetName="ValidationMessage">
                                            <DiscreteObjectKeyFrame KeyTime="0" Value="Visible" />
                                        </ObjectAnimationUsingKeyFrames>
                                    </Storyboard>
                                </VisualState>
                                <VisualState x:Name="InvalidUnfocused" >
                                    <Storyboard>
                                        <ObjectAnimationUsingKeyFrames Storyboard.TargetProperty="Visibility" Storyboard.TargetName="ValidationBorder">
                                            <DiscreteObjectKeyFrame KeyTime="0" Value="Visible" />
                                        </ObjectAnimationUsingKeyFrames>
                                        <ObjectAnimationUsingKeyFrames Storyboard.TargetProperty="Visibility" Storyboard.TargetName="ValidationMessage">
                                            <DiscreteObjectKeyFrame KeyTime="0" Value="Visible" />
                                        </ObjectAnimationUsingKeyFrames>
                                    </Storyboard>
                                </VisualState>
</VisualStateGroup>

W ten oto sposób zdefiniwaliśmy w XAML-u grupę (VisualStateGroup) o nazwie ValidationStates - zauważmy, że nazwa grupy jest taka sama jak nazwa grupy z atrybutów klasy TextBox. Dodaliśmy również trzy stany wizualne (VisualState), których nazwy również odpowiadają nazwą zdefiniowanym w atrubytach klasy TextBox. Od tej chwili gdy kontrolka TextBoxa będzie posiadała błędy walidacji, zostanie odpalona animacja zmieniająca właściwość Visibility bordera ValidationBorder oraz TextBlocka ValidationMessage na Visible. Ostatecznie cały gotowy template będzie wyglądał w następujący sposób

<ControlTemplate x:Key="PhoneDisabledTextBoxTemplate" TargetType="TextBox">
    <ContentControl x:Name="ContentElement" BorderThickness="0" HorizontalContentAlignment="Stretch" Margin="{StaticResource PhoneTextBoxInnerMargin}" Padding="{TemplateBinding Padding}" VerticalContentAlignment="Stretch"/>
    </ControlTemplate>
    <Style TargetType="TextBox">
        <Setter Property="FontFamily" Value="{StaticResource PhoneFontFamilyNormal}"/>
        <Setter Property="FontSize" Value="{StaticResource PhoneFontSizeMediumLarge}"/>
        <Setter Property="Background" Value="{StaticResource PhoneTextBoxBrush}"/>
        <Setter Property="Foreground" Value="{StaticResource PhoneTextBoxForegroundBrush}"/>
        <Setter Property="BorderBrush" Value="{StaticResource PhoneTextBoxBrush}"/>
        <Setter Property="SelectionBackground" Value="{StaticResource PhoneAccentBrush}"/>
        <Setter Property="SelectionForeground" Value="{StaticResource PhoneTextBoxSelectionForegroundBrush}"/>
        <Setter Property="BorderThickness" Value="{StaticResource PhoneBorderThickness}"/>
        <Setter Property="Padding" Value="2"/>
        <Setter Property="Template">
            <Setter.Value>
                <ControlTemplate TargetType="TextBox">
                    <StackPanel Background="Transparent">
                        <VisualStateManager.VisualStateGroups>
                            <VisualStateGroup x:Name="CommonStates">
                                <VisualState x:Name="Normal"/>
                                <VisualState x:Name="MouseOver"/>
                                <VisualState x:Name="Disabled">
                                    <Storyboard>
                                        <ObjectAnimationUsingKeyFrames Storyboard.TargetProperty="Visibility" Storyboard.TargetName="EnabledBorder">
                                            <DiscreteObjectKeyFrame KeyTime="0">
                                                <DiscreteObjectKeyFrame.Value>
                                                    <Visibility>Collapsed</Visibility>
                                                </DiscreteObjectKeyFrame.Value>
                                            </DiscreteObjectKeyFrame>
                                        </ObjectAnimationUsingKeyFrames>
                                        <ObjectAnimationUsingKeyFrames Storyboard.TargetProperty="Visibility" Storyboard.TargetName="DisabledOrReadonlyBorder">
                                            <DiscreteObjectKeyFrame KeyTime="0">
                                                <DiscreteObjectKeyFrame.Value>
                                                    <Visibility>Visible</Visibility>
                                                </DiscreteObjectKeyFrame.Value>
                                            </DiscreteObjectKeyFrame>
                                        </ObjectAnimationUsingKeyFrames>
                                    </Storyboard>
                                </VisualState>
                                <VisualState x:Name="ReadOnly">
                                    <Storyboard>
                                        <ObjectAnimationUsingKeyFrames Storyboard.TargetProperty="Visibility" Storyboard.TargetName="EnabledBorder">
                                            <DiscreteObjectKeyFrame KeyTime="0">
                                                <DiscreteObjectKeyFrame.Value>
                                                    <Visibility>Collapsed</Visibility>
                                                </DiscreteObjectKeyFrame.Value>
                                            </DiscreteObjectKeyFrame>
                                        </ObjectAnimationUsingKeyFrames>
                                        <ObjectAnimationUsingKeyFrames Storyboard.TargetProperty="Visibility" Storyboard.TargetName="DisabledOrReadonlyBorder">
                                            <DiscreteObjectKeyFrame KeyTime="0">
                                                <DiscreteObjectKeyFrame.Value>
                                                    <Visibility>Visible</Visibility>
                                                </DiscreteObjectKeyFrame.Value>
                                            </DiscreteObjectKeyFrame>
                                        </ObjectAnimationUsingKeyFrames>
                                        <ObjectAnimationUsingKeyFrames Storyboard.TargetProperty="Background" Storyboard.TargetName="DisabledOrReadonlyBorder">
                                            <DiscreteObjectKeyFrame KeyTime="0" Value="{StaticResource PhoneTextBoxBrush}"/>
                                        </ObjectAnimationUsingKeyFrames>
                                        <ObjectAnimationUsingKeyFrames Storyboard.TargetProperty="BorderBrush" Storyboard.TargetName="DisabledOrReadonlyBorder">
                                            <DiscreteObjectKeyFrame KeyTime="0" Value="{StaticResource PhoneTextBoxBrush}"/>
                                        </ObjectAnimationUsingKeyFrames>
                                        <ObjectAnimationUsingKeyFrames Storyboard.TargetProperty="Foreground" Storyboard.TargetName="DisabledOrReadonlyContent">
                                            <DiscreteObjectKeyFrame KeyTime="0" Value="{StaticResource PhoneTextBoxReadOnlyBrush}"/>
                                        </ObjectAnimationUsingKeyFrames>
                                    </Storyboard>
                                </VisualState>
                            </VisualStateGroup>
                            <VisualStateGroup x:Name="FocusStates">
                                <VisualState x:Name="Focused">
                                    <Storyboard>
                                        <ObjectAnimationUsingKeyFrames Storyboard.TargetProperty="Background" Storyboard.TargetName="EnabledBorder">
                                            <DiscreteObjectKeyFrame KeyTime="0" Value="{StaticResource PhoneTextBoxEditBackgroundBrush}"/>
                                        </ObjectAnimationUsingKeyFrames>
                                        <ObjectAnimationUsingKeyFrames Storyboard.TargetProperty="BorderBrush" Storyboard.TargetName="EnabledBorder">
                                            <DiscreteObjectKeyFrame KeyTime="0" Value="{StaticResource PhoneTextBoxEditBorderBrush}"/>
                                        </ObjectAnimationUsingKeyFrames>
                                    </Storyboard>
                                </VisualState>
                                <VisualState x:Name="Unfocused"/>
                            </VisualStateGroup>
                            <VisualStateGroup x:Name="ValidationStates">
                                <VisualState x:Name="Valid" >
                                    <Storyboard>
                                        <ObjectAnimationUsingKeyFrames Storyboard.TargetProperty="Visibility" Storyboard.TargetName="ValidationBorder">
                                            <DiscreteObjectKeyFrame KeyTime="0" Value="Collapsed" />
                                        </ObjectAnimationUsingKeyFrames>
                                        <ObjectAnimationUsingKeyFrames Storyboard.TargetProperty="Visibility" Storyboard.TargetName="ValidationMessage">
                                            <DiscreteObjectKeyFrame KeyTime="0" Value="Collapsed" />
                                        </ObjectAnimationUsingKeyFrames>
                                    </Storyboard>
                                </VisualState>
                                <VisualState x:Name="InvalidFocused" >
                                    <Storyboard>
                                        <ObjectAnimationUsingKeyFrames Storyboard.TargetProperty="Visibility" Storyboard.TargetName="ValidationBorder">
                                            <DiscreteObjectKeyFrame KeyTime="0" Value="Visible" />
                                        </ObjectAnimationUsingKeyFrames>
                                        <ObjectAnimationUsingKeyFrames Storyboard.TargetProperty="Visibility" Storyboard.TargetName="ValidationMessage">
                                            <DiscreteObjectKeyFrame KeyTime="0" Value="Visible" />
                                        </ObjectAnimationUsingKeyFrames>
                                    </Storyboard>
                                </VisualState>
                                <VisualState x:Name="InvalidUnfocused" >
                                    <Storyboard>
                                        <ObjectAnimationUsingKeyFrames Storyboard.TargetProperty="Visibility" Storyboard.TargetName="ValidationBorder">
                                            <DiscreteObjectKeyFrame KeyTime="0" Value="Visible" />
                                        </ObjectAnimationUsingKeyFrames>
                                        <ObjectAnimationUsingKeyFrames Storyboard.TargetProperty="Visibility" Storyboard.TargetName="ValidationMessage">
                                            <DiscreteObjectKeyFrame KeyTime="0" Value="Visible" />
                                        </ObjectAnimationUsingKeyFrames>
                                    </Storyboard>
                                </VisualState>
                            </VisualStateGroup>
                        </VisualStateManager.VisualStateGroups>
                        <Grid>
                            <Grid.RowDefinitions>
                                <RowDefinition Height="Auto"></RowDefinition>
                                <RowDefinition Height="Auto"></RowDefinition>
                            </Grid.RowDefinitions>
                            <Border x:Name="EnabledBorder" BorderBrush="{TemplateBinding BorderBrush}" BorderThickness="{TemplateBinding BorderThickness}" Background="{TemplateBinding Background}" Margin="{StaticResource PhoneTouchTargetOverhang}">
                                <ContentControl x:Name="ContentElement" BorderThickness="0" HorizontalContentAlignment="Stretch"   Padding="{TemplateBinding Padding}" VerticalContentAlignment="Stretch"/>
                            </Border>
                            <Border x:Name="DisabledOrReadonlyBorder" BorderBrush="{StaticResource PhoneDisabledBrush}" BorderThickness="{TemplateBinding BorderThickness}" Background="Transparent" Margin="{StaticResource PhoneTouchTargetOverhang}" Visibility="Collapsed">
                                <TextBox x:Name="DisabledOrReadonlyContent" Background="Transparent" Foreground="{StaticResource PhoneDisabledBrush}" FontWeight="{TemplateBinding FontWeight}" FontStyle="{TemplateBinding FontStyle}" FontSize="{TemplateBinding FontSize}" FontFamily="{TemplateBinding FontFamily}" IsReadOnly="True" SelectionForeground="{TemplateBinding SelectionForeground}" SelectionBackground="{TemplateBinding SelectionBackground}" TextAlignment="{TemplateBinding TextAlignment}" TextWrapping="{TemplateBinding TextWrapping}" Text="{TemplateBinding Text}" Template="{StaticResource PhoneDisabledTextBoxTemplate}"/>
                            </Border>
                            <Border x:Name="ValidationBorder" Grid.RowSpan="2" BorderBrush="Red" BorderThickness="2" Visibility="Collapsed"  >
                            </Border>
                            <TextBlock x:Name="ValidationMessage" Foreground="Red" FontSize="16" Visibility="Collapsed" Grid.Row="1" Text="{Binding (Validation.Errors)[0].ErrorContent, RelativeSource={RelativeSource TemplatedParent}}"  Padding="0,0,0,2" Margin="10,-14,0,0"  />

                        </Grid>

                    </StackPanel>
                </ControlTemplate>
            </Setter.Value>
        </Setter>
    </Style>
</ControlTemplate>

Tak natomiast przedstawiają się błędy walidacji wyświetlone na TextBoxach

Tworzenie bootstrappera aplikacji przy użyciu CaliburnMicro

Mon, 07 May 2012 19:24:00 GMT

Witam po długiej przerwie. W dzisiejszym wpisie postaram się krótko opisać w jaki sposób stworzyć bootstrapper aplikacji przy użyciu CaliburnMicro. Ponadto przedstawię w jaki sposób skonfigurować bootstrapper w taki sposób, aby Caliburn wykorzystywał nasz własny kontener IOC.

1. Wstęp

CaliburnMicro jest to framework MVVM, który w znacznym stopniu ułatwia i przyśpiesza pisanie aplikacji pod WPF,Silverlight,WindowsPhone oraz WinRT. Zdecydowałem się poznać ten framework z uwagi na jego przenośność na różne platformy. Wcześniej całkiem sporo czasu poświęciłem Prismowi, jednakże z powodu licznych problemów z jego działaniem pod WindowsPhonem chciałem spróbować czegoś nowego.

2. Bootstrapper - Silverlight

Bootstrapper jest to ogólnie rzecz biorąc klasa inicjalizująca całą aplikację. W trakcie odpalania bootstrappera na ogół konfiguruje się kontener IOC(rejestruje wszystkie potrzebne typu), inicjalizuje się połączenie z serverem, oraz odpala się główne okno aplikacji - tzw. Shella. Dlatego też musimy odchudzić plik App.xaml.cs i zostawić w nim jedynie konstruktor wraz z wywołaniem funkcji InitializeComponents

public partial class App : Application
{
    public App()
    {          
        InitializeComponent();
    }
}

Zacznijmy od utworzenia nowego projektu typu SilverlightApplication, do którego dodajemy referencje do dll-ek Cliburna. Możemy to zrobić poprzez NuGetta (niestety u mnie one nie działały :D), jak również możemy je ściągnąć z oficjalnej strony projektu. Następnie stwórzmy główne okno aplikacji(wspomnianego wcześniej Shella) oraz jego viewmodel. W tym celu dodajemy do projektu Silverlight User Control o nazwie ShellView

oraz nową klasę ShellViewModel.

Dorzućmy jeszcze jakiegoś TextBox-a do naszego ShellView, tak aby mieć pewność, że rzeczywiście odpowiednie okno jest widoczne przy starcie aplikacji

<UserControl x:Class="Loginv2.ShellView"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
    xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
             xmlns:cal="clr-namespace:Caliburn.Micro;assembly=Caliburn.Micro" mc:Ignorable="d" Height="516" Width="792">

    <Grid x:Name="LayoutRoot"  >
        <TextBox Text="oto jest shell"/>
    </Grid>
</UserControl>

W kolejnym kroku musimy stworzyć właściwy bootstrapper - dodajmy nową klasę o nazwie SilverlightBootstrapper, która dziedziczyć będzie po klasie Bootstrapper

namespace Client.Silverlight
{
    public class SilverlightBootstrapper : Bootstrapper<ShellViewModel>
    {
    
    }
}

Klasa Bootstrapper jest to klasa dostarczona przez CaliburnMicro, generyczny parametr T określa nam viewmodel na podstawie którego framework będzie wyszukiwał odpowiedni widok shella ze swojego wbudowanego kontenera IOC (Caliburn podczas uruchomienia aplikacji rejestruje dostępne typu w kontenerze). Zgodnie z domyślną konwencją, CaliburnMicro jako główne okno aplikacji ustawi widok, który nazywać się będzie ShellView. W celu odpalenia naszego bootstrappera musimy jeszcze umieścić go w zasobach aplikacji. Zmodyfikujmy zatem plik App.xaml aby wyglądał w następujący sposób

<Application xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
             xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
             xmlns:Silverlight="clr-namespace:Client.Silverlight" x:Class="Client.Silverlight.App">
    <Application.Resources>
        <Silverlight:SilverlightBootstrapper x:Key="Bootstrapper"></Silverlight:SilverlightBootstrapper>
    </Application.Resources>
</Application>

Kompilując, a następnie uruchamiając nasz projekt naszym oczom powinien ukazać się następujący widok

Powyżej przedstawiłem w jaki sposób stworzyć najprostszą wersję bootstrapera z wykorzystaniem CaliburnMicro oraz jego domyślnego kontenera IOC. Jednakże najczęściej jest tak, że w aplikacji wykorzystujemy już jakiś bardziej zaawansowany kontener i po prostu nie chcemy wykorzystywać jednego kontenera do "rozwiązywania" widoków, a drugiego do pozostałych rzeczy. Dlatego też pokaże teraz w jaki sposób skonfigurować napisany wcześniej bootstrapper tak aby widoki były wyciągane z naszego kontenera IOC. Zacznijmy do dodania do naszego projektu referencji do NInjecta, a następnie utwórzmy klasę IOCContainer (będącą naszym customowym kontenerem), wyglądającą w następujący sposób

public class IOCContainer
{
    private static readonly IKernel Kernel = new StandardKernel();

    protected IOCContainer()
    {

    }

    public static void Dispose()
    {
        Kernel.Dispose();
    }

    public static object Get(Type type)
    {
        return Kernel.Get(type);
    }

    public static object Get(Type type,string key)
    {
        return Kernel.Get(type, key);
    }
  
    public static IEnumerable<object>  GetAll(Type instanceType)
    {
        return Kernel.GetAll(instanceType);
    }
  
    public static void Bind<T, TS>() where TS : T
    {
        Kernel.Bind<T>().To<TS>();
    } 
}

Następnie w klasie SilverlightBootstraper musimy przeciążyć funkcję Configure, GetAllInstances oraz GetInstance. Jako, że będziemy korzystali z naszego własnego kontenera w funkcji Configure rejestrujemy wszystkie potrzebne nam viewmodele oraz widoki. Zatem funkcja Configure powinna od teraz wyglądać tak

protected override void Configure()
{
    IOCContainer.Bind<ShellView, ShellView>();
    IOCContainer.Bind<ShellViewModel, ShellViewModel>();
}

Następnie musimy "pokazać" Caliburn-owi gdzie powinien szukać widoków. Dlatego też przeciążamy funkcje GetInstance oraz GetAllInstances i zmieniamy ich postać na następującą

protected override object GetInstance(Type serviceType, string key)
{
    return IOCContainer.Get(serviceType, key);
}

protected override IEnumerable<object> GetAllInstances(Type serviceType)
{
    return IOCContainer.GetAll(serviceType);
}

Od tej pory, za każdym razem gdy użyjemy mechanizmów Caliburna do bindowania viewmodelu z widokiem itp., Caliburm będzie szukał widoków oraz viewmodeli w naszym kontenerze IOC.

2.2 Własna konwencja wyszukiwania widoków

W przedstawionym powyżej przykładzie bootstrappera, nasz bootstrapper korzystał z domyślnej konwencji rozwiązywania widoków na podstawie viewmodeli (do ShellViewModel został dopasowany widok ShellView). Czasem jednak konwencja ta, nie pasuje do konwencji przyjętej w danym projekcie. Sam biorę udział w projekcie, w którym widoki w kontenerze są rejestrowane następujący sposób

IOCContainer.Bind<IView<ViewModel>, View>

Czy zatem oznacza to, że nie mogę korzystać już mechanizmów Caliburna i musze zrezygnować chociażby z bootstrappera? Oczywiście, że nie. Framework dostarcza nam możliwość zdefiniowania własnej konwencji wyszukiwania widoków na podstawie viewmodeli. W celu zastąpienia domyślnej konwencji musimy podpiąć się pod propercję LocateForModelType znajdującą się w klasie ViewLocator i zdefiniować własną funkcję wyszukującą widok na podstawie viewmodelu. W moim przypadku wygląda to w następujący sposób

ViewLocator.LocateForModelType = (modelType, displayLocation, context) =>
                                                 {
                                                     string viewTypeName = string.Format("{0}[[{1}]],{2}", typeof(IView<>).FullName, modelType.AssemblyQualifiedName, typeof(IView<>).Assembly.FullName);
                                                     Type viewType = Type.GetType(viewTypeName);
                                                     if (viewType == null)
                                                         throw new ArgumentNullException(string.Format("Nie odnaleziono typu widoku dla viewModelu"), modelType.FullName);

                                                     return ViewLocator.GetOrCreateViewType(viewType);
                                                 };

Funkcja ViewLocator.LocateForModelType odpalana jest za każdym razem, gdy CaliburnMicro chce wyszukać widok na podstawie viewmodleu. Najważniejszym argumentem funkcji LocateForModelType jest modelType - czyli typ viewmodelu, który posłuży nam do znalezienia widoku - a właściwie jego typu. Po odnalezieniu typu widoku, wywołujemy funkcję ViewLocator.GetOrCreateViewType(viewType); (które z kolei znajdzie nam w kontenerze pożądanym przez nas typ widoku) i zwracamy jej rezultat.

3. Bootstrapper - Windows Phone

W przypadku bootstrappera dla Windows Phona sytuacja wygląda odrobinę inaczej. W celu utworzenia własnego bootstrappera musimy rozszerzyć klasę PhoneBootstrapper. Utwórzmy zatem nowy projekt typu Windows Phone Application, oraz dodajmy do niego nową kontrolkę typu Windows Phone Portrait Page.

Podobnie jak w przypadku projektu Silverlightowego dodajemy referencję do CaliburnMicro, dorzucamy klasę viewmodelu (którą nazywamy ShellViewModel) oraz dodajemy jakiegoś textboxa do ShellView. Następnie musimy utworzyć nasz bootstrapper, dodajmy zatem klasę WindowsPhoneBootstrapper rozszerzającą klasę PhoneBootstrapper. Podobnie jak w przypadku bootstrappera silverlightowego przeciążamy funkcje odpowiedzialne za konfigurację kontenera IOC.

public class WindowsPhoneBootstrapper : PhoneBootstrapper
{
    protected override void Configure()
    {
      
       IOCContainer.BindToConstant<INavigationService>(new FrameAdapter(RootFrame));
       IOCContainer.BindToConstant<IPhoneService>(new PhoneApplicationServiceAdapter(RootFrame));
       IOCContainer.BindAsSingleton<ShellViewModel, ShellViewModel>();
    }

    protected override void OnExit(object sender, EventArgs e)
    {
        IOCContainer.Dispose();
        base.OnExit(sender, e);
    }

    protected override object GetInstance(Type serviceType, string key)
    {
        return IOCContainer.Get(serviceType, key);
    }

    protected override IEnumerable<object> GetAllInstances(Type serviceType)
    {
        return IOCContainer.GetAll(serviceType);
    }

    protected override void BuildUp(object instance)
    {
        IOCContainer.Inject(instance);
    }
}

Zwróćmy uwagę, że w kontenerze IOC zostały zarejestrowane usługi nawigacji Windows Phona, do których został przekazany RootFrame. RootFrame jest to główne okno aplikacji, zostaje ono utworzone przez CliburnMicro. Tak samo jak w przypadku projektu Silverlightowego w pliku App.xaml.cs zostawiamy jedynie konstruktor z wywołaniem funkcji InitializeComponents. W celu ustawienia ShellView jako RootFram-a musimy zmodyfikować plik WMAppManifest.xml (znajdujący się w katalogu Properties). Odnajdujemy tam wpis

<DefaultTask  Name ="_default" NavigationPage="MainPage.xaml"/>

i zamieniamy go na

<DefaultTask  Name ="_default" NavigationPage="ShellView.xaml"/>

Jak widać WindowsPhone wymusza tutaj podejście ViewFirst. Przy uruchomieniu aplikacji mechanizm nawigacji WindowsPhona odpali widok ShellView (bez wiedzy Caliburn'a), natomiast CaliburnMicro dopasuje odpowiedni ViewModel do naszego widoku - na podstawie domyślnej konwencji. Jeżeli chcielibyśmy zmodyfikować sposób wyszukiwania ViewModeli do widoków musimy podpiąć się do propertisa LocateForViewType znajdującego się w klasie ViewModelLocator

ViewModelLocator.LocateForViewType = type => { return //tutaj zwroc odpowiedni viewmodel na podstawie parametru type; };

W ostatnim kroku musimy jeszcze tylko dodać nasz bootstrapper do zasobów aplikacji

<Application.Resources>
        <Bootstrapper:WindowsPhoneBootstrapper x:Key="Bootstrapper"></Bootstrapper:WindowsPhoneBootstrapper>
</Application.Resources>

odpalając teraz program naszym oczom powinien ukazać się taki oto widok

FluentNhibernate - mapowanie kolumn typu time

Tue, 13 Mar 2012 21:36:00 GMT

Ostatnio napotkałem na dość ciekawy wyjątek podczas wykonywania NHibernatowego inserta. W bazie danych mam prostą tabelę

Do takiej tabeli został stworzony model

namespace Model
{
    public class Appointment
    {
        public virtual int Id { get; set; }
        public virtual string Name { get; set; }
        public virtual DateTime StartDate { get; set; }
        public virtual TimeSpan Duration { get; set; }
    }
}

oraz mapping

namespace Model.Mappings
{
    public class AppointmentMapping : ClassMap<Appointment>
    {
        public AppointmentMapping()
        {
            Id(val => val.Id).GeneratedBy.Native();
            Map(val => val.Name).Not.Nullable();
            Map(val => val.StartDate).Not.Nullable();
            Map(val => val.Duration).Not.Nullable();
        }
    }
}

Niestety ku mojemu zaskoczeniu próbując zapisać do bazy obiekt typu Appointment dostałem następujący wyjątek SqlException: Operand type clash: bigint is incompatible with time

Mówiąc szczerze wyjątek ten niewiele mi powiedział, zwłaszcza, że zapytanie wygenerowane przez NHibernata (przechwycone w NHibernateProfilerze) wyglądało jak najbardziej poprawnie. Jednakże zapytanie przechwycone przez SqlProfilera wyglądało w następujący sposób

exec sp_executesql N'INSERT INTO [Appointment] (Name,StartDate,Duration) VALUES (@p0,@p1,@p2); 
select SCOPE_IDENTITY()',
N'@p0 nvarchar(4000),
@p1 datetime,
@p2 bigint',
@p0=N'appoitnemt',
@p1='2012-03-13 00:00:00',
@p2=439320000000

Widać tutaj, że drugi parametr (@p2) został oznaczony jako bigint, a nie time (tak jak jest to oznaczone w bazie). Przyczyną takiego stanu rzeczy jest zły mapping. Z tego co wyczytałem, jeżeli chcemy aby poprawnie zmapować TimeSpana na kolumnę typu time, musimy zmodyfikować interesujący nas mapping na następujący.

Map(val => val.Duration).Not.Nullable().CustomType("TimeAsTimeSpan");

Mając taki mapping nasze zapytanie zostanie wygenerowane poprawnie i operacja insertu zakończy się powodzeniem

Definiowanie własnego operatora rzutowania

Sun, 26 Feb 2012 21:54:00 GMT

Ostatnio modyfikując mój kod stanąłem przed problemem rzutowania obiektu typu MembershipUser(z namespaca System.Web.Security) na mój własny typ UserDTO. Klasa UserDTO nie wyróżnia się niczym specjalnym i wygląda następująco

public class UserDTO : UserBase
{
    public string Id { get; set; }

    public string Email { get; set; }

    public string DisplayName { get; set; }
}

Podejściem dość oczywistym w takim przypadku jest utworzenie odpowiedniego konstruktora w klasie UserDTO, przyjmującego jako parametr obiekt typu MembershipUser. Jednakże można również utworzyć własny operator rzutowania, dzięki któremu zapis

 
MembershipUser user = new MembershipUser(/*jakies parametry*/);
UserDTO dtoUser = (UserDTO) user;

będzie poprawny. Wszystko sprowadza się do użycia dwóch słów kluczowych:

operator
explicit

W klasie UserDTO musimy dopisać następujący kod

public static explicit operator UserDTO(MembershipUser user)
{
    if (user == null)
        throw new ApplicationException("Parametr user nie może być null-em");

    return new UserDTO {   
                          Id = user.ProviderUserKey is Guid ? ((Guid)user.ProviderUserKey).ToString() : user.ProviderUserKey.ToString(),
                          Name = user.UserName,
                          Email = user.Email,
                       };
}

Jak widać tworzymy nowy operator konwersji, w którym po prawej stronie wyrażenia musi stać obiekt typu MembershipUser. Od teraz za każdym razem gdy będziemy chcieli rzutować obiekt MembershipUser na UserDTO będziemy mogli posłużyć się następującą konstrukcją.

UserDTO dtoUser = (UserDTO) membershipUser;

Rzutowanie z UserDTO na MembershipUser nie jest dozwolone (przy wykorzystaniu wyżej wymienionego kodu), ale nic nie stoi na przeszkodzie aby zdefiniować drugi operator rzutowania

public static explicit operator MembershipUser(UserDTO userDto)
{
    //tutaj odpowiedni kod
}

który zapewni nam konwersję odwrotną

ASP.NET MVC - okna modalne z wykorzystaniem Kendo UI

Sat, 04 Feb 2012 22:39:00 GMT

Ostatnimi czasy w pracy eksperymentujemy z ASP.NET MVC. Jednym z problemów na jakie natknąłem się poznając tą technologię było utworzenie okien modalnych. Po niezbyt owocnej walce z kontrolkami ze stajni Devexpressa postanowiliśmy, że skorzystamy z darmowej biblioteki Kendo UI napisanej w jQuery. Wspomnianą wcześniej bibliotekę możemy znaleźć pod adresem http://www.kendoui.com/get-kendo-ui.aspx. Aby uzyskać dostęp do plików należy zarejestrować się w systemie - oczywiście rejestracja jest darmowa. Po zassaniu wszystkich plików kopiujemy zawartość katalogu "source" do naszego projektu MVC. W moim przypadku utworzyłem katalog Kendo w katalogu Content i tam umieściłem zawartość katalogu source.

Mając wszystkie pliki w komplecie musimy wskazać naszej aplikacji aby zaczęła z nich korzystać. Dodajmy zatem w pliku _Layout.cshtml następujące elementy

<script src="@Url.Content("~/Content/Kendo/js/jquery.min.js")" type="text/javascript"></script>
<link href="@Url.Content("~/Content/Site.css")" rel="stylesheet" type="text/css" />
<link href="@Url.Content("~/Content/Kendo/styles/kendo.common.css")" rel="stylesheet"/>
<link href="@Url.Content("~/Content/Kendo/styles/kendo.default.css")" rel="stylesheet"/>
<script src="@Url.Content("~/Scripts/jquery-1.5.1.min.js")" type="text/javascript"></script>
<script src="@Url.Content("~/Content/Kendo/js/jquery.min.js")" type="text/javascript"></script>
<script src="@Url.Content("~/Content/Kendo/js/kendo.core.js")" type="text/javascript"></script>
<script src="@Url.Content("~/Content/Kendo/js/kendo.data.js")" type="text/javascript"></script>
<script src="@Url.Content("~/Content/Kendo/js/kendo.pager.js")" type="text/javascript"></script>
<script src="@Url.Content("~/Content/Kendo/js/kendo.selectable.js")" type="text/javascript"></script>
<script src="@Url.Content("~/Content/Kendo/js/kendo.draganddrop.js")" type="text/javascript"></script>
<script src="@Url.Content("~/Content/Kendo/js/kendo.groupable.js")" type="text/javascript"></script>
<script src="@Url.Content("~/Content/Kendo/js/kendo.grid.js")" type="text/javascript"></script>
<script src="@Url.Content("~/Content/Kendo/js/kendo.fx.js")" type="text/javascript"></script>
<script src="@Url.Content("~/Content/Kendo/js/kendo.resizable.js")" type="text/javascript"></script>
<script src="@Url.Content("~/Content/Kendo/js/kendo.window.js")" type="text/javascript"></script>

Przejdźmy teraz do najważniejszej części, a mianowicie do tworzenia okna modalnego. Biblioteka Kendo UI udostępnia nam funkcję kendoWindow, dzięki której jesteśmy w stanie utworzyć okno modalne. Okno to jednak nie ma w sobie żadnej zawartości - nie posiada nawet przycisków typu Zapisz oraz Anuluj. Utworzenie i załadowanie zawartości okna oraz reakcja na kliknięcia w potencjalne przyciski musi zostać obsłużona przez nas. Zacznijmy zatem od utworzenia zawartości okna. Załóżmy, że okno, które za chwilę stworzymy będzie służyło do dodawania nowego produktu do bazy danych. Klasa produkt jest bardzo prostą klasą prezentującą się w następujący sposób:

public class Product
{
    public string Id { get; set; }
    public string Name { get; set; }
    public int Quantity { get; set; }
}

Stwórzmy zatem strongly-typed partial view, który będzie zawartością naszego okna modalnego. Widok ten będzie posiadał dwa textboxy do wypełniania propertisów obiektu, oraz przyciski Zapisz oraz Anuluj. Zacznijmy od dodania odpowiednich funkcji w kontrolerze. Pierwszą z nich będzie akcja AddProduct();

public PartialViewResult AddProduct()
{
    return PartialView("AddProduct", new Product());
}

W celu dodania widoku klikamy PPM na nazwę funkcji i wybieramy opcję Add View. W otwartym oknie zaznaczmy opcję Create Strongly Typed View, a w comboboxie wpisujemy Product. Ponadto zaznaczamy checkboxa Create as a partial view.

W katalogu Home pojawił się nowy plik AddProduct.cshtml. W pliku tym zdefiniujemy wygląd zawartości naszego okna modalnego. Jako, że nasze dane będą musiały zostać wysłane na serwer do zapisu, skorzystamy z funkcji pomocniczej Html.BeginForm, w której to umieścimy wszystkie potrzebne elementy do edycji produktu.

@model ModalDialogs.Models.Product
<div id="windowContent">
    @using (Html.BeginForm("AddProduct", "Home", FormMethod.Post, new { id = "fmAddProduct" }))
    {
        @Html.ValidationSummary(true)
        <div>
            @Html.Label("lblName", "Nazwa")
            @Html.TextBoxFor(val => val.Name)
            @Html.ValidationMessageFor(val => val.Name)
        </div>
        <div>
            @Html.Label("lblQuantity", "Ilość")
            @Html.TextBoxFor(val => val.Quantity)
            @Html.ValidationMessageFor(val => val.Quantity)
        </div>
        <input type="button" value="Zapisz" id="btnSave" />
        <input type="button" value="Anuluj" id="btnCancel" />
    }
</div>

Dodajmy teraz na naszej stronie głównej linka, który wywoła nasze okno modalne.

@Html.ActionLink("Dodaj produkt", "AddProduct", "Home", null, new { id = "addProduct" })

Przyszedł teraz czas na najważniejszą część wpisu, a mianowicie na wykorzystaniu jQuery oraz kendoWindow do pokazania okna edycji/dodawania produktu. Najpierw podpinamy się do zdarzenia(dodajemy handler) click utworzonego przed chwilą odnośnika. W funkcji obsługującej zdarzenie click musimy utworzyć okno, wypełnić jego zawartość oraz pokazać okno.

$(document).ready(function () {
        var $kendoWindow;
        $("#addProduct").click(function (event) {
            debugger;
            event.preventDefault(); // anulujemy domyślną akcję
            var $dialog = $('<div></div>');
            var $url = $(this).attr('href'); //wyciągamy  url-a
            $dialog.empty();
            $kendoWindow = $dialog.kendoWindow({ //tworzmy okno
                height: "200px", //o wysokosci 200px
                title: "Dodaj", // z tytulem "Dodaj"
                width: "200px", // o szerokosci 200px
                actions: ["Close"], // ktore mozna jedynie zamknac - nie mozna przesuwac, odswiezac itp
                content: $url // ktorego zawartosc pobieramy z urla przechwyconego z clica

            }).data("kendoWindow");
            $kendoWindow.center(); //centrujemy okno
            $kendoWindow.open(); // otwieramy
        });
...
...
...
}

Korzystając z selektora jQuery znajdujemy link opisany id-kiem addProduct, a następnie podłączamy się do zdarzenia click. W funkcji obsługującej zdarzenie musimy najpierw zapobiec wywołaniu się domyślnej akcji wykonującej się po naciśnięciu na link. Robimy to przy pomocy funkcji prefentDefault(). W kolejnych krokach tworzymy okno modalne zgodnie ze wskazówkami znajdującymi się w dokumentacji Kendo UI. Najważniejszym elementem przy tworzeniu okna jest dynamiczne załadowanie jego zawartości poprzez podanie linka do akcji w kontrolerze. Linka tego jesteśmy w stanie wyciągnąć wykorzystując kolejną użyteczną funkcję jQuery - attr('nazwaAtrybutu'). Od tej chwili po naciśnięciu odnośnika Dodaj produkt zawsze będzie odpalane okno modalne dodawania nowego produktu. Teraz musimy jeszcze obsłużyć zdarzenia click na przyciskach Zapisz oraz Anuluj. Do funkcji przedstawionej powyżej dopisujemy następujące linijki

$("#btnSave").live("click", function (event) {
            event.preventDefault(); // anulujemy domyślną akcję
            var $url = $("#fmAddProduct").attr("action"); //wyciągamy  url-a
           // odpalamy ajaxa w celu wywołania akcji kontrolera
            $.ajax(
                {
                    url: $url,  // podajemy url z akcja kontrolera
                    type: "POST", // okreslamy metode 
                    data: $("#fmAddProduct").serialize(), // przekazujemy dane 
                    success: function (response) {       //w przypadku gdy wszystko OK
                        $("#btnSave").unbind(); // odpinamy zdarzenia
                        $("btnCancel").unbind();
                        $kendoWindow.close(); //zamykamy i 
                        $kendoWindow.destroy(); // niszczymy okno
                    },
                    error: function (response) {
                        $("#btnSave").unbind(); //odpinamy zarzenia
                        $("btnCancel").unbind();
                        $kendoWindow.content(response.responseText); //odswiezamy zawartosc okna
                    }
                });
        });

        $("#btnCancel").live("click", function (event) {
            event.preventDefault();// anulujemy domyślną akcję
            $("#btnSave").unbind(); //odpinamy zdarzenia
            $("btnCancel").unbind();
            $kendoWindow.close(); //zamykamy i
            $kendoWindow.destroy(); // niszczymy okno
        });

Tutaj sytuacja odrobinę się komplikuje gdyż musimy wysłać wprowadzone dane do kontrolera oraz obsłużyć ewentualne błędy walidacji. Zaczynamy od znalezienia przycisku opisanego id-kiem btnSave oraz podpięcia się do zdarzenia click. Ponownie anulujemy domyślną akcję wywołując funkcję preventDefault. W kolejnym kroku wyciągamy url-a, który miał zostać wywołany po naciśnięciu przycisku. Robimy to, ponownie wykorzystując funkcję attr('nazwaAtrybutu'). Jednakże teraz wyszukujemy tego atrybutu na obiekcie o id ="fmAddProduct" (taki id nadaliśmy "formie" na której są pola edycyjne produktu). Ostatnim elementem jest wykonanie asynchronicznego zapytania AJAX. Do tego zapytania przekazujemy wcześniej uzyskany url,określamy typ zapytania jako POST oraz przesyłamy dane wykorzystując funkcję serialize z biblioteki jQuery. Na samym końcu musimy sprecyzować co ma się stać w przypadku gdy wszystko pójdzie ok - parametr success, a co w przypadku gdy coś będzie nie tak - parametr error. Musimy oczywiście dodać do kontrolera jeszcze jedną akcję. Tym razem będzie to również akcja AddProduct, jednakże będzie to akcja HttpPost posiadająca jeden parametr typu Product

[HttpPost]
public ActionResult AddProduct(Product product)
{
    if (ModelState.IsValid)
        return new EmptyResult();
    Response.StatusCode = (int)HttpStatusCode.BadRequest;
    return PartialView("AddProduct", product);
}

Ostatnią rzeczą jaką musimy zrobić jest wyłączenie cachowania widoków, które są pokazywane w oknie modalnym - można to zrobić wykorzystując atrybut OutputCaching. W przypadku gdy nie wyłączymy cachowania, okna modalne, które raz nie przeszły walidacji nie będą mogły zostać zapisane. W celu wyłączenia cachowania dla poszczególnych widoków najpierw musimy stworzyć profil cachowania. Dodajemy taki oto wpis do pliku Web.config

<caching>
      <outputCacheSettings>
        <outputCacheProfiles>
          <add name="DisableCaching"
               duration="0"
               varyByParam="None"
               location="None" />
        </outputCacheProfiles>
      </outputCacheSettings>
</caching>

a następnie dekorujemy atrybutem

[OutputCache(CacheProfile = "DisableCaching")]

akcje AddProduct() oraz AddProduct(Product product).

To by było na tyle, projekt można zassać z tego linka

Lokalizowanie aplikacji Silverlight i Windows Phone z wykorzystaniem Portable Shared Library

Sat, 21 Jan 2012 11:32:00 GMT

W dzisiejszym wpisie postaram się przedstawić w jaki sposób lokalizować treści aplikacji typu Silverlight oraz WindowsPhone. Założenie jest takie, że chcemy zbudować multiplatformową aplikację, która będzie obsługiwała platformę Silverlight oraz Windows Phone. Rozsądnym zatem podejściem jest trzymanie wszystkich tłumaczeń w jednym miejscu - najlepiej aby mechanizm tłumaczenia był obsługiwany zarówno przez Windows Phona jak i Silverlighta. W pierwszym kroku musimy doinstalować do środowiska Visual Studio projekt typu Portable Class Library. Referencje do tego typu projektów możemy dodawać zarówno do projektów Silverlightowych, WindowsPhonowych - zatem idealnie nadaje się na przetrzymywanie w nim mechanizmu tłumaczenia aplikacji. W celu zainstalowania wyżej wspomnianego typu projektu musimy odwiedzić następującą stronę, a następnie zassać plik instalacyjny. Mając już przygotowane środowisko, stwórzmy nową solucję i dodajmy do niej projekt typu Portable Class Library - nazwijmy go SharedPortableClasses.

Następnie dodajmy do tego projektu nowy folder Localization, w którym to umieścimy pliki typu *.resx. Pierwszy plik nazywamy po prostu Localization.resx natomiast następne nazywamy według wzorca Localization.<culture>.resx, gdzie: <culture> oznacza kulturę/język komunikatów jaki dany plik będzie przechowywać. Dla przykładu aby mechanizm tłumaczący obsługiwał język polski oraz angielski, powinniśmy stworzyć następującą strukturę plików

Localization.resx
Localization.pl-PL.resx
Localization.en-US.resx

W kolejnym kroku musimy zmienić modyfikator dostępu do naszych plików zasobów na publiczny. W tym celu klikamy podwójnie na każdy plik *.resx i z comboboxa wybieramy public

Mając przygotowane pliki zasobów, możemy teraz umieszczać w nich tłumaczone elementy interfejsów oraz komunikatów. Robimy to w następujący sposób:

W pliku Localization.resx wypełniamy pole w kolumnie Name jakąś wartością(kluczem), która identyfikuje nasz tekst (w moim przypadku będzie to Title)
W plikach Localization.pl-PL.resx oraz Localization.en-US powtarzamy tę czynność (uzupełniamy pola w kolumnie Name tymi samymi wartościami co w pliku Localization.resx) oraz wypełniamy pole w kolumnie Value tekstem w odpowiednim języku.

Mając już prawie gotowy mechanizm tłumaczący stwórzmy teraz projekt typu Silverlight Application oraz dodajmy mu referencję do projektu SharedPortableClasses. Dodajmy teraz do zasobów naszej aplikacji obiekt typu Localization

<Application.Resources>
        <Localization:Localization x:Key="LocalizationProxy" />
</Application.Resources>

Niestety z powodu tego, że klasa Localization nie posiada publicznego konstruktora bezparametrowego, nie uda nam się odpalić naszej aplikacji. Resharper od razu wyrzuci ostrzeżenie następującej treści

Zatem w jaki sposób wykorzystać nasz mechanizm tłumaczący? Rozwiązania są dwa

Zmodyfikować plik Localization.Designer.cs i ustawić konstruktor domyślny na publiczny. Takie rozwiązanie jednak nie jest eleganckie, gdyż za każdym razem gdy dodamy nowy wpis do pliku Localization.resx kod w pliku Localization.Designer.cs zostanie przegenerowany.
Drugim sposobem jest stworzenie klasy pośredniczącej, która będzie w sobie trzymała instancję obiektu Localization, oraz dodanie obiektu tej klasy pośredniczącej do zasobów aplikacji

Jako, że podejście drugi jest według mnie dużo lepsze to postaram się je teraz przedstawić. Do projektu SharedPortableClasses dodajmy klasę LocalizationProxy.cs.

public class LocalizationProxy : INotifyPropertyChanged
{
    public Localization LocalizationManager { get; private set; }

    public LocalizationProxy()
    {
        LocalizationManager = new Localization();
    }

    public void ResetResources()
    {
        OnPropertyChanged("LocalizationManager");
    }

    #region INotifyPropertyChanged region
    public event PropertyChangedEventHandler PropertyChanged;

    public void OnPropertyChanged(string propertyName)
    {
        if (PropertyChanged != null)
        {
            PropertyChanged(this, new PropertyChangedEventArgs(propertyName));
        }
    }
    #endregion
}

Teraz stwórzmy instancję tej klasy w zasobach aplikacji

<Application xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
             xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
             xmlns:Localization="clr-namespace:SharedPortableLibrary.Localization;assembly=SharedPortableLibrary"
             x:Class="LocalizationSolution.App">
    <Application.Resources>
        <Localization:LocalizationProxy x:Key="LocalizationProxy" />
    </Application.Resources>
</Application>

Zanim przystąpimy do tłumaczenia samego interfejsu musimy jeszcze zmodyfikować plik projekty *.csproj. Otwieramy nasz plik projektu w dowolnym edytorze tekstowym, a następnie w sekcji SupportedCultures dorzucamy kultury w jakich nasza aplikacja ma pracować. W moim przypadku będzie to wyglądać w następujący sposób:

Jak widać moja aplikacja będzie wspierała język angielski oraz język polski. Mając już wszystko gotowe przystąpmy do tworzenia interfejsu. Zmodyfikujmy plik MainPage.xaml tak aby wyglądał w następujący sposób

<UserControl x:Class="LocalizationSolution.MainPage"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
    xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
    mc:Ignorable="d"
    d:DesignHeight="300" d:DesignWidth="400">

    <Grid x:Name="LayoutRoot" Background="White">
        <!--TitlePanel contains the name of the application and page title-->
        <StackPanel x:Name="TitlePanel" Grid.Row="0" Margin="12,17,0,28">
            <TextBlock TextWrapping="Wrap" x:Name="PageTitle" Text="{Binding Source={StaticResource LocalizationProxy},Path=LocalizationManager.Title,Mode=TwoWay}" Margin="9,-7,0,0" />
            <Button Content="Polski" Command="{Binding PolisLanguageCommand}"  Height="72" HorizontalAlignment="Left"   VerticalAlignment="Top" Width="160"   />
            <Button Content="English" Command="{Binding EnglishLanguageCommand}" Height="72" HorizontalAlignment="Left"  VerticalAlignment="Top" Width="160"  />
        </StackPanel>
    </Grid>
</UserControl>

Widok ten jest bardzo prosty. Posada on dwa przyciski służące do zmiany aktualnego języka oraz labelkę, na której dany tekst będzie się pojawiać. Najciekawszą rzeczą w tym kodzie jest sposób wyświetlania tłumaczonego tekstu. Jak widać do właściwości Text elementu typu TextBlok nie jest przypisywana wartość stała, ale używany jest binding

Text="{Binding Source={StaticResource LocalizationProxy},Path=LocalizationManager.Title,Mode=TwoWay}"

To co wyświetli się w danym TextBloku zależne jest od tego co zwróci nam nasz mechanizm tłumaczący. Odnosimy się do niego poprzez wskazanie zasobu, który nazwaliśmy LocalizationProxy (taki klucz nadaliśmy mu w zasobach aplikacji). Następnie do konkretnego tekstu odnosimy się podając odpowiednią ścieżkę - w tym przypadku jest to LocalizationManager.Title. LocalizationManager jest to właściwość, którą stworzyliśmy w klasie LocalizationProxy, natomiast Title jest to klucz jaki wpisaliśmy w pliku zasobów Localization.resx. Przeglądając plik Localization.Designer.cs można zauważyć, że została tam wygenerowana właściwość Title.

public static string Title 
{
    get { return ResourceManager.GetString("Title", resourceCulture); }
}

Właściwość tak zwraca nam tekst w odpowiednim języku. Sam mechanizm zwracania tekstu dla wybranego przez nas języka jest już dostarczony z Frameworkiem. Tekst wyświetlany w aplikacji będzie w takim języku/kulturze jaka zostania przypisana do właściwości Thread.CurrentThread.CurrentUICulture. Możemy to w łatwy sposób sprawdzić zmieniając dynamicznie kulture wątku. Stwórzmy nową klasę i nazwijmy ją MainPageViewModel. Wygląda ona w następujący sposób

public class MainPageViewModel
{
    public DelegateCommand PolisLanguageCommand { get; set; }
    public DelegateCommand EnglishLanguageCommand { get; set; }
    public MainPageViewModel()
    {
        PolisLanguageCommand = new DelegateCommand(() =>
        {
            Thread.CurrentThread.CurrentCulture = new System.Globalization.CultureInfo("pl-PL");
            Thread.CurrentThread.CurrentUICulture = new System.Globalization.CultureInfo("pl-PL");
            ResetResources();

        });

        EnglishLanguageCommand = new DelegateCommand(() =>
        {
            Thread.CurrentThread.CurrentCulture = new System.Globalization.CultureInfo("en-US");
            Thread.CurrentThread.CurrentUICulture = new System.Globalization.CultureInfo("en-US");
            ResetResources();
        });
    }

    private void ResetResources()
    {
        ((LocalizationProxy)Application.Current.Resources["LocalizationProxy"]).ResetResources();
    }
}

Następnie stwórzmy obiekt tej klasy i przypiszmy go do DataContext-u okna MainPage.

public partial class MainPage : UserControl
{
    public MainPage()
    {
        InitializeComponent();
        DataContext = new MainPageViewModel();
    }         
}

Dzięki wykorzystaniu komend po naciśnięciu przycisku Polski zostanie odpalana komenda PolishLangugeCommand, która z kolei odpali anonimową funkcję do niej przypisaną. W funkcji tej zmienimy kulturę wątku na pl-PL. Ważnym elementem jest tutaj funkcja ResetResources, która znajduje się w klasie LocalizationProxy. Funkcja ta informuje widok (poprzez zdarzenie NotifyPropertyChanged), że należy odświeżyć wszystkie elementy, które zostały zbindowane do właściwości LocalizationManager.

Postępując w analogiczny sposób możemy stworzyć aplikację WindowsPhone, która będzie wykorzystywałą nasz mechanizm tłumaczący. Co więcej dzięki temu, że dwie aplikacje będą korzystały z tego samego mechanizmu oraz z tych samych resourców, nie musimy podwójnie wpisywać tłumaczonych tekstów.

Projekt można znaleźć pod tym linkiem

Lokalizowanie aplikacji WPF oraz Silverlight 5 przy użyciu MarkupExtension

Sat, 21 Jan 2012 11:24:00 GMT

W poprzednim wpisie przedstawiłem w jaki sposób można lokalizować aplikację napisaną w Silverlight 4 oraz Windows Phone, wykorzystując do tego ten sam mechanizm. Tym razem zademonstruje w jaki sposób można nieco uprościć składnie tłumaczenia wykorzystując do tego MarkupExtension. Jeżeli kiedykolwiek pisałeś coś w Silverlighcie, Windows Phonie lub WPF-ie istnieje duża szansa, że używałeś już MarkupExtension. Do najpopularniejszych MarkupExtensions należą takie słowa kluczowe (używane w XAML-u) jak:

Binding
StaticResource
DynamicResource
TemplateBinding

Na potrzeby mechanizmu lokalizowania aplikacji WPF (ewentualnie Silverlight 5) stworzymy customowe MarkupExtenssion, które będzie odpowiedzialne za tłumaczenie elementów UI naszej aplikacji. Zacznijmy od przygotowania plików zasobów. Podobnie jak w poprzednim wpisie utwórzmy trzy pliki:

Localization.resx
Localization.pl-PL.resx
Localization.en-US.resx

W plikach tych będziemy przechowywać nasze tłumaczenia. Następnie stwórzmy klasę Translator, która będzie dziedziczyła po klasie MarkupExtension. Do klasy tej dodajmy właściwość

public string Key { get; set; }

, która będzie przechowywać klucz dzięki któremu z pliku zasobów wyciągniemy tekst w odpowiednim języku. W kolejnym kroku musimy przeciążyć funkcję

public abstract object ProvideValue(IServiceProvider serviceProvider)

tak aby dostarczyła nam ona przetłumaczony tekst. W moim pierwszym podejściu funkcja ta wyglądała w następujący sposób

public override object ProvideValue(IServiceProvider serviceProvider)
{
    Binding binding = new Binding(Key) { Source = new Localization(),Mode = BindingMode.OneWay};
    return binding.ProvideValue(serviceProvider);
}

Wadami takiego rozwiązania było:

duża liczba tworzonych obiektów - przy każdym tłumaczeniu tworzyłem nowy obiekt Localization(), który prawdopodobnie może być dość ciężkim obiektem (zwłaszcza gdy będzie przechowywał dużo tłumaczonego tekstu)
brak możliwości dynamicznej zmiany języka

Ostatecznie zatem zrezygnowałem z przedstawionej wyżej opcji i zdecydowałem się na metodę odrobinę bardziej zaawansowaną. Po pierwsze utworzyłem klasę TranslationManager

public class TranslationManager
{
    public event Action<CultureInfo> LanguageChanged = val => { };
    private static TranslationManager _instance;
    private static readonly object LockInstance = new object();
    public static TranslationManager Instance
    {
        get
        {
            lock (LockInstance)
            {
                return _instance = _instance ?? new TranslationManager();
            }
        }
    }
    
    private CultureInfo _currentCulture;
    public CultureInfo CurrentCulture
    {
        get { return _currentCulture ?? (CurrentCulture = Thread.CurrentThread.CurrentUICulture); }
        set
        {
            _currentCulture = value;
            OnLanguageChanged(CurrentCulture);
        }
    }
    
    protected void OnLanguageChanged(CultureInfo culture)
    {
        LanguageChanged(culture);
    }
    
    private TranslationManager()
    {
    }
    
    public string Translate(string key)
    {
        return Localization.ResourceManager.GetString(key, CurrentCulture);
    }
}

która będzie zarządzała tłumaczeniami. Najważniejszą metodą tej klasy jest oczywiście funkcja

public string Translate(string key)

która to zwraca tekst w odpowiednim języku - w zależności od kultury, która zostanie ustawiona w TranslationManagerze. Ponadto TranslationManager posiada jedno zdarzenie

public event Action<CultureInfo> LanguageChanged

które ma za zadanie poinformować UI o potrzebie odświeżenia zbindowanych elementów. W jaki sposób się to odbywa? Wszystko zawdzięczamy interfejsowi INotifyPropertyChanged oraz bindingom. Funkcja ProvideValue została zmodyfikowana w następujący sposób

public override object ProvideValue(IServiceProvider serviceProvider)
{
    Binding binding = new Binding("Value") { Source = new TranslationItem(Key), Mode = BindingMode.OneWay };
    return binding.ProvideValue(serviceProvider);
}

W funkcji tej tworze binding, który binduje się do właściwości Value obiektu TranslationItem. TranslationItem jest to prosty obiekt który udostępnia właściwość Value zwracającą przetłumaczony tekst. Dodatkowo obiekt ten podpina się do zdarzenia LanguageChanged z klasy TranslationManager. W przypadku gdy ktoś zmieni język aplikacji, odpalone zostanie zdarzenie NotifyPropertyChanged, które poinformuje widok o potrzebie odświeżenia odpowiednich elementów. Klasa TranslationItem wygląda zatem w następujący sposób

public sealed class TranslationItem : INotifyPropertyChanged, IDisposable
{
    public event PropertyChangedEventHandler PropertyChanged = delegate { };
    private readonly string _key;
    public TranslationItem(string key)
    {
        _key = key;
        TranslationManager.Instance.LanguageChanged += Instance_LanguageChanged;
    }

    ~TranslationItem()
    {
        Dispose();
    }

    void Instance_LanguageChanged(System.Globalization.CultureInfo obj)
    {
        PropertyChanged(this, new PropertyChangedEventArgs("Value"));
    }

    public string Value
    {
        get { return TranslationManager.Instance.Translate(_key); }
    }

    public  void Dispose()
    {
        TranslationManager.Instance.LanguageChanged -= Instance_LanguageChanged;
    }
}

Mając gotowy mechanizm tłumaczący możemy wykorzystać go w następujący sposób w XAML-u

<Label Content="{WPFMarkupExtension:Translator Key=Title}"/>

Zauważmy, że tekst do labelki jest przypisywany z wykorzystywaniem naszego customoweog MarkupExtension - WPFMarkupExtension:Translator (WPFMarkupExtension - jest to alias na namespace, w którym znajduje się nasza klasa Translator). W składni przekazujemy do właściwości Key klucz do tekstu (znajdującego się w resourcach), który chcemy tłumaczyć. W celu zmiany języka wystarczy, że ustawimy interesującą nas kulturę w klasie TranslationManager

TranslationManager.Instance.CurrentCulture = new CultureInfo("en-US")

Przykładowy widok wykorzystujący napisany translator, oraz pokazujący dynamiczną zmianę języka może wyglądać w następujący sposób (dorzucamy następujące linijki do MainWindow.xaml)

<StackPanel>
    <Label Content="{WPFMarkupExtension:Translator Key=Key}"/>
    <Button Command="{Binding PolishCommand}">Polski</Button>
    <Button Command="{Binding EnglishCommand}">English</Button>
</StackPanel>

Następnie tworzymy ViewModel do naszego okna

public class MainPageViewModel
{
        public DelegateCommand PolishCommand { get; set; }
        public DelegateCommand EnglishCommand { get; set; }
        
        public MainPageViewModel()
        {
            PolishCommand = new DelegateCommand(()=> TranslationManager.Instance.CurrentCulture = new CultureInfo("pl-PL"));
            EnglishCommand = new DelegateCommand(()=>TranslationManager.Instance.CurrentCulture = new CultureInfo("en-US"));
        }
}

Ostatecznie przypisujemy obiekt klasy MainPageViewModel do DataContextu MainWindow.xaml

public MainWindow()
{
    InitializeComponent();
    DataContext = new MainPageViewModel();
}

Kod do projektu można znaleźć pod tym linkiem

Silverlight - koncepcja logowania z użyciem MembershipProviders oraz WCF RIA cz.3 - Microsoft Enterprise Library Security Block

Fri, 06 Jan 2012 13:47:00 GMT

W tym wpisie postaram się krótko przedstawić blok bezpieczeństwa (Security Block) z biblioteki Microsoft Enterprise Library. Biblioteki tej użyjemy do sprawdzania rol i reguł dostępu do funkcji serwisu WCF. Najpierw oczywiście musimy pobrać bibliotekę Microsoft Enterprise Library, znajduje się ona pod tym adresem. Biblioteka ta jest również dostępna z poziomu NuGeta, jednakże instalacja poprzez ten plugin dorzuca do projektu tylko dll-ki. W pierwszym przypadku natomiast oprócz dll-ek zostaje również zainstalowane bardzo wygodne narzędzie ułatwiające konfigurację różnych modułów biblioteki. Mając zainstalowane wszystkie potrzebne komponenty możemy przystąpić do działania. Zacznijmy od zmodyfikowania pliku Web.config, tak aby umożliwić naszemu systemowi korzystanie z ról - a tak właściwie aby umożliwić edycję, tworzenie, usuwanie oraz przypisywanie ról użytkownikom. W sekcji <system.web> dorzucamy następujące wpisy

<roleManager enabled="true" defaultProvider="SqlProvider">
      <providers>
        <clear />
        <add connectionStringName="aspnetdbConnectionString" name="SqlProvider"
          type="System.Web.Security.SqlRoleProvider" />
      </providers>
</roleManager>

W tym momencie dodaliśmy do kolekcji menadżerów ról (Role managers) nowy provider - nie jest to jednak MembershipProvider lecz RoleProvider, a dokładniej dostarczony przez framework SqlRoleProvider. Provider ten jest przystosowany do działania na bazie danych o takiej strukturze, jak baza, którą stworzyliśmy w części pierwszej. Po konfiguracji providera przyszedł czas na dodanie przykładowego użytkownika oraz przypisanie mu jakiejś roli. Wybieramy opcję ASP.NET Configuration z menu Project, następnie na stronie na którą zostaniemy przeniesieni, przechodzimy na zakładkę Security

W kolejnym kroku dodajemy role - klikamy w Create or Manage roles, a w stronie, która się otworzy wpisujemy nazwę roli np. Developer. Postępując w podobny sposób dodajmy jeszcze role Admin. Następnie tworzymy użytkownika - klikamy w Create user, a następnie wypełniamy pola podobnie jak na załączonym poniżej screenie

Mając stworzonego przykładowego użytkownika możemy przystąpić do ograniczenia dostępu do niektórych funkcji naszego serwisu. W tym celu, po pierwsze modyfikujemy funkcję logowania.

 protected UserDTO ValidateCredentials(string name, string password, string customData, out string userData)
 {
     UserDTO user = null;
     userData = null;
     if (Membership.Providers[customData].ValidateUser(name, password))
     {
         userData = name;
         user = new UserDTO { DisplayName = name, Name = name, Email = name, Roles = Roles.GetRolesForUser(name) };
     }
     
     if (user != null) userData = name;
     
     return user;
 }

Jak widać, przy tworzeniu użytkownika dodatkowo pobieramy z bazy danych jego wszystkie role. Statyczna funkcja GetRolesForUser pobiera role przy pomocy domyślnego RoleProvidera. Dodajmy teraz do naszego DataAccesService-u dwie funkcje.

OnlyAdminCanDownloadThis
DevelopersCanDownloadThis

Dane pobierane przez pierwszą funkcję mogą być odczytane jedynie przez użytkowników, którzy są administratorami systemu. Natomiast dane z funkcji drugiej mogą być odczytane przez developerów (oczywiście admin również może pobrać te dane). Zastanówmy się teraz w jaki sposób sprawdzić czy dany użytkownik ma dostęp do danych. Możemy sprawdzać role ręcznie (niewygodne), użyć znanego z ASP.NET atrybutu PrincipalPermission (mało elastyczne) lub skorzystać z Microsoft Enterprise Library (całkiem dobra opcja). Security Block z biblioteki Microsoft Enterprise Library ma tę przewagę nad wcześniej wspomnianymi rozwiązaniami, że wprowadza on tzw. reguły(Rules). Dzięki nim możemy w łatwy sposób zdefiniować warunki jakie musi spełnić użytkownik aby zezwolić mu na dostęp w jakieś miejsce systemu. Skonfigurujmy zatem prostą regułę - regułą ta pozwoli na dostęp do danych jedynie tym użytkownikom, którzy mają prawo administratora. Klikamy PPM na plik Web.config i wybieramy z niego opcję Edit Enterprise Library V5 Configuration - opcja ta została dodana po instalacji biblioteki Microsoft Enterprise Library.

W oknie które się otworzy wybieramy Add Security Settings z menu Blocks.

W głównym oknie aplikacji pojawi się nowy element - Security Settings. Klikamy na znak + obok Authorization Providers, następnie z rozwiniętego menu przechodzimy na Add Authorization Providers i ostatecznie klikamy na Add Authorization Rule Provider

W ten sposób dodaliśmy domyślny Rule Provider, teraz możemy stworzyć reguły dostępu do naszej aplikacji. W tym celu musimy kliknąć w lewy dolny róg pola Authorization Rule Provider, a następnie z menu, które się pojawi wybrać Add Authorization Rule

W oknie aplikacji pojawi się nowy element - Authorization Rule, nadajmy mu nazwę DevelopersOnly, a następnie zdefiniujmy tzw. Rule expression. Rule expression jest warunek jaki musi zostać spełniony, aby użytkownik uzyskał dostęp do części aplikacji chronionej przez regułę DevelopersOnly. Wyrażenie to możemy wpisać ręcznie, lub poprzez prosty kreator - dostępny jest on pod przyciskiem .... Stwórzmy więc regułę, która pozwoli tylko użytkownikom typu Developer oraz oczywiście adminowi mieć dostęp do jakieś części aplikacji. Otwórzmy zatem Rule Expression Editor (dostępny on jest pod przyciskiem ...), kliknijmy na przycisk Role, wpiszmy Developer, następnie kliknijmy w przycisk OR, wpiszmy Admin. Możemy również wpisać następujące wyrażenie ręcznie

R:Developer OR R:Admin

Stworzyliśmy zatem regułę pozwalającą na dostęp użytkownikom typu Developer (R:Developer) oraz administratorom (R:Admin). Aby zatwierdzić zmiany wybieramy Save z menu File. W pliku Web.config pojawiły się teraz następujące linijki

<securityConfiguration>
    <authorizationProviders>
      <add type="Microsoft.Practices.EnterpriseLibrary.Security.AuthorizationRuleProvider, Microsoft.Practices.EnterpriseLibrary.Security, Version=5.0.414.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
        name="Authorization Rule Provider">
        <rules>
          <add expression="R:Developer OR R:Admin" name="DevelopersOnly" />
        </rules>
      </add>
    </authorizationProviders>
</securityConfiguration>

Do powyżej konfiguracji musimy jeszcze dorzucić wybór domyślnego providera - dodajmy zatem następujący wpis do linii

XHTML
defaultAuthorizationInstance="Authorization Rule Provider"

Wykorzystajmy teraz stworzoną właśnie regułę aby zabezpieczyć wspomnianą wcześniej funkcję DevelopersCanDownloadThis. Po pierwsze stwórzmy pomocniczą klasę pomocniczą SecurityHelper i dodajmy do niej metodę IsAuthorized, która wygląda w następujący sposób:

public static bool IsAuthorized(this IPrincipal principal, string rule)
{
    IAuthorizationProvider ruleProvider = EnterpriseLibraryContainer.Current.GetInstance<IAuthorizationProvider>();
    return ruleProvider.Authorize(principal, rule);
}

Następnie w funkcji DevelopersCanDownloadThis musimy sprawdzić czy użytkownik może wykorzystać tą funkcję - w tym celu wykorzystujemy funkcję IsAuthorized. Może wyglądać to w następujący sposób

public string DevelopersCanDownloadThis()
{
    if (ServiceContext.User.IsAuthorized("DevelopersOnly"))
        return "very secure data";
    throw new PermisionDeniedException("Brak dostępu");
}

Logując się na użytkownika, który posiada prawo/rolę Developer będziemy mogli pobrać dane wykorzystując funkcję DevelopersCanDownloadThis w przeciwnym razie do klienta zostanie rzucony wyjątek z odpowiednim komunikatem. Niestety Security Block nie został jeszcze przeniesiony na platformę Silverlightową, zatem przedstawionych powyżej sposobów sprawdzania praw dostępu(np. do jakiejś funkcjonalności) nie możemy zastosować po stronie klienta.

Silverlight - koncepcja logowania z użyciem MembershipProviders oraz WCF RIA cz.2

Sun, 25 Dec 2011 13:17:00 GMT

W poprzednim wpisie przedstawiłem w jaki sposób zaimplementować mechanizm logowania po stronie serwera. Wykorzystałem do tego celu WCF RIA oraz znane z ASP MembershipProvidery. Tym razem przedstawię jak wymusić logowanie po stronie klienta, oraz w jaki sposób można dynamicznie zmieniać providerów, którzy walidują usera. Poprzednim razem stworzyliśmy już szkielet aplikacji, zatem mamy projekt klienta oraz projekt serwera. Zacznijmy od "włączenia" FormsAuthentication po stronie klienta. W pliku App.xaml.cs , w konstruktorze dorzućmy następujące linijki

WebContext context = new WebContext {Authentication = new FormsAuthentication()};
ApplicationLifetimeObjects.Add(context);

Następnie zanim pokażemy treść naszej strony, musimy sprawdzić czy użytkownik jest zalogowany. Jeżeli nie, należy pokazać okno logowania. Możemy to zrobić w następujący sposób.

if (!WebContext.Current.User.IsAuthenticated)
{
    ModalDialogService.ShowDialog(_unityContainer.Resolve<IModalView<LoginViewModel>>(),
                                  val => { InitializeView();GetSecureData(); });
}
else
{
    InitializeView();
    GetSecureData();
}

WebContext jest to klasa generowana automatycznie przy buildowaniu solucji. Jej kod powinniśmy odnaleźć w katalogu Generated_Code po stronie klienta. Klasa ta posiada właściwość Current, która zwraca obecny context zarejestrowany w kolekcji ApplicationLifetimeObjects. Okno logowania zostało zaimplementowane jako ChildWindow. Jego kod może wyglądać w następujący sposób

<Grid x:Name="LayoutRoot" Margin="2">
        <Grid.RowDefinitions>
            <RowDefinition />
            <RowDefinition Height="Auto" />
        </Grid.RowDefinitions>
        <StackPanel VerticalAlignment="Center">
            <sdk:Label Content="Login"></sdk:Label>
            <TextBox Text="{Binding Login,NotifyOnValidationError=True,Mode=TwoWay}" >
               
            </TextBox>
            <sdk:Label Content="Hasło"</sdk:Label>
            <PasswordBox  Password="{Binding Password,NotifyOnValidationError=True,Mode=TwoWay}" >
            </PasswordBox>
        </StackPanel>
        <Button x:Name="CancelButton" Content="Cancel" Click="CancelButton_Click"  Width="75" Height="23" HorizontalAlignment="Right" Margin="0,12,0,0" Grid.Row="1" />
        <Button x:Name="OKButton" Content="OK" Command="{Binding OkCommand}" Width="75" Height="23" HorizontalAlignment="Right" Margin="0,12,79,0" Grid.Row="1" />
</Grid>

Kontrolka logowania jest bardzo prosta, składa się ona z dwóch labelek, textboxa oraz passwordBoxa. Powyższy kod powinien wygenerować mniej więcej takie oto okno

Mechanizm wywoływania operacji logowania znajduje się natomiast w ViewModelu kontrolki logowania. Po naciśnięciu przycisku OK, dzięki zastosowaniu DelegateCommand uruchamiany następującą funkcję

private void OkCommandExecuted()
{
    if (Validate())
    {
        PerfomrLoginOperation();
    }
}

W funkcji tej najpierw sprawdzamy, czy użytkownik podał dane do logowania, a następnie wywołujemy kolejną funkcję PerfomrLoginOperation. Przedstawia się w następujący sposób

private void PerfomrLoginOperation()
{      
    WebContext.Current.Authentication.Login(new LoginParameters(Login, Password, false,string.Empty, CompleteLoginOperation, Guid);
}

Widzimy zatem, że wywołujemy funkcję logowania z serwisu WCF, w parametrach natomiast podajemy login oraz hasło przechwycone z okna. Dodatkowo w parametrze podajemy delegata do funkcji, która zostanie wykonana po zakończeniu operacji logowania.

private void CompleteLoginOperation(LoginOperation loginOperation)
{
    if (loginOperation.Error == null)
        OnOperationCompleted();
    else
    {
        if (loginOperation.Error is FormsAuthenticationLogonException)
            MessageBoxService.ShowMessageBox("Nieprawidłowy login lub hasło", MessageBoxButton.OK);
        else
            MessageBoxService.ShowMessageBox("Wystąpił problem podczas operacji logowania",
                                             MessageBoxButton.OK);
    }
}

Jeżeli odpowiedź z serwisu WCF zawiera błędy to wiemy, że operacja logowania się nie powiodła. Wyświetlamy zatem stosowny komunikat. Jeżeli natomiast wszystko jest OK, pole loginOperation.Error będzie miało wartość null. Możemy wtedy pokazać naszą wiadomość dostępną jedynie dla zalogowanych użytkowników.

Mamy zatem ochronę przeciwko nieautoryzowanemu dostępowi do klienta. Jednak co w przypadku gdy nasz klient musi w calach np. zassania danych pobrać je przy wykorzystaniu jakiegoś WebServicu. Na ogól wystawiany jest wtedy drugi WebService do pobierania danych z jakiejś bazy. Do takiego WebServicu w teorii może dostać się każdy - my natomiast chcemy żeby dane można było pobierać jedynie po zalogowaniu się do aplikacji. Na szczęście nasz dodatkowy WebServise można w prosty sposób zabezpieczyć przed dostępem osób trzecich. Stwórzmy zatem sobie nowy WebService służący do pobierania danych. Do projektu Webowego dodajmy nową klasę typu Domain Service oraz dopiszmy do nie jedną metodę symulującą pobieranie danych.

[EnableClientAccess()]
public class DataAccesService : DomainService
{
    public string GetSecureData()
    {
        return "very secure data";
    }
}

Do takiego Servicu może dostać się każdy. Jeżeli natomiast naszą klasę udekorujemy atrybutem [RequiresAuthentication] tylko użytkownicy, którzy pomyślnie przeszli autentykację przez nasz CustomAuthenticationService będą w stanie pobrać dane. W przeciwnym wypadku zostanie rzucony wyjątek.

Zastanówmy się teraz w jaki sposób można byłoby logować się do naszej aplikacji np. przy pomocy konta Google. Zacznijmy od tego, że musimy stworzyć własny MembershipProvider. W tym celu dodajmy do projektu Webowego nową klasę GoogleMembershipProvider, która będzie rozszerzać klasę MembershipProvider. Klasa MembershipProvider jest klasą abstrakcyjną zatem musimy zoverridować wszystkie jej funkcje (nie musimy wrzucać tam logiki, narazie po prostu wpiszmy tam cokolwiek aby przeszła kompilacja). Mając stworzony szkielet providera musimy go dorzucić do listy wszystkich providerów (tak jak to zrobiliśmy z SqlMembershipProvider-em). Modyfikujemy zatem sekcję podsekcję providers z sekcji membership na następującą.

<membership
            defaultProvider="PremiumHandsMembershipProvider"
            userIsOnlineTimeWindow="20">
      <providers>
        <clear/>
        <add name="PremiumHandsMembershipProvider"
             connectionStringName="aspnetdbConnectionString"
            type="System.Web.Security.SqlMembershipProvider"
            enablePasswordRetrieval="false"
            enablePasswordReset="false"
            requiresQuestionAndAnswer="true"
            passwordFormat="Hashed"
            applicationName="/" />
        <add name="GoogleMembershipProvider"
             type="MainModule.Web.Providers.GoogleMembershipProvider"
             enablePasswordRetrieval="false"
            enablePasswordReset="false"
            requiresQuestionAndAnswer="true"
            passwordFormat="Hashed"
            applicationName="/"
             />
      </providers>
</membership>

Mając w kolekcji wszystkie nasze providery pozostaje nam się zastanowić, w jaki sposób raz używać GoogleMembershpProvidera, a innym razem SqlMembershipProvidera. Ja zrobiłem to w następujący sposób. Najpierw utworzyłem enuma, w którym przechowuje "nazwy" moich providerów

public enum AccountType
{
    PremiumHandsMembershipProvider,
    GoogleMembershipProvider,
    Facebook
}

Następnie wykorzystałem parametr customData interfejsu IAuthentication. Po stronie klienta w funkcji logowania po prostu przesyłam typ konta do którego się loguję. Wygląda to w ten sposób:

 WebContext.Current.Authentication.Login(new LoginParameters(Login, Password, false,AccountType.GoogleMembershipProvider.ToString("g")), CompleteLoginOperation, Guid);

Następnie po stronie serwera wybieram tego providera, przez którego loguje się użytkownik.

protected UserDTO ValidateCredentials(string name, string password, string customData, out string userData)
{
    UserDTO user = null;
    userData = null;
    if (Membership.Providers[customData].ValidateUser(name, password))
    //if (Membership.Provider.ValidateUser(name, password))
    {
        userData = name;
        user = new UserDTO { DisplayName = name, Name = name, Email = name};
    }
    if (user != null) userData = name;
    return user;
}

Zauważmy, że linijka

if (Membership.Provider.ValidateUser(name, password))

została zastąpiona przez

if (Membership.Providers[customData].ValidateUser(name, password))

zatem teraz mamy wpływ na to, którego MembershipProvidera użyjemy. Jeżeli chodzi o samo sprawdzenie czy dany użytkownik podał poprawne dane do konta google, to sprawa jest trochę kłopotliwa(tak mi się wydaje :D). Nie udało mi się użyć biblioteki dotNetOpenAuth, gdyż z tego co widzę logowanie poprzez tą bibliotekę wymaga przekierowania na stronę Googla. Niestety taka operacja nie jest dozwolona w Silverlighcie (Silverlight nie wspiera cross-domain policy). Ponadto wykorzystanie tej biblioteki po stronie serwera również nie przyniosło oczekiwanych rezultatów. Ostatecznie zatem skorzystałem z opisu znajdującego się na stronie Googla. Czyli po prostu spreparowałem odpowiedni HTTPS Post Request. Funkcja ValidateUser z GoogleMembershipProvidera wygląda zatem następująco

public override bool ValidateUser(string username, string password)
{
    string requestUrl = string.Format("https://www.google.com/accounts/ClientLogin?service=mail&Email={0}&Passwd={1}", username, password);
    byte[] data = Encoding.ASCII.GetBytes(requestUrl);
    HttpWebRequest req = (HttpWebRequest)WebRequest.Create(requestUrl);
    req.ProtocolVersion = HttpVersion.Version10;
    req.ContentLength = data.Length;
    req.ContentType = "application/x-www-form-urlencoded";
    req.Method = "POST";
    var stream = req.GetRequestStream();
    stream.Write(data,0,data.Length);
    stream.Close();
    
    try
    {
        HttpWebResponse response = (HttpWebResponse)req.GetResponse();
        return response.StatusCode == HttpStatusCode.OK;
    }
    catch (WebException e)
    {
        return false;
    }
}

Ciężko mi jednak stwierdzić czy takie logowanie jest bezpieczne. Co prawda nie udało mi się wyłapać nic konkretnego poprzez Wiresharka lub Fiddlera, jednakże ekspertem od zabezpieczeń niestety nie jestem. W następnym wpisie postaram się króciutko przedstawić bibliotekę Microsoft Enterprise Library, a właściwie jeden z jej bloków - Security Block. Wykorzystam go do zezwalania użytkownikom do dostępu do funkcji serwisu, w zależności od ich roli w systemie.

Silverlight - koncepcja logowania z użyciem MembershipProviders oraz WCF RIA cz.1

Sat, 24 Dec 2011 13:12:00 GMT

W dzisiejszym wpisie postaram się przedstawić moją koncepcję logowania do aplikacji Silverlightowej z wykorzystaniem MembershipProviders oraz własnego AuthenticationService. Zacznijmy od stworzenia bazy danych, w której będziemy przetrzymywać informacje o użytkownikach - hasła, role itp. Bazę danych stworzymy przy użyciu narzędzia aspnet_regsql.exe, które to wygeneruje schemat bazy danych dostosowany do możliwości SqlMembershipProvider-a. aspnet_regsq.exe znajduje się w katalogu C:WINDOWS\Microsoft.NET\Framework\wersjaFrameworka\aspnet_regsql.exe. Czyli w moim przypadku jest to C:WINDOWS\Microsoft.NET\Frameworkv\4.0.30319\aspnet_regsql.exe.

Klikając podwójnie na ikonę aplikacji pojawia nam się następujące okno

Klikamy w przycisk Dalej. W kolejnym oknie mamy do wyboru dwie opcje

Configure SQL Server for application services
Remove application services from an existing database

Pierwsza opcja odpowiedzialna jest za stworzenie struktury danych do naszego sytemu logowania, natomiast druga usuwa z bazy danych tabele służące do logowania itp. Wybieramy opcję bramkę nr 1. W kolejnym oknie musimy podać connection string do naszego serwera bazy danych oraz login i hasło. W moim przypadku wygląda to w następujący sposób:

Jeżeli wszystko pójdzie OK pokaże się nam następujące okno, w którym to możemy zobaczyć, że została stworzona baz danych aspnetdb

Ostatecznie klikamy na przycisk Next, a następnie w Finish aby dokończyć działanie kreatora

Mając gotową bazę danych możemy przystąpić do właściwego kodowania. Zacznijmy od stworzenia nowego projektu typu Silverlight Application

po kliknięciu przycisku OK włączamy WCF RIA Service

Mając stworzony szkielet aplikacji możemy zabrać się za napisanie własnego AuthenticationService. Do projektu webowego (nazwaprojektu.Web) dodajmy nowy element typu Domain Service. PPM na projekt, następnie Add new item, w oknie które się otworzy wybieramy Domain Service. Nadajemu mu nazwę CustomAuthenticationService.cs

Nasza właśnie dodana klasa powinna wyglądać mniej więcej w taki sposób

namespace MainModule.Web
{
    using System;
    using System.Collections.Generic;
    using System.ComponentModel;
    using System.ComponentModel.DataAnnotations;
    using System.Linq;
    using System.ServiceModel.DomainServices.Hosting;
    using System.ServiceModel.DomainServices.Server;

    // TODO: Create methods containing your application logic.
    [EnableClientAccess()]
    public class CustomAuthenticationService: DomainService
    {
    }
}

W następnym kroku zaimplementujmy w klasie CustomAuthenticationService interfejs IAuthentication where T: IUser. Interfejs ten wygląda w następujący sposób:

public interface IAuthentication<T> where T: IUser
{
    T GetUser();
    T Login(string userName, string password, bool isPersistent, string customData);
    T Logout();
    void UpdateUser(UserDTO user);
}

Widzimy zatem, że zanim go zaimplementujemy musimy posiadać obiekt implementujący inny interfejs - IUser. Przystąpmy zatem do stworzenia naszej klasy modelującej użytkownika - nazwijmy ją UserDTO. Stwórzmy nowy projekt typu Class library. W projekcie tym stwórzmy klasę UserDTO, która będzie dziedziczyła po klasie UserBase znajdującej się w przestrzeni nazw System.ServiceModel.DomainServices.Server.ApplicationServices

public class UserDTO : UserBase
{
    public string Email { get; set; }
    public string DisplayName { get; set; }
}

Mając gotową klasę reprezentującą użytkownika zaimplementujmy w końcu w klasie CustomAuthenticationService interfejs IAuthentication. Po implementacji interfejsu nasz serwis wygląda w następujący sposób:

[EnableClientAccess]
public class CustomAuthenticationService: DomainService, IAuthentication
{
    public UserDTO GetUser()
    {
        throw new NotImplementedException();
    }
    
    public UserDTO Login(string userName, string password, bool isPersistent, string customData)
    {
        throw new NotImplementedException();
    }
    
    public UserDTO Logout()
    {
        throw new NotImplementedException();
    }
    
    public void UpdateUser(UserDTO user)
    {
        throw new NotImplementedException();
    }
}

Pozostaje nam "tylko" zaimplementować odpowiednie metody. Funkcja która nas najbardziej interesuje to oczywiście funkcja logowania. Przy jej implementacji posłuży się mechanizmem znanym z ASP mianowicie z MembershipProviders. Klasa MembershipProvider jest to abstrakcyjna klasa posiadająca szereg funkcji mającej na celu walidowanie poprawnego użytkownika, rejestrację itp. Stwórzmy zatem własną klasę providera dziedziczącą po klasie MembershipProvicer. .NET dostarcza nam domyślny provider, którym jest SqlMembershipProvider, jest on napisany w taki sposób, aby mógł porozumiewać się z bazą, którą stworzyliśmy na początku. Aby wykorzystać wspomnianego wcześniej providera musimy odpowiednio zmodyfikować plik Web.config. Po pierwsze dodajemy do niego ConnectionString do naszej bazy danych, w moim przypadku będzie to wyglądało w następujący sposób

<connectionStrings>
    <add name="aspnetdbConnectionString" connectionString="Data Source=TOMEKKOMPUTERSQLEXPRESSRC2;Initial Catalog=aspnetdb;Integrated Security=True"
      providerName="System.Data.SqlClient" />
</connectionStrings>

Następnie musimy "pokazać" naszej aplikacji, że będziemy używać FormsAuthentication oraz MembershipProvider-ow. Dorzućmy zatem do config następujące rzeczy:(w sekcji system.web)

<authentication mode="Forms" />

następnie dorzucamy do kolekcji providerów SqlMembershipProvider

<membership
            defaultProvider="PremiumHandsMembershipProvider"
            userIsOnlineTimeWindow="20">
      <providers>
        <clear/>
        <add name="PremiumHandsMembershipProvider"
             connectionStringName="aspnetdbConnectionString"
            type="System.Web.Security.SqlMembershipProvider"
            enablePasswordRetrieval="false"
            enablePasswordReset="false"
            requiresQuestionAndAnswer="true"
            passwordFormat="Hashed"
            applicationName="/" />
      </providers>
</membership>

We wpisach tych dorzuciliśmy możliwość autentykacji poprzez providery, ustawiliśmy SqlMembershipProvider jako domyślny provider, oraz dorzuciliśmy go do listy wszystkich providerów. W celu sprawdzenia czy nasza konfiguracja jest poprawna możemy posłużyć się mechanizmem dostarczonym nam przez Visual Studio. Klikamy Projekt, a następnie ASP.NET Configuration

Zostaniemy przeniesieni do domyślnej przeglądarki internetowej, a naszym oczom ukaże się następująca strona.

Z poziomu tej stronki możemy dodawać użytkowników, przydzielać im role itp, dzięki czemu możemy szybko sprawdzić czy podstawowe funkcje naszego providera działają, oraz czy nasza konfiguracja została przeprowadzona prawidłowo. Wracając natomiast do naszego systemu logowania, pozostało nam jedynie odpowiednio zmodyfikować funkcję odpowiedzialną za logowanie. Robimy to w następujący sposób:

protected  UserDTO ValidateCredentials(string name, string password, string customData, out string userData)
{
    UserDTO user = null;
    userData = null;
    
    if (Membership.Provider.ValidateUser(name, password))
    {
        userData = name;
        user =  new UserDTO {DisplayName = name,Name = name,Email = name};
    }
    
    if (user != null) userData = name;
    
    return user;
}

public UserDTO Login(string userName, string password, bool isPersistent, string customData)
{
    string userData;
    UserDTO user = ValidateCredentials(userName, password, customData, out userData);
    
    if (user != null)
    {
        FormsAuthenticationTicket ticket = new FormsAuthenticationTicket(/* version */ 1, userName,
                                                   DateTime.Now, DateTime.Now.AddMinutes(30),
                                                   isPersistent,
                                                   userData,
                                                   FormsAuthentication.FormsCookiePath);
                                                   
        string encryptedTicket = FormsAuthentication.Encrypt(ticket);
        HttpCookie authCookie = new HttpCookie(FormsAuthentication.FormsCookieName, encryptedTicket);
        HttpContextBase httpContext = (HttpContextBase)ServiceContext.GetService(typeof(HttpContextBase));
        httpContext.Response.Cookies.Add(authCookie);
    }
    else
    {
        HttpContextBase httpContext = (HttpContextBase)ServiceContext.GetService(typeof(HttpContextBase));
        httpContext.AddError(new FormsAuthenticationLogonException("Nieprawidłowy login lub hasło"));
    }
    return user;
}

W funkcji ValidateCredentials odbywa się sprawdzanie czy użytkownik podał właściwe hasło oraz login. Do walidacji wykorzystujemy dodany wcześniej SqlMembershipProvider - właściwość Membership.Provider zawsze zwraca obiekt domyślnie zdefiniowanego providera. W przypadku gdy walidacja się powiedzie tworzymy obiekt użytkownika, a następnie tworzymy i szyfrujemy FormsAuthenticationTicket oraz tworzymy ciasteczko (cookie), które przesyłamy w responsie wysyłanym przez serwer do klienta. Mechanizm logowania jest już prawie gotowy. Musimy jedynie zaimplementować jeszcze pozostałe funkcje interfejsu IAuthentication. Nie ma raczej w nich nic trudnego

public UserDTO Logout()
{
    FormsAuthentication.SignOut();
    return null;
}

public UserDTO GetUser()
{
    IPrincipal currentUser = ServiceContext.User;
    
    if ((currentUser != null) && currentUser.Identity.IsAuthenticated)
    {
        FormsIdentity userIdentity = currentUser.Identity as FormsIdentity;
        if (userIdentity != null)
        {
            FormsAuthenticationTicket ticket = userIdentity.Ticket;
            if (ticket != null && !ticket.Expired)
            {
                 return new UserDTO { DisplayName = currentUser.Identity.Name, Name = currentUser.Identity.Name };
            }
        }
    }
    
    return null;
}

Funkcja Logout po prostu wywołuje funkcję SingOut z klasy FormsAuthentication. Natomiast funkcja GetUser zwraca zalogowanego użytkownika. W funkcji tej najpierw sprawdzamy czy użytkownik jest zalogowany (do tego celu używamy zmiennej IsAuthenticated), a następnie sprawdzamy czy przypadkiem jego sesja nie wygasła. W przypadku gdy wszystko jest OK zwracamy obiekt typu UserDTO, w przeciwnym razie zwracamy null.

Podsumowując, udało nam się stworzyć mechanizm logowania. Jak na razie gotowa jest strona serwera. W następnym wpisie pokażę w jaki sposób należy wywołać logowanie od strony klienta. Przedstawię również pomysł w jaki sposób zmieniać providerów przez które użytkownik ma się logować. Może to być przydatne jeżeli chcielibyśmy logować się np. poprzez inne serwisy jak Google, Facebook itp.

Coded UI Test - tworzenie testów UI przy pomocy Visual Studio Ultimate

Sun, 04 Dec 2011 00:54:00 GMT

Poszukując sposobów automatycznego testowania aplikacji natrafiłem na ciekawą funkcjonalność Visual Studio 2010 Ultimate. Mianowicie w tej wersji naszego ulubionego IDE znalazło się miejsce na nowy typ testów - Coded UI Test. Coded UI Test jest to automatyczny test UI, który tworzymy poprzez nagrywanie akcji jakie wykonujemy w naszej aplikacji. Nie musimy pisać ani jednej linijki kodu żeby przetestować jakąś funkcjonalność naszego programu. Jedyne co musimy zrobić jest to przejście przez wszystkie niezbędne kroki w naszej aplikacji, tak aby zweryfikować naszą funkcjonalność. W celu stworzenia Coded UI Test musimy po pierwsze zaopatrzyć się w wersję Ultimate Visual Studio 2010. Z tego co wiem, niestety niższe wersje nie mają funkcjonalności automatycznego testowania. Następnie musimy stworzyć nowy Test Project. W tym celu z menu File wybieramy New a następnie Project. W oknie, które się pokaże, w drzewie po lewej stronie wybieramy Test, a następnie w prawej części okna Test Project

Mając stworzony projekt testowy dodajemy do niego nowy Coded UI Test. W Solution Explore-rze klikamy PPM na projekt testowy, a następnie z menu contextowego wybieramy Coded UI Test.

W oknie, które się pojawi wybieramy Record actions, edit UI map or add assertion lub gdy mamy już gotowe testy możemy wybrać opcję nr 2. Po wybraniu pierwszej opcji okno Visual Studio zostanie zminimalizowane, a w prawym dolnym rogu pulpitu ukaże się następujące okienko.

Służy ono do nagrywania testu. Naciskając czerwony przycisk rozpoczynamy proces nagrywania testu. W moim przypadku będę testować aplikację, którą testowałem również w poprzednim poście. Wykonuje zatem czynności mające na celu sprawdzenie funkcjonalności dodawania liczb. Po kliknięciu na textbox-a pojawia się nad nim dymek,że dana akcja jest nagrywana.

Po "wyklikaniu" całej ścieżki mającej sprawdzić funkcjonalność klikamy przycisk Generate code (ten najbardziej z prawej strony). Następnie w okienku, które się pojawi

podajemy nazwę naszego testu. Po kliknięciu OK, Visual Studio wygeneruje nam kod odpowiedzialny za nasz test.

W celu odpalenia naszego testu z menu Test wybieramy Run, a następnie Tests in Current Context. Visual Studio przejdzie teraz wszystkie kroki, które zostały nagrane w teście. Ok, niby wszystko ładnie pięknie, ale tak naprawdę nic nie sprawdziliśmy. Jedyne co zrobiliśmy to wykonaliśmy pewne operacje na naszej aplikacji, jednakże nie zweryfikowaliśmy danych otrzymanych w wyniku operacji dodaj. W celu dodania warunku sprawdzającego do naszego testu, musimy dodać tzw. asercję. Aby to zrobić klikamy PPM na wolne pole edytora, pod funkcją this.UIMap.RecordedMethod1() (ta funkcja została wygenerowana podczas nagrywania testu). Następnie z menu contextowego wybieramy

Otwiera nam się znane już wcześniej okienko nagrywania testu. Jednakże tym razem naciśnijmy przycisk celownika i przeciągnijmy go na textbox-a, w którym ma pojawić się wynik dodawania

Nasz textbox zostanie obramowany, natomiast w prawym dolnym rogu pulpitu pojawi się nowe okno pokazujące propertisy naszego przycisku. Wybierzmy właściwość Text ,a następnie naciśnijmy przycisk Add Assertion

W oknie, które się pojawi możemy wybrać warunek, który musi spełnić dana właściwość (w tym przypadku Text), aby test przeszedł. Ustawmy tam wartość np. 3. Następnie klikamy OK oraz nadajemy nazwę naszej assercji. Po wykonaniu tych czynności w kodzie naszego pojawi się dodatkowa linijka

Teraz za każdym razem gdy odpalimy test na samym jego końcu będzie sprawdzana nasza assercja. W przypadku gdy wartość właściwości Text nie będzie równa 3 nasz test nie przejdzie.

UI Automation - czyli testy automatyczne w .NET

Sat, 03 Dec 2011 15:10:00 GMT

Biblioteka Microsoft UI Automation ujrzała światło dzienne wraz z premierą .NET 3.0 - jednakże pozostała ona w cieniu swoich większych braci WPF oraz WPF, które również zostały wprowadzone do Frameworka 3.0. Microsoft UI automation zapewnia nam dostęp do wszystkich elementów drzewa wizualnego aplikacji. Dzięki czemu mamy możliwość:

Znajdowania wybranych przez nas kontrolek
Interakcji z kontrolkami - wpisywanie tekstów do TextBox-ów, klikanie w przyciski itp
Wczytywania wartości już wprowadzonych do kontrolek

Każda kontrolka znajdująca się na widoku jest traktowana przez UI Automation jako AutomationElement. Rootem naszego drzewa wizualnego pulpit, dostęp do niego uzyskujemy poprzez statyczną właściwość

AutomationElement.RootElement

Mając dostęp do roota możemy następnie poruszać się po drzewie tak aby znaleźć interesujące nas elementy. Załóżmy, że napisaliśmy prostą aplikację WPF-ową, która wykonuje podstawowe obliczenia matematyczne (pomysł na prostą aplikację do testowania zaczerpnięty z tej strony - kod jednak pisałem po swojemu :D). Wizualnie aplikacja ta przedstawia się w następujący sposób:

<Window x:Class="UIAutomation.Views.MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        Height="350" Width="525" Title="{Binding Title}">
    <Grid x:Name="SomeUniqueName1">
        <Grid.RowDefinitions>
            <RowDefinition></RowDefinition>
            <RowDefinition></RowDefinition>
            <RowDefinition></RowDefinition>
            <RowDefinition></RowDefinition>
        </Grid.RowDefinitions>
        <Grid.ColumnDefinitions>
            <ColumnDefinition></ColumnDefinition>
            <ColumnDefinition></ColumnDefinition>
            <ColumnDefinition></ColumnDefinition>
            <ColumnDefinition></ColumnDefinition>
        </Grid.ColumnDefinitions>
        <Label Content="Pierwsza liczba:" HorizontalAlignment="Center" VerticalAlignment="Center" Grid.ColumnSpan="2"></Label>
        <Label Content="Druga liczba:" HorizontalAlignment="Center" VerticalAlignment="Center" Grid.Row="1" Grid.ColumnSpan="2"></Label>
        <Label Content="Wynik:" HorizontalAlignment="Center" VerticalAlignment="Center" Grid.Row="2"  Grid.ColumnSpan="2"></Label>
        <Button Name="btnAdd"  Grid.Column="0" Grid.Row="3" Content="Dodaj" Command="{Binding AddCommand}" />
        <Button Name="btnSubtract" Grid.Column="1" Grid.Row="3"  Content="Odejmij" Command="{Binding SubstractCommand}" />
        <Button Name="btnMultiply" Grid.Column="2" Grid.Row="3"  Content="PomnÃ³Å¼" Command="{Binding MultiplyCommand}" />
        <Button Name="btnDivide" Grid.Column="3" Grid.Row="3"  Content="Podziel" Command="{Binding DivideCommand}" />
        <TextBox Name="txtFirstNumber"  Grid.Column="2"  VerticalAlignment="Center" Grid.ColumnSpan="2" Text="{Binding FirstNumber,Mode=TwoWay}"></TextBox>
        <TextBox Name="txtSecondNumber" Grid.Column="2" Grid.Row="1" HorizontalAlignment="Stretch" VerticalAlignment="Center" Text="{Binding SecondNumber,Mode=TwoWay}" Grid.ColumnSpan="2"></TextBox>
        <TextBox Name="txtResult"  Grid.Column="2" Grid.Row="2" HorizontalAlignment="Stretch" VerticalAlignment="Center" Text="{Binding Result,Mode=TwoWay}" Grid.ColumnSpan="2"></TextBox>
    </Grid>
</Window>

W celu poruszania się po drzewie wizualnym możemy skorzystać z dwóch metod

public AutomationElement FindFirst(TreeScope scope, Condition condition);
public AutomationElementCollection FindAll(TreeScope scope, Condition condition);

pierwsza z nich zwraca nam konkretny element, który spełnia podane przez nas kryterium. Pierwszy parametr funkcji TreeScope scope określa nam sposób przeszukiwania drzewa wizualnego. Dostępne opcje to:

Element - wyszukiwanie odbywa się tylko na danym elemencie
Children - wyszukiwanie odbywa się na wszystkich dzieciach danego elementu - nie zagłębiamy się rekurencyjnie,sprawdzamy tylko jeden poziom w dół od danego elementu
Descendants - wyszukiwanie odbywa się na wszystkich potomkach - przeszukiwanie rekurencyjne w dół
Subtree - wyszukiwanie odbywa się na wszystkich potomkach, oraz elemencie od którego zaczynamy
Ancestors - wyszukiwanie odbywa się na wszystkich rodzicach - rekurencyjnie w górę drzewa

Drugim z parametrów jakie musimy podać jest to UIAutomation.Condition. Parametr ten określa jaki warunek musi spełnić dany element aby został uwzględniony w wyniku wyszukiwania. Sama klasa Condition jest klasą abstrakcyjną, z której dziedziczą wyspecjalizowane klasy. Do określenia warunków najczęściej będziemy korzystać z potomka klasy Condition, mianowicie z

PropertyCondition

określa ona jaka właściwość kontrolki/aplikacji będzie uwzględniana przy wyszukiwaniu wyniku.

Pierwszym krokiem przy testowaniu aplikacji będzie oczywiście znalezienie głównego okna programu. Mając w solucji stworzony projekt z aplikacją WPF-ową, dodajmy drugi projekt - tym razem będzie to projekt typu ConsoleApplication. Następnie musimy dodać referencję do odpowiednich ddl-ek. Potrzebujemy następujących bibliotek:

UIAutomation.dll
UIAutomationClient.dll
UIAutomationType.dll

Następnie w naszym projekcie konsolowym w metodzie main odpalamy aplikację, którą chcemy testować. W moim przypadku wygląda to w następujący sposób:

Console.WriteLine("Odpalam aplikacje");
Process p = Process.Start("..\..\..\UIAutomation\bin\Debug\UIAutomation.exe");

Następnie musimy dostać się do głównego okna testowanej aplikacji. Możemy to zrobić używając funkcji FindFirst:

AutomationElement mainForm =  AutomationElement.RootElement.FindFirst(TreeScope.Children,new PropertyCondition(AutomationElement.ProcessIdProperty, p.Id));

lub możemy uzyskać dostęp do okna przy pomocy funkcji

AutomationElement mainForm = AutomationElement.FromHandle(p.MainWindowHandle);

W pierwszym przypadku wykorzystując funkcję FindFirst przeszukujemy wszystkie dzieci (TreeScope.Children) roota (czyli pulpitu). Jako warunek wyszukiwania podaliśmy obiekt klasy PropertyCondition. Jako właściwość do porównywania podaliśmy id processu (AutomationElement.ProcessIdProperty). W drugim przypadku po prostu uzyskujemy dostęp do okna dzięki znajomości jego uchwytu (właściwość MainWindowHandle z klasy Process). Według mnie lepiej skorzystać z funkcji pierwszej, zwłaszcza gdy odpalamy aplikację, która się długo uruchamia. W pierwszym przypadku wystarczy zrobić odpowiednią funkcję oczekującą na odpalanie (gdyż funkcja zwróci nam null gdy okna jeszcze nie będzie), natomiast druga opcja rzuci nam wyjątek. Oczekiwania na załadowanie okna może wyglądać w następujący sposób

AutomationElement mainForm;
while ((mainForm = AutomationElement.RootElement.FindFirst(TreeScope.Children,new PropertyCondition(AutomationElement.ProcessIdProperty,p.Id)))==null)
{
    Thread.Sleep(100);
}

Mając dostęp do głównego okna możemy przeprowadzić testy - przetestujemy czy po wpisaniu danych do tekstboksów i przeprowadzeniu odpowiednich akcji (dodawanie,usuwanie,odejmowanie,dzielenie) w polu wynik pojawi się odpowiednia wartość. Zacznijmy od zlokalizowania textboxów. Posłużmy się tutaj przedstawioną wcześniej funkcją FindFirst.

var firstTextbox = mainForm.FindFirst(TreeScope.Children, new PropertyCondition(AutomationElement.AutomationIdProperty, "txtFirstNumber"));

Wyszukiwanie odbywa się po właściwości AutomationElement.AutomationIdProperty - właściwość ta jest zawsze taka sama jak nazwa kontrolki - chyba, że ktoś ją zmieni przy pomocy AttachedProperty AutomationProperties.AutomationId. Odpalając powyższy kod okazuje się, że nasza zmienna firstTextbox jest nullem - czyli framework nie był w stanie znaleźć naszego textboxa. Dlaczego tak się stało? Odpowiedzi może nam dostarczyć aplikacja Snoop, dzięki której możemy podejrzeć drzewo wizualne naszego programu.

Na powyższym screenie widzimy, że szukany textbox nie jest bezpośrednim dzieckiem MainWindow, jest natomiast dzieckiem grida (tego można było się spodziewać zwłaszcza, że umieściliśmy textbox w gridzie). Zauważmy jednak, że MainWindow nie jest bezpośrednim rodzicem grida - znajduje się on dopiero na poziomie 4 w drzewie. Z racji dużego skomplikowania drzewa wizualnego aplikacji według mnie bezpiecznie jest używać funkcji Find z parametrem TreeScope.Descendants. Unikniemy dzięki temu przykrych niespodzianek z nieodnalezionymi kontrolkami. Nasza funkcja zatem powinna wyglądać w następujący sposób.

var firstTextbox = mainForm.FindFirst(TreeScope.Descendants, new PropertyCondition(AutomationElement.AutomationIdProperty, "txtFirstNumber"));

W analogiczny sposób znajdujemy pozostałe przyciski na naszej formie, a następnie postarajmy się wprowadzić do nich jakiś text. W celu interakcji z kontrolkami wykorzystamy tzw. Patterns. Patterns definiują określone funkcjonalności, które wspiera nasza kontrolka. Do najczęściej używanych patterns należą:

SelectionPattern - używany do manipulacjami kontrolkami wspierającymi zaznaczanie np. ListBox-ami
TextPattern - używany do manipulacjami kontrolkami wspierającymi edycję
ValuePattern - używany do pobierania i ustawiania wartości kontrolek nie wspierających wielokrotnych wartości
InvokePattern - używane do kontrolek wspierających wywołania - np. przyciski (wywołanie przyciśnięcia)
ScrollPattern - używane do kontrolek posiadających ScrolBar-y
RangeValuePattern - używany do kontrolek mogących posiadać jakiś zakres wartości np. ComboBox

Zatem w celu ustawienia wartości w textbox-ie posłużymy się następującym kodem

var pattern = txtFirstNumber.GetCurrentPattern(ValuePattern.Pattern) as ValuePattern;
pattern.SetValue("50");

W analogiczny sposób ustawiamy zawartość drugiego textbox-a

var pattern = txtSecondNumber.GetCurrentPattern(ValuePattern.Pattern) as ValuePattern;
pattern.SetValue("50");

Mając wprowadzone dane do textbox-ów wypadałoby teraz przeprowadzić obliczenia. Zatem musimy w jakiś sposób aby "nacisnąć" jeden z naszych czterech przycisków. Znajdźmy zatem nasze przyciski:

var btnAdd = mainForm.FindFirst(TreeScope.Descendants, new PropertyCondition(AutomationElement.AutomationIdProperty, "btnAdd"));
var btnSubtract = mainForm.FindFirst(TreeScope.Descendants, new PropertyCondition(AutomationElement.AutomationIdProperty, "btnSubtract"));
var btnMultiply = mainForm.FindFirst(TreeScope.Descendants, new PropertyCondition(AutomationElement.AutomationIdProperty, "btnMultiply"));
var btnDivide = mainForm.FindFirst(TreeScope.Descendants, new PropertyCondition(AutomationElement.AutomationIdProperty, "btnDivide"));

Następnie wykorzystując wspomniany wcześniej InvokePattern naciśnijmy przycisk Dodaj.

InvokePattern ipClickButton1 = (InvokePattern)btnAdd.GetCurrentPattern(InvokePattern.Pattern);
ipClickButton1.Invoke();

Ostatnim krokiem będzie zweryfikowanie czy wartość w textbox-ie txtResult jest zgodna z oczekiwaniami. W celu wyciągnięcia wartości z txtResult po raz kolejny posłużę się ValuePattern

var value = (txtResult.GetCurrentPattern(ValuePattern.Pattern) as ValuePattern).Current.Value

Wynik otrzymany w textbox-ie porównujemy z oczekiwanym rezultatem

Console.Write("Dodawanie test OK ? , {0}",value == "100");

Na koniec najlepiej wrzucić nasz test w jakąś pętle, losowo generować wartości oraz porównywać je z wartościami oczekiwanymi. Dobrym pomysłem jest również stworzenie sobie jakiejś klasy pomocniczej, w której zostałyby umieszczone funkcje do wypełniania textbox-ow, klikania w buttony itp - gdyż jak widać dużo kodu jest powtarzalna. Ostatecznie aplikacja testowa może wyglądać w następujący sposób:

class Program
{
    static void Main(string[] args)
    {
        Random rand = new Random();
        try
        {
            Console.WriteLine("Odpalam aplikacje");
            Process p = Process.Start("..\..\..\UIAutomation\bin\Debug\UIAutomation.exe");
            AutomationElement mainForm;
            while ((mainForm = AutomationElement.RootElement.FindFirst(TreeScope.Children,new PropertyCondition(AutomationElement.ProcessIdProperty,p.Id)))==null)
            {
                Thread.Sleep(100);
            }
            
            var txtFirstNumber = mainForm.FindFirst(TreeScope.Descendants, new PropertyCondition(AutomationElement.AutomationIdProperty, "txtFirstNumber"));
            var txtSecondNumber = mainForm.FindFirst(TreeScope.Descendants, new PropertyCondition(AutomationElement.AutomationIdProperty, "txtSecondNumber"));
            var txtResult = mainForm.FindFirst(TreeScope.Descendants, new PropertyCondition(AutomationElement.AutomationIdProperty, "txtResult"));
            
            var btnAdd = mainForm.FindFirst(TreeScope.Descendants, new PropertyCondition(AutomationElement.AutomationIdProperty, "btnAdd"));
            var btnSubtract = mainForm.FindFirst(TreeScope.Descendants, new PropertyCondition(AutomationElement.AutomationIdProperty, "btnSubtract"));
            var btnMultiply = mainForm.FindFirst(TreeScope.Descendants, new PropertyCondition(AutomationElement.AutomationIdProperty, "btnMultiply"));
            var btnDivide = mainForm.FindFirst(TreeScope.Descendants, new PropertyCondition(AutomationElement.AutomationIdProperty, "btnDivide"));
            
            for (int i = 0; i < 200; i++)
            {
                double firstNumber = rand.Next(1, 1000);
                double seconNumber = rand.Next(1, 1000);
                Console.WriteLine("nn Test dla wartości: {0} , {1}", firstNumber, seconNumber);
                txtFirstNumber.SetTextBoxValue(firstNumber.ToString());
                txtSecondNumber.SetTextBoxValue(seconNumber.ToString());
                btnAdd.Click();
                Console.WriteLine("Dodawanie test OK ? , {0}", txtResult.GetTextBoxValue().ConvertToDouble() == firstNumber + seconNumber);
                btnDivide.Click();
                Console.WriteLine("Dzielenie test OK ? , {0}", Math.Round(txtResult.GetTextBoxValue().ConvertToDouble(), 2) == Math.Round(firstNumber / seconNumber, 2));
                btnSubtract.Click();
                Console.WriteLine("Odejmowanie test OK ? , {0}", txtResult.GetTextBoxValue().ConvertToDouble() == firstNumber - seconNumber);
                btnMultiply.Click();
                Console.WriteLine("Mnożenie test OK ? , {0}", txtResult.GetTextBoxValue().ConvertToDouble() == firstNumber * seconNumber);
            }
            
            Console.WriteLine("nEnd test runn");
            Console.ReadKey();
            p.Close();
            p.Kill();
        }
        catch (Exception ex)
        {
            Console.WriteLine("Fatal error: " + ex.Message);
            Console.WriteLine("nEnd test runn");
            Console.ReadKey();
        }
    }
}

oraz klasa pomocnicza

public static class UiAutomationHelper
{
    public static string GetTextBoxValue(this AutomationElement automationElement)
    {
        return (automationElement.GetCurrentPattern(ValuePattern.Pattern) as ValuePattern).Current.Value;
    }
    
    public static void SetTextBoxValue(this AutomationElement automationElement,string value)
    {
        (automationElement.GetCurrentPattern(ValuePattern.Pattern) as ValuePattern).SetValue(value);
    }
    
    public static void Click(this AutomationElement automationElement)
    {
        InvokePattern ipClickButton1 = (InvokePattern)automationElement.GetCurrentPattern(InvokePattern.Pattern);
        ipClickButton1.Invoke();
        Thread.Sleep(100); // dajmy czas na pokazanie okna, wykonanie funkcji itp
    }
    
    public static double ConvertToDouble(this string str)
    {
        double number;
        if (double.TryParse(str.Replace('.',','), out number  ))
            return number;
        throw new Exception("Niepoprawna wartość");
    }
}

MVVM i okna modalne

Wed, 30 Nov 2011 17:10:00 GMT

Często podczas użytkowania programów zachodzi konieczność pokazania dodatkowego okna, służącego do interakcji z użytkownikiem. Najczęściej okno takie należy pokazać w określonym przypadku. Jak już wcześniej zostało wspomniane cała logika powinna być umieszczona w ViewMoedlu, zatem nasuwa się pytanie, w jaki sposób z ViewModelu pokazać okno modalne - przecież ViewModel nie powinien mieć żadnych informacji o widoku. Rozwiązanie tego problemu polega na oddelegowaniu pokazywania widoków lub MessageBox-ów do wyspecjalizowanych klas tzw. serwisów. Ponadto w przypadku gdy chcemy pokazywać proste komunikaty możemy również skorzystać z Interaction/Interactivity oraz klasy Prisma InteractionRequest.

1. InteractionRequest

Jak już wcześniej wspomniano klasa InteractionRequest odpowiedzialna jest za pokazywanie komunikatów użytkownikowi - koordynuje ona działanie pomiędzy ViewModelem a widokiem. W celu skorzystania z klasy InteractionRequest w ViewModelu tworzymy publiczną właściwość udostpęniającą obiekt typu InteractionRequest na zewnątrz

public InteractionRequest<Confirmation> Request { get; set; }
Request = new InteractionRequest<Notification>();

Jak widać za generyczny typ T została podstawiona klasa Notification. Parametr T może przyjmować klasy dziedziczące po klasie Notification. Domyślnie w Prismie są dwie takie klasy:

Notification - wspomniana już wcześniej, służy do powiadomienia użytkownika o jakimś zdarzeniu
Confirmation - również służy powiadominiu użytkownika o jakiś zdarzeniu, ale zwraca ona reakcję użytkownika (czy potwierdził daną akcję czy nie - coś jak MessageBox YesNo)

W celu wywołania okienka należy odpalić funkcję Raise na przykład w taki sposób:

Request.Raise(new Notification { Content = "Info dla użytkownika", Title = "sth" }, confirmation => AfterMessageAction());

Funkcja Raise przyjmuje jeden lub dwa parametry. Przedstawy bardziej zaawansowaną wersję tej funkcji - tą z dwoma parametrami. W pierwszym parametrze podajemy obiekt typu Notification, w którym przekazujemy informacje do przekazania użytkownikowi (Content) oraz tytuł okna (Title). Drugim parametrem jest delegat Action , który określa co mamy zrobić po zamknięciu okna przez użytkownika. Ostatnią rzeczą jaką musimy zrobić, żeby wykorzystać NotificationRequest jest zdefiniowanie triggera w widoku, który będzie reagował na odpalenie funkcji Raise. Robimy to w następujący sposób:

definiujemy w XAML-u alias do namespaca interactivity

xmlns:i="http://schemas.microsoft.com/expression/2010/interactivity"

tworzymy InteractionRequestTrigger

<i:Interaction.Triggers>
   <prism:InteractionRequestTrigger SourceObject="{Binding Request}">
       <prism:PopupChildWindowAction></prism:PopupChildWindowAction>
   </prism:InteractionRequestTrigger>
 </i:Interaction.Triggers>

2. MessageBoxService

Alternatywą dla InteractionRequest jest stworzenie własnej klasy, do której zostałyby oddelegowane wszystkie prośby o pokazania MessageBoxa. Przykładowa implementacja takiego serwisu może wyglądać w następujący sposób. Po pierwsze stwórzmy interfejs z funkcjami potrzebnymi do pokazania MessageBoxa

public interface IMessageBoxService
{      
    MessageBoxResult ShowMessageBox (string info, string caption,MessageBoxButton buttons);      
}

Następnie zaimplementujmy ten interfejs w klasie MessageBoxService - właśnie do tej klasy będą oddelegowywane wszystkie prośby o pokazanie MessageBoxa

public class MessageBoxService : IMessageBoxService
{
    public MessageBoxResult ShowMessageBox(string info, string caption, MessageBoxButton buttons)
    {
        return MessageBox.Show(info, caption, buttons);
    }
}

Taki serwis musimy następnie przekazać do każdego ViewModelu , w którym będzie potrzeba pokazania MessageBoxa. Jako, że ręczne przekazywanie tego obiektu może być nużące, możemy skorzystać z dobrodziejstw Inversion of Control. Ja skorzystałem z kontenera z Unity. Po pierwsze musimy zarejestrować nasz typ w kontenerze

_container.RegisterType<IMessageBoxService, MessageBoxService>();

następnie MessageBoxService może zostać wstrzyknięty do każdego ViewModelu przy np. przy pomocy wstrzykiwania właściwości.

[Dependency]
public IMessageBoxService MessageBoxService
{
  get { return  messageBoxService; }
  set { messageBoxService = value; }
}

Oczywiście żeby nasza właściwość została wstrzykniętai, nasz ViewModel musi zostać stworzony przy użycia kontenera IO. Zauważmy, że właściwość MessageBoxService nie jest konkretnym typem, lecz interfejsem. Dzięki takiemu podejściu nasza aplikacja wciąż jest w łatwy sposób testowalna oraz ViewModel nie ma nic wspólnego z klasami widoku.

3. ModalWindowService

Do pokazywania widoków(jako okien) z poziomu ViewModelu posłużmy się podobnym mechanizmem jak w przypadku pokazywania MessageBox-ów. Zasada działania klasy, która stworzymy będzie taka sama, jednakże będziemy musieli odrobinę poszerzyć jej funkcjonalność. Po pierwsze tak jak poprzednio stwórzmy odpowiedni interfejs - IModalWindowService.

:::warning[UWAGA] Przykład ModalWindowServicu zostanie zaprezentowany dla Silverlight-a, gdyż okna modalne w silverlighcie to tak naprawdę okna semi-modalne. Główny wątek się nie zatrzymuje, jednakże użytkownik nie ma możliwości interakcji z oknami będącymi pod aktualnie widocznym oknem. :::

public interface IModalDialogService
{
    void ShowDialog<TViewModel>(IModalView<TViewModel> view,Action<TViewModel> CloseAction) where TViewModel : ViewModelBase;       
}

Zauważmy, że funkcja ShowDialog w parametrze nie przyjmuje konkretnego widoku, lecz interfejs, który każde okno modalne powinno implementować - IModalView. Interfejs ten może wyglądać w następujący sposób:

public interface IModalView<TViewModel> where TViewModel : ViewModelBase
{
    /// 
    /// ViewModel odpowiedzialny za dane okno
    /// 
    TViewModel ViewModel { get; set; }
    /// 
    /// DialogResult po zamknieciu okna
    /// 
    bool? DialogResult { get; set; }
    /// 
    /// zamkniecie okna
    /// 
    void Close();
    /// 
    /// Pokazanie okna
    /// 
    void Show();
    /// 
    /// Zdarzenie wywoływane w momencie zamkniecia okna modalnego
    /// 
    event EventHandler Closed;
    /// 
    /// Zdarzenie wywoływane w chwli zamykania widoku 
    /// 
    event EventHandler<CancelEventArgs> Closing;
}

Jako, że okna modalne w Silverlighcie są tak naprawdę oknami semi-modalnymi musimy wiedzieć kiedy dane okno zostanie zamknięte. Dlatego, też interfejs ten zawiera zdarzenie

event EventHandler Closed;

ponadto wypadałoby sprawdzić czy dane wpisane w oknie są poprawne, dlatego też dodano zdarzenie

event EventHandler<CancelEventArgs> Closing;

w przypadku gdy dane wpisane w oknie nie będą poprawne, nasz ModalDialogService zapobiegnie zamknięciu okna. Ostatecznie nasza klasa ModalDialogService może wyglądać w następujący sposób:

public class ModalDialogService : IModalDialogService
{
    private EventHandler<CancelEventArgs> ClosingEventHandler;
    private EventHandler CloseEventHandler;
    public void ShowDialog<TViewModel>(IModalView<TViewModel> view, Action<TViewModel> CloseAction) where TViewModel : ViewModelBase
    {
        view.Closing += ClosingEventHandler = (sender, args) =>
        {
            if (view.DialogResult.HasValue && view.DialogResult.Value)
            {
                if (!(args.Cancel = !view.ViewModel.Validate())) // jezeli mozna zamknac okno to odczepiamy handler
                    view.Closing -= ClosingEventHandler;
            }
        };
        if (CloseAction != null)
        {
            view.Closed += CloseEventHandler = (sender, args) =>
                {
                    CloseAction(view.ViewModel);
                    view.Closed -= CloseEventHandler;
                };
        }
        view.Show();
    }
}

Nasz serwis podobnie jak w przypadku MessageBoxServicu rejestrujemy w kontenerze, a następnie wstrzykujemy go do ViewModelu

_container.RegisterType<IModalDialogService, ModalDialogService>();
[Dependency]
public IMessageBoxService MessageBoxService
{
 get { return  messageBoxService; }
 set { messageBoxService = value; }
}

Pozostaje nam jedynie kwestia wyjaśnienia w jaki sposób wywołać nasze okno. Nie powinniśmy tworzyć okna w ViewModelu, gdyż łamie to zasadę MVVM-a. Dlatego też po raz kolejny skorzystamy z kontenera IoC. W kontenerze IoC rejestrujemy sobie nasz widok

_container.RegisterType<IModalView<AddPersonViewModel>, AddPersonView>()

jako, że ViewModel jest wstrzykiwany do View poprzez Dependency Injection należy również w kontenerze zarejestrować odpowiedni typ ViewModelu - czyli w tym przypadku AddPersonViewModel

_container.RegisterType<AddPersonView>()

Mając już zarejestrowane w kontenerze wszystkie niezbędne typu możemy wywołać okno z ViewModelu w następujący sposób:

ModalDialogService.ShowDialog<EditAllPlayersViewModel>(_container.Resolve<IModalView<AddPersonViewModel>>(), model => {//tutaj jakas logika });

Obiekt widoku otrzymujemy z kontenera IoC wykorzystując funkcję Resolve, w miejsce LambdaExpression wstawiamy nasze wyrażenie w którym określamy co zrobimy po poprawnym zamknięciu okna. Zauważmy, że ViewModel nie ma żadnych informacji o widoku - kontener nie zwraca nam konkretnego typu lecz interfejs. Dzięki takiemu podejściu nasza aplikacja może być w łatwy sposób testowalna.

Interactivity oraz Interaction

Tue, 29 Nov 2011 21:01:00 GMT

Interactions oraz Interactivity są to dwie dll-ki, które poszerzają sposób komunikacji pomiędzy widokiem oraz ViewModelem. Wprowadzają one nowy typ EventTriggerów(w Silverlighcie nie ma triggerów, natomiast w WPF-ie event triggery można praktycznie używać jedynie do animacji) oraz dodatkowo wprowadzają ciekawe sposoby(funkcje) na interakcję widoku z ViewModelem.

Pierwszym z tych sposobów jest użycie właściwości InvokeCommandAction. Jak sama nazwa wskazuje można wywołać komendę z ViewModelu. Jaka jest różnica między wywołaniem komendy poprzez InvokeCommandAction, a Command="{Binding CommandName}"? InvokeCommandAction ma tą przewagę nad normalnm bindowaniem do property Command, że pozwala wywołać daną komendę w odpowiedzi na zajście jakiegoś zdarzenia na widoku. Przykładowe użycie może wyglądać następująco:

<Button Content="Submit" IsEnabled="{Binding CanSubmit}">
      <i:Interaction.Triggers>
        <i:EventTrigger EventName="MouseMove">
           <i:InvokeCommandAction Command="{Binding SubmitCommand}"/>
        </i:EventTrigger>
      </i:Interaction.Triggers>
</Button>

Powyższy przykład działa w następujący sposób. Za każdym razem gdy zostanie wywołane zdarzenie MouseMove na przycisku, odpalona zostanie komenda SubmitCommand. Wadą używania InvokeCommandAction jest to, że sami musimy się martwić o wygaszenie kontrolki w przypadku gdy dana komenda nie może być wykonana. Dlatego też w pierwszej linii mamy bindowanie właściwości IsEnabled przycisku do właściwości CanSubmit z ViewModelu. Alias i: jest aliasen na namespace interactivity z dll-ki

System.Windows.Interactivity.xmlns:i="clr-namespace:System.Windows.Interactivity;assembly=System.Windows.Interactivity".

Drugim sposobem powiadomiania ViewModelu o jakimś zdarzeniu w widoku jest użycie InvokeMethodAction. Dzięki tej właściwości możemy bezpośrednio z widoku (z XAML-a) wywołać funkcję w ViewModelu. Składnia przedstawia się w następujący sposób:

<Button Content="Submit" IsEnabled="{Binding CanSubmit}">
     <i:Interaction.Triggers>
       <i:EventTrigger EventName="Click">
        <i:CallMethodAction TargetObject="{Binding}" Method="Submit"/>
      </i:EventTrigger>
     </i:Interaction.Triggers>
</Button>

TargetObject jest zbindowany do DataContextu, to właśnie tam będzie szukana funkcja Submit. Należy pamiętać, że właściwość CallMethodAction nie wspiera parametrów funkcji. Zatem jeżeli musimy wywołać jakąś funkcję z parametrami, należy opakować ją w funkcję bezparametrową, natomiast wszystkie parametry przekazać z właściwości ViewModelu.

Kolejnym ciekawym featurem Interactivity jest klasa Behavior. Jest niezastąpiona jeżeli potrzebujemy ingerować w działanie widoku po jakimś zdarzeniu. Nie musimy wówczas tworzyć obsługi eventów w code behind. Możemy wyłuskać daną funkcjonalność i zamknąć ją w klasie Behavior a następnie doczepić do wszystkich widoków danego typu. Załóżmy, że sterujemy ListBoxem z poziomu ViewModelu (przełączamy SelectedItem). Możemy zaznaczyć jakiś Item, co jednak jeżeli nasza lista jest bardzo długa,a zaznaczamy ostatni element. Na widoku element rzeczywiście się zaznaczył jednak lista się nie przewinęła. Przez co cały czas wiszą elementy z początku i nie widać czy któryś element jest zaznaczony. Dopiero gdy przeskrolujemy ręcznie ListBoxa widzimy, że rzeczywiście prawidłowo zareagował na zmianę property w ViewModelu. Jest to idealna sytuacja, aby stworzyć własny Behavior, który będziemy mogli podczepić do wszystkich listboxów w każdym widoku.

public class Behavior<ListBox>
{
  protected override void OnAttached()
  {
    AssociatedObject.SelectionChanged += ListBoxSelectionChanged;
  }

  protected override void OnDetaching()
  {
     AssociatedObject.SelectionChanged -= ListBoxSelectionChanged;
  }

  private void ListBoxSelectionChanged(object sender, SelectionChangedEventArgs e)
  {
    if (sender is ListBox && ((ListBox)sender).SelectedItem != null)
    {
        var listBox = sender as ListBox;
        listBox.ScrollIntoView(listBox.SelectedItem);
    }
  }
}

Metoda OnAttached odpala się w momencie, gdy behavior jest podpinany do kontrolki. W metodzie tej powinniśmy podpiąć się pod wszystkie eventy, które są dla nas istotne. W momencie, gdy widok jest niszczony wywołuje się metoda OnDetaching, w której powinniśmy odpiąć wszystkie metody od eventów.

Prism - CommandBehaviors

Tue, 29 Nov 2011 20:20:00 GMT

Analizując wcześniejsze przykłady pokazujące użycie DelegateCommand można odnieść wrażenie, że mimo tego iż są one bardzo użyteczne, ich użycie jest niestety bardzo ograniczone. Jedynie niektóre komponenty WPF-a i Silverlight-a mają właściwość Command do której można zbindować nasz obiekt DelegateCommand. Ponadto właściwość ta reaguje jedynie na wybrane zahardcodowane w kontrolce zdarzenie (zdarzenie Click). Co w przypadku gdybyśmy chcieli zareagować np. na zdarzenie MouseMove za pomocą komendy? Nasz problem możemy rozwiązać poprzez:

Interactivity
Interactions
CommandBehaviors

W tym poście zostanie przedstawione rozwiązanie trzecie - CommandBehaviors

Pierwszą rzeczą jaką należy zrobić w celu stworzenia komendy reagującej na inne zdarzenie niż Click jest stworzenie klasy dziedziczącej po CommandBehaviorBase. Załóżmy, że zrobimy komendę reagującą na zdarzenie MouseMove

public class MouseMoveCommandBehavior : CommandBehaviorBase<Control>
{
    private MouseOutCommandBehavior(Control control) : base(control)
    {
        control.MouseMove += (sender, args) => 
        {
            this.ExecuteCommand();
        };
    }
}

Piersza część już za nami, ale pojawia się teraz pytanie jak z tego skorzystać. Żeby mieć możliwość użycia powyżej klasy wykorzytamy attached dependency property. Musimy sobie stworzyć pomocniczą statyczną klasę, w której to zarejestrujemy nasze właściwości. Zacznijmy od zarejestrowania dependency property o nazwie Command - do tego obiektu będziemy bindowali komendy z ViewModelu (komendy reagujące na zdarzenie MouseMove)

public static class MouseMove 
{
    public static ICommand GetCommand(DependencyObject obj)
    {
        return (ICommand)obj.GetValue(CommandProperty);
    }

    public static void SetCommand(DependencyObject obj, ICommand value)
    {
        obj.SetValue(CommandProperty, value);
    }

    public static readonly DependencyProperty CommandProperty =
            DependencyProperty.RegisterAttached("Command", typeof(ICommand), typeof(MouseMove), new PropertyMetadata(OnSetCustomCommandCallback));
}

zauważmy, że podłączyliśmy event handlera reagującego na zmianę naszej nowo stworzonej właściwości Command. Funkcja OnSetCustomCommandCallback wygląda następująco:

private static void OnSetCustomCommandCallback(DependencyObject dep, DependencyPropertyChangedEventArgs e)
{
    var control = dep as Control;
    if (control != null)
    {
        MouseMoveCommandBehavior behavior = GetorCreateMouseMoveBehavior(control);
        behavior.Command = e.NewValue as ICommand;
    }
}

Funkcja ta po prostu w razie potrzeby tworzy nowy obiekt typu MouseMoveCommandBehavior (gdy ktoś zbinduje komende) i dopina go do naszej kontrolki. Pomocnicza funkcja GetorCreateMouseMoveBehavior wygląda tak:

private static MouseMoveCommandBehavior GetorCreateMouseMoveBehavior(Control listBox)
{
    var behavior = listBox.GetValue(MouseMoveBehaviorProperty) as
        MouseMoveCommandBehavior;
    if (behavior == null)
    {
        behavior = new MouseMoveCommandBehavior(listBox);
        listBox.SetValue(MouseMoveBehaviorProperty, behavior);
    }
    return behavior;
}

Obiekt rejestrowany poprzez funkcję GetorCreateMouseMoveBehavior jest dopinany do kolejnej attached property, która również została zadeklarowana w tym pliku

public static MouseMoveCommandBehavior GetMouseMoveBehavior(DependencyObject obj)
{
    return (MouseMoveCommandBehavior)obj.GetValue(MouseMoveBehaviorProperty);
}

public static void SetMouseMoveBehavior(DependencyObject obj, MouseMoveCommandBehavior value)
{
    obj.SetValue(MouseMoveBehaviorProperty, value);
}

public static readonly DependencyProperty MouseMoveBehaviorProperty =
    DependencyProperty.RegisterAttached("MouseMoveBehavior", typeof(MouseMoveCommandBehavior), typeof(MouseMove), null );

Mając zdefiniowane wszystkie powyższe właściwości możemy już wykorzystać naszą komendę. Jednakże przydałoby się dodać jeszcze jedną właściwość (opcjonalnie), mianowicie właściwość CommandParameters

public static object GetCommandParametr(DependencyObject obj)
{
    return (object)obj.GetValue(CommandParametrProperty);
}

public static void SetCommandParametr(DependencyObject obj, object value)
{
    obj.SetValue(CommandParametrProperty, value);
}

public static readonly DependencyProperty CommandParametrProperty =
    DependencyProperty.RegisterAttached("CommandParametr", typeof(object), typeof(MouseMove), new PropertyMetadata(OnSetCustomCommandParameterCallback));`

W tym propertisie również reagujemy na przypisnie obiektu. Handler OnSetCustomCommandParameterCallback wygląda następująco

private static void OnSetCustomCommandParameterCallback(DependencyObject dep,DependencyPropertyChangedEventArgs e)
{
    var listBox = dep as Control;
    if (listBox != null)
    {
        MouseMoveCommandBehavior behavior = GetorCreateMouseMoveBehavior(listBox); ;
            behavior.CommandParameter = e.NewValue;
    }
}

Mając już zdefiniowane wszystkie niezbędne właściwości możemy użyć ich w XAML-u. Po pierwsze musimy dodać alias do namespaca gdzie znajduje się nasza statycza klasa MouseMove. W moim przypadku wygląda to następująco:

xmlns:AttachedCommands="clr-namespace:MainModule.Commands"

Następnie bindujemy jakąś kontrolkę do naszego attached property Command. Wygląda to w następujący sposób:

<Button Name="txtButton" Grid.Column="2" AttachedCommands:MouseMove.Command="{Binding SomeCommandFromViewModel}"></Button>

Od teraz za każdym razem jak najedziemy na txtButton wywoła się komenda SomeCommandFromViewModel. Podsumowując trzeba się całkiem sporo napisać żeby zmusić do działania CommandBehaviors . W następnym poście przedstawię dwa sposoby na osiągnięcie tego samego efektu mniejszym kosztem.

Prism - Komendy

Tue, 29 Nov 2011 19:33:00 GMT

1. DelegateCommands

DelegateCommands w Prismie są to obiekty, które implementują interfejs ICommand, służą one do interakcji widoku z ViewModelem. Korzystając z Prisma nie musimy już pisać własnej klasy implementującej ten interfejs (tak jak to zrobiliśmy tutaj). Konstruktor klasy DelegateCommand przyjmuje dwa parametry:

Action execteMethod - funkcja odpalania przy wywołaniu komendy,
Func canExecuteMethod - funkcja sprawdzająca czy daną komendę można wywołać

DelegateCommands z Prisma używamy w taki sam sposób w jaki używaliśmy komend w tym poście.

2. CompositeCommands

CompositeCommands są to obiekty, które przechowują kolekcją obiektów typu DelegateCommand. Tworzenie CompositeCommand jest bardzo proste. Po pierwsze musimy stworzyć obiekt typu CompositeCommand

public CompositeCommand SomeCompositeCommand = new CompositeCommand();

następnie rejestrujemy w tym obiekcie obiekt implementujący interfejs ICommand, czyli w naszym przypadku jakiś obiekt typu DelegateCommand. Robimy to w następujący sposób:

DelegateCommand DistributeCommand = new DelegateCommand(DistributeCards);
SomeCompositeCommand.RegisterCommand(DistributeCommand);

w razie potrzeby możemy usunąć komendę z kolekcji komend przy pomocy następującej składni:

SomeCompositeCommand.UnregisterCommand(DistributeCommand);

Mając już stworzony obiekt typu CompositeCommand oraz zarejestrowane w nim obiekty DelegateCommand możemy zastosować bindowanie.

<Button Command="{Binding SomeCompositeCommand}" Grid.Column="1">Rodzaj</Button>

Od teraz, w chwili naciśnięcia przycisku, najpierw sprawdzane jest czy dana CompositeCommand może zostać wykonana. CompositeCommand może zostać wykonana tylko wtedy, gdy wszystkie komendy do niej podpięte mogą zostać wykonane. Jeżeli warunek ten zostanie spełniony następuje wywoływanie po kolei wszystkich metod execute z komend podpiętych do danej CompositCommand. CompositeCommand znajduje zastosowanie w przypadku gdy pozwalamy użytkownikowi na edycję wielu elementów jednocześnie i potrzebujemy w prosty sposób przeprowadzić walidację na poszczególnych widokach.

CompositeCommand może również wykorzystana np. do zapisania tylko aktywnego widoku. Dzięki temu, że DelegateCommand implementuje interfejs IActiveAware, CompositeCommand wie, który widok jest aktualnie zaznaczony i zapisze tylko wybrany widok.

Interfejs IActiveAware wygląda w następujący sposób

public interface IActiveAware
{    
    bool IsActive { get; set; }
    event EventHandler IsActiveChanged;
}

bool IsActive - wskazuje czy dana komenda jest aktualnie aktywna
event EventHandler IsActiveChanged - informuje o zmianie aktywności komendy

W celu wykorzystania tego interfejsu przez CompositeCommand należy skorzystać z drugiego dostępnego konstruktora tej klasy

CompositeCommand SomeCompositeCommand = new CompositeCommand(true);

Od teraz po naciśnięciu przycisku zbindowanego do tej komendy, wywołana zostanie jedynie aktywna komenda - czyli taka, której właściwość IsActive została ustawiona na true. Niestety o ustawianie aktywności danej komendy musimy zadbać sami.

Kolekcje wspierające sortowanie, grupowanie oraz filtrowanie

Mon, 28 Nov 2011 20:13:00 GMT

1. ListViewCollection (WPF)

ListViewCollection jest to kolekcja wprowadzona do WPF-a, która wspiera sortowanie, grupowanie oraz filtrowanie. Kolekcję taką tworzymy w następujący sposób

List<Player> palyerList = new Player { new Player(),new Player()};
public ListViewCollection<Player> PlayerListCollectionView {get;set;}
ListViewCollection<Player> PlayerListCollectionView= new ListViewCollection<Player>(playerList);

czyli po prostu w konstruktorze przesyłamy obiekt implementujący interfejs IEnumerable

Filtrowanie

W celu przefiltrowania kolekcji wystarczy podać odpowiedni obiekt typu Predicate(czyli tak naprawdę wystarczy napisać funkcję zwracającą bool oraz przyjmującą w parametrze obiekt). Załóżmy, że chcemy pokazać na widoku jedynie tych graczy, który nazywają się Tomek. W tym celu wystarczy, że zrobimy coś takiego:

PlayerListCollectionView.Filter = val => { return (val as Player).Name.ToLower() == "tomek"; }

po zaaplikowaniu predicata widok zbindowany do danej listy automatycznie się odświeży. W razie czego można zawsze wymusić oświeżenie przez wywołanie funkcji

PlayerListCollectionView.Refresh();

Grupowanie

Kolekcja ListViewCollection wspiera również grupowanie. W celu pogrupowania listy po jakimś elemencie wystarczy do naszej listy dorzucić tzw. group description. Odbywa się to w taki sposób:

PlayerListCollectionView.GroupDescriptions.Add(new PropertyGroupDescription { PropertyName = "Name" }

Po dodaniu PropertyGroupDescription widok automatycznie pogrupuje nam elementy po danych właściwościach.

Sortowanie

Nasza kolekcja wspiera również sortowanie. W celu posortowania wystarczy stworzyć obiekt implementujący interfjes IComparer, a następnie przypisać go do właściwości CustomSort

public class PlayerComparer : IComparer
{
    public int Compare(object x, object y)
    {
        if (((Player)x).Age > (((Player)y).Age))
        {
            return 1;
        }
        return -1;
    }
}

PlayerListCollectionView.CustomSort = new PlayerComparer ()

po takiej akcji widok automatycznie się odświeży i pokaże posortowane dane.

2. PagedCollectionView (Silverlight)

PagedCollectionView jest to uboższą wersja ListCollectionView z WPF-a. Grupowanie oraz filtrowanie dobywa się w ten sam sposób, jednakże sortowanie zostało w znaczny sposób utrudnione. Sortować możemy jedynie po właściwościach, nie możemy stworzyć własnego comparera, który zostałby użyty do wykonania operacji sortowania. Wykonanie operacji może wyglądać w następujący sposób:

PlayerPagedCollection.SortDescriptions.Clear();
PlayerPagedCollection.SortDescriptions.Add(new System.ComponentModel.SortDescription("Name", ListSortDirection.Ascending));

W tym wypadku nasza kolekcja zostanie posortowana po właściwości Name

Walidacja

Mon, 28 Nov 2011 19:03:00 GMT

Walidacja jest to technika sprawdzająca, czy dany obiekt spełnia pewne założenia poprawności danych. W WPF-ie oraz Silverlighcie istnieją trzy sposoby walidacji obiektów:

walidacja poprzez rzucanie wyjątków,
walidacja z użyciem interfejsu IDataErrorInfo,
walidacja z użyciem interfejsu INotifyDataErrorInfo

1. Walidacja poprzez rzucanie wyjątków

Walidacja poprzez rzucanie wyjątków odbywa się w następujący sposób. W seterze danej właściwości dodajemy warunek sprawdzający czy wpisane dane są poprawne. Jeżeli nie to najzwyczajniej w świecie rzucamy wyjątek, w którym podajemy komunikat błędu. Przykładowy properties z walidacją może wyglądać w ten sposób:

private string _name;
public string Name
{
    get { return _name; }
    set
    {
        _name = value;
        if (string.IsNullOrEmpty(_name))
            throw new Exception("Nazwa nei może być pusta");
    }
}

W celu "wyłapania" tego wyjątku i pokazania odpowiedniego komunikatu, w bindingu musimy ustawić właściwość ValidatesOnExceptions na wartość true.

<TextBox Text="{Binding Name, ValidatesOnExceptions=True, Mode=TwoWay}" />

Taki sposób walidowania jest jednak rzadko stosowany i wielu programistów twierdzi, że rzucanie wyjątków powinno się odbywać tylko w przypadku nieprawidłowego działania aplikacji. Ponadto walidowane propertisy nie mogą być autopropertisami, co dodatkowo wydłuża czas tworzenia klas.

2. Walidacja z użyciem interfejsu `IDataErrorInfo`

public interface IDataErrorInfo
{
    string this[string columnName] { get; }
    string Error { get; }
}

W celu wyłapywania błędów w widoku, należy w bindingu ustawić ValidatesOnDataError = true

<TextBox Text="{Binding Name, ValidatesOnDataError=True, Mode=TwoWay}" />

Przykładowa klasa implementująca interfejs IDataErrorInfo może wyglądać następująco:

public class Customer : IDataErrorInfo
{
    public string Name { get; set; }
    
    public string Error
    {
        get { return string.Empty; }
    }
    
    public string this[string propertyName]
    {
        get 
        {
            string result = string.Empty;
            if (propertyName == "Name")
            {
                if (string.IsNullOrEmpty(Name))
                    result = "Wartość nie moż być pusta";
            }
            
            return result;
        }
    }
}

Najważniejszą metodą w powyższej klasie jest indekser

string this[string propertyName]

to właśnie tutaj mogą zostać sprawdzone wszystkie właściwości danego obiektu - propertyName oznacza nazwę propertisu, który walidujemy. W przypadku, gdy wartość jakiejś właściwości jest nieprawidłowa, w pole result wpisujemy komunikat błędu. Komunikaty te "wyłapywane" są przez widok, a następnie wyświetlane w postaci komunikatów przy odpowiednich kontrolkach. Jeżeli wszystko jest OK zwracamy string.Empty. Walidacje przy pomocy interfejsu IDataErrorInfo idealnie nadają się do walidowania modelu.

3. Walidacja z użyciem interfejsu `INotifyDataErrorInfo`

Interfejs INotifyDataErrorInfo prezentuje się w następujący sposób:

public interface INotifyDataErrorInfo
{
     bool HasErrors { get; }
     event EventHandler<DataErrorsChangedEventArgs> ErrorsChanged;
     IEnumerable GetErrors(string propertyName);
}

bool HasErrors - określa czy dany obiekt zawiera błędy
event EventHandler ErrorsChanged - zdarzenie informujące o zmienie ilości błędów w obiekcie
IEnumerable GetErrors(string propertyName) - funkcja pobierająca kolekcję błędów dla danego propertisa

W celu "wyłapania" błędów przez widok należy w bindingu ustawić properties NotifyOnValidationError = true

<TextBox Text="{Binding Name, NotifyOnValidationError=True, Mode=TwoWay}" />

Jak już wcześniej wspomniano funkcja GetErrors(string propertyName) zwraca kolekcję błędów dla danej właściwości. Zatem do klasy, która będzie implementowała interfejs INotifyDataErrorInfo należy dodać kolekcję przechowującą obiekty typu ValidationResult. Przykładowa implementacja interfejsu może wyglądać w następujący sposób:

public class BaseViewModel : INotifyDataErrorInfo
{
    private ICollection<ValidationResult> _validationResults;
    public IEnumerable GetErrors(string propertyName)
    {
        return _validationResults.Where(result => result.MemberNames.Contains(propertyName));
    }
 
    public bool HasErrors
    {
        get { return _validationResults.Count > 0; }
    }
 
    public event EventHandler<DataErrorsChangedEventArgs> ErrorsChanged;
    
    private void NotifyErrorsChanged(string propertyName)
    {
        if(ErrorsChanged!=null)
            ErrorsChanged(this, new DataErrorsChangedEventArgs(propertyName));
    }

    protected void Validate()
    {
        _validationResults.Clear();
        Validator.TryValidateObject(this, new ValidationContext(this, null, null), _validationResults, true);
     
        foreach (var result in _validationResults)
            NotifyErrorsChanged(result.MemberNames.First());
    }
    
    protected void Validate(string propertyName)
    {
        var validationResults = _validationResults.Where(result => result.MemberNames.Contains(propertyName)).ToList();
        foreach (var result in validationResults)
               _validationResults.Remove(result);
        
        Validator.TryValidateProperty(value, new ValidationContext(this, null, null) { MemberName = propertyName }, _validationResults);
           NotifyErrorsChanged(propertyName);
     }
}

Funkcja Validate() najpierw czyści wszystkie poprzednie wyniki walidacji, a następnie przy pomocy klasy Validator oraz funkcji TryValidateObject waliduje wszystkie właściwości, które zostały oznaczone atrybutem dziedziczącym po klasie ValidationAttribute. Z kolei funkcja Validate(string propertyName) waliduje tylko konkretną właściwość. Przykładowe walidowanie właściwości przy pomocy atrybutów może wyglądać w następujący sposób:

[Required(ErrorMessage = "Pole nie może być puste")]
public string Subject
{
    get { return _subject; }
    set
    {
        _subject = value;
         Validate(“Subject”)
    }
}

W celu stworzenia własnych regół walidacji, nie uwzględnionych w zapewnionych przez framework atrybutach należy stworzyć własną klasę dziedziczącą po klasie ValidationAttribute, a następnie przeciążyć metodę IsValid. Przykładowa klasa może wyglądać w następujący sposób:

public class IntValidation : ValidationAttribute
{
    private bool allowNull;
    public IntValidation(bool allowNull)
    {
        this.allowNull = allowNull;
    }
    
    protected override ValidationResult IsValid(object value, ValidationContext validationContext)
    {
        if (value != null)
        {
            int resul;
            if (int.TryParse(value.ToString(), out resul))
                return ValidationResult.Success;
            else
                return new ValidationResult(ErrorMessage, new List{validationContext.MemberName });
        }
        
        return allowNull ? ValidationResult.Success : new ValidationResult(ErrorMessage);
    }
}

Walidacja przy użyciu interfejsu INotifyDataErrorInfo idealnie nadaje się (wg mnie) do walidowaniu całych ViewModeli. Przy zamykaniu okna wystarczy wywołać funkcję Validate z bazowego ViewModelu, a w przypadku gdy zwróci ona false zatrzymać zamykanie okna. Jako, że walidacja zostanie przeprowadzona na wszystkich wybranych przez nas propertisach, widok automatycznie się zaktualizuje i pokaże komunikaty błędów na odpowiednich kontrolkach okna.

Routed Events - nowy rodzaj zdarzeń w WPF-ie

Mon, 28 Nov 2011 18:20:00 GMT

RoutedEvent jest to nowy typ zdarzeń, który po raz pierwszy został zaprezentowany w WPF-ie. Głównym założeniem RoutedEventów jest to, że w momencie wywołania takiego zdarzenia może ono podróżować w górę, lub w dół drzewa wizualnego oraz drzewa logicznego. Każdy RoutedEvent może przyjmować jedną z trzech strategii poruszania się po drzewie:

Bubbling - zdarzenie najpierw jest wywoływane w elemencie źródłowym, a następnie podróżuje ono w górę drzewa wizualnego (od naszego elementu do korzenia drzewa), aż do roota (lub do momenty gdy nie zostanie obsłużone poprzez e.Handled = true)
Tunelling - zdarzenie wywoływane jest w korzeniu drzewa, a następnie podróżuje w dół drzewa, aż osiągnie element źródłowy (lub gdy nie zostanie obsłużone poprzez e.Handled = true)
Direct - zdarzenie jest wywoływane tylko i wyłącznie w elemencie źródłowym - czyli zdarzenie to zachowuje się tak samo jak standardowe .NET-owe zdarzenia

Definiowanie własnych RoutedEvents wygląda następująco. W pierwszym kroku przy pomocy EventManagera i jego funkcji RegisterRoutedEvent rejestrujemy nasze zdarzenie.

public static RoutedEvent PreviewTrippleClickEvent = EventManager.RegisterRoutedEvent("PreviewTrippleClick", RoutingStrategy.Tunnel, typeof(RoutedEventHandler), typeof(MyContentControl));

następnie piszemy wrapper RoutedEventa na zwykłe zdarzenie

public event RoutedEventHandler PreviewTrippleClick
{
    add
    {
        AddHandler(MyContentControl.PreviewTrippleClickEvent, value);
    }
    remove
    {
        RemoveHandler(MyContentControl.PreviewTrippleClickEvent, value);
    }
}

Funkcja RegisterRoutedEvent przyjmuje cztery parametry:

Nazwa naszego zdarzenia - taka sama jak nazwa standardowego eventa opakowującego RoutedEvent
Strategia routingu - czyli czy nasze zdarzenie będzie typu Bubble, Tunnel lub Direct
Typ handlera - czyli typ delegata/funkcji jaki będzie można podłączyć do zdarzenia, żeby je obsłużyć
Typ właściciela - czyli typ klasy do której należy dany event

Jako, że stworzenie nowego RoutedEventa jest dość czasochłonne (w porównaniu ze zwykłym zdarzeniem) warto zassać sobie snippet, który znacząco przyśpiesza tworzenie routed eventów. Snippet taki można znaleźć tutaj RoutedEventSnippet. Mając już zdefiniowany nowy RoutedEvent można go wywołać w następujący sposób:

RaiseEvent(new RoutedEventArgs(MyContentControl.TrippleClickEvent, this));

Funkcja RaiseEvent w parametrze przyjmuje obiekt typu RoutedEventArts. W przypadku gdyby nie był on dla nas wystarczający (potrzebujemy przesłać więcej parametrów itp.), musimy napisać klasę rozszerzającą klasę RoutedEventArts.

Routowanie zdarzenia może zostać zatrzymane, poprzez ustawienie flagi e.Handled na true. Gdzie e jest to obiekt klasy RoutedEventArgs. Przykładowe zatrzymanie routowania eventa może wyglądać w następujący sposób

private void Window_MouseRightButtonDown(object sender, MouseButtonEventArgs e)
{
    e.Handled = true;
}

:::warning[UWAGA] Można zadeklarować zdarzenie w taki sposób aby wartość flagi e.Handled była pomijana. Jednak można to zrobić jedynie z poziomu kodu. Za pomocą metody AddHandler(RoutedEvent, Delegate, bool) jeżeli ustawimy ostatni parametr na true, wówczas nasza metoda wykona się nawet w przypadku gdy e.Hadnled == true. Metoda ta dostępna jest dla klasy UIElement i wszystkich klas po niej dziedziczących. :::

Attached events

Attached events działają podobnie jak attached dependency properties. Pozwalają one rozszerzyć kolekcję zdarzeń danej kontrolki o dodatkowe zdarzenia(nawet jeżeli nie mamy dostępu do źródeł danej kontrolki. Przykładowo, istnieje możliwość obsługi eventu click na kontrolce, która tak naprawdę takiego eventu nie posiada. Każdy RoutedEvent może zostać użyty jako attached event.

<Window x:Class="MCTSTrainingChapter1.ThirdMainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        Title="ThirdMainWindow" Height="300" Width="300">
    <Grid Button.Click="Grid_Click">
        <Grid.RowDefinitions>
            <RowDefinition></RowDefinition>
            <RowDefinition></RowDefinition>
            <RowDefinition></RowDefinition>
        </Grid.RowDefinitions>
        <Button Grid.Row="0">Top</Button>
        <Button Grid.Row="1">Middle</Button>
        <Button Grid.Row="2">Bottom</Button>
    </Grid>
</Window>

Na gridzie mamy zdefiniowane 3 przyciski, chcielibyśmy aby po naciśnięciu każdego z tych przycisków, wywoływała się odpowiednia funkcja.

Jednym ze sposobów napisania takiej funkcjonalności jest podłączenie eventa Click z każdego przycisku do jednego handlera. Rozwiązanie to jest jak najbardziej poprawne, jednakże w przypadku dużej ilości przycisków może być to czasochłonne. Można zrobić to prościej, przy wykorzystaniu attached events. Jak widzimy w listingu przedstawionym wyżej, do grida "przypięto" event Click z klasy Button. Od teraz za każdym razem gdy jakikolwiek przycisk będący w obrębie Grida zostanie naciśnięty, zdarzenie to zostanie przechwycone przez handler zdefiniowany w gridzie - Grid_Click

Trigery - Triggers

Mon, 28 Nov 2011 17:20:00 GMT

Trigery jest to mechmizm WPF-a służący reakcji UI na jakieś zdarzenie. Wyróżniamy cztery rodzaje triggerów

Property triggers - używane do zareagowanie na zmiany dependency property w danej kontrolce,
Data triggers - używane do zareagowanie na zmiany w bindowanych obiektach - można podłączyć się do właściwości z DataContextu jak i z danej kontrolki,
MultiDataTriggers - używane do reagowania na zmiany kilku właściwości,
MultiTrigger - używane do reagowania na zmiany kilku dependecy property w danej kontrolce,
Event triggers - używane do reagowania na jakieś zdarzenie - służą do odpalania animacji

1. Property triggers

Oto przykład wykorzystania Property Triggera. W ResourceDictionary tworzymy styl, który zostanie przypisany do przycisku.

<Style TargetType="{x:Type Button}">
    <Style.Triggers>
        <Trigger Property="IsMouseOver" Value="True">
            <Setter Property="Background" Value="Black"></Setter>
        </Trigger>
    </Style.Triggers>
    <Setter Property="Background" Value="Red"/>
</Style>

Widzimy, że dany trigger jest powiązany z właściwością IsMouseOver. W przypadku gdy wartość tej właściwości zostanie ustawiona na true, tło przycisku zostanie zmienione na czarne. Natomiast gdy IsMouseOverpowróci do stanufalse`, tło przycisku wróci do wartości sprzed zmiany.

2. Data triggers

Oto przykład wykorzystania Data Triggera. W ResourceDictionary tworzymy styl, który zostanie przypisany do przycisku.

<Style x:Key="bindingTest" TargetType="Button">
    <Style.Triggers>
        <DataTrigger Binding="{Binding Path=Text}" Value="Kolor">
            <Setter Property="Background"  Value="Beige"/>
        </DataTrigger>
    </Style.Triggers>
</Style>

W tym przypadku nasz trigger reaguje na zmiany właściwości Text. Jako, że nie ustawiliśmy źródła bindowania, właściwość Text będzie wyszukiwana w DataContext danej kontrolki. W przypadku gdy DataContext nie zostanie ustawiony, właściwość ta będzie wyszukiwana w kontrolce będącej wyżej w hierarchii. W przypadku gdy wartość właściwości Text będzie wynosiła Kolor tło kontrolki zostanie zmienione na kolor beżowy.

3. MultiData triggers

Oto przykład wykorzystania MultiDataTriggera. W ResourceDictionary tworzymy styl, który zostanie przypisany do przycisku.

<Style x:Key="MultiDataTrigger" TargetType="{x:Type Button}">
    <Style.Triggers>
        <MultiDataTrigger>
            <MultiDataTrigger.Conditions>
                <Condition Binding="{Binding Path=Text}" Value="Kolor"/>
                <Condition Binding="{Binding Path=Title}" Value="Spider-Man"/>
            </MultiDataTrigger.Conditions>
            <Setter Property="Background" Value="Black"/>
        </MultiDataTrigger>
    </Style.Triggers>
</Style>

Tym razem nasz trigger zareaguje, tylko i wyłącznie gdy wartość właściwości Text(znajdującej się w DataContext) będzie równe Kolor, oraz wartość właściwości Title będzie równa Spider-Man. W chwili gdy warunek ten zostanie spełniony, tło kontrolki zmieni się na kolor czarny.

4. MultiTrigger

Zasada działania MultiTriggera jest analogiczna z zasadą działania MultiDataTriggera. Różnica między ni mi jest taka, że w MultiTriggerze możemy jedynie odnosić się do propertisów danej kontrolki (kontrolki dla której styl tworzymy,oraz kontrolek wchodzących w skład naszej kontrolki). Przykładowy kod MultiTriggera może wyglądać w następujący sposób:

<Style x:Key="MultiTrigger" TargetType="{x:Type Button}">
    <Style.Triggers>
        <MultiTrigger>
            <MultiTrigger.Conditions>
                <Condition Property="Background" Value="Black"/>
                <Condition Property="IsMouseOver" Value="True"/>
            </MultiTrigger.Conditions>
            <Setter Property="Content" Value="MultiTrigger"/>
        </MultiTrigger>
    </Style.Triggers>
</Style>

Tym razem nasz trigger zareaguje, tylko i wyłącznie gdy tło naszej kontrolki będzie czarne, oraz kursor myszy będzie znajdował się nad przyciskiem. W chwili gdy warunki ten zostaną spełnione, napis na przycisku zmieni się na MultiTrigger

5. Event triggers

Event triggery wykraczają poza zakres tej części tutoriala, gdyż są one ściśle związane z animacjami.

Style

Sun, 27 Nov 2011 17:41:00 GMT

Style jest to mechanizm wprowadzony w WPF-ie, a następnie w Silverlighcie, dzięki któremu w łatwy sposób można ujednolicić wygląd elementów naszej aplikacji. Style z reguły definiowane są w zasobach. Mogą to być zarówno zasoby całej aplikacji, danego okna lub nawet wybranej kontrolki. Przykładowy styl może wyglądać w następujący sposób:

<Style x:Key="przycisk">
    <Setter Property="Button.FontSize" Value="22" />
    <Setter Property="Button.Background" Value="Orange" />
    <Setter Property="Button.Width" Value="60" />
</Style>

Każdy styl jest rozpoznawany dzięki unikalnemu kluczowi - parametr x:Key. Możliwe jest pominięcie klucza, w przypadku gdy ustawiona zostanie właściwść TargetType. Jednakże zdefiniowanie właściwości TargetType spowoduje, że dany styl będzie automatycznie zastosowany do wszystkich kontrolek danego typu. W przypadku gdybyśmy jednak chcieli wyłączyć dany styl dla pojedynczej kontrolki możemy zawsze przypisać mu wartość x:Null.

Jak widać styl posiada kolekcję obiektów typu Setter. Najważniejszymi propertisami każdego Settera są:

Property - określa nazwę właściwości, którą dany styl będzie modyfikować,
Value - określa wartość właściwości określonej w elemencie Property

Dla przykładu - następujący styl:


<Style x:Key="przycisk">
    <Setter Property="Button.FontSize" Value="22" />
</Style>

ustawi rozmiar czcionki na buttonie na 22 pkt. Jako, że nie została ustawiona właściwość TargetType dla stylu, musimy podawać pełną nazwę właściwości(czyli nazwę klasy oraz nazwę właściwości). Oczywiście możemy również ustawiać bardziej skomplikowane właściwości

<Style TargetType{x:Type Button}>
    <Setter Property="RenderTransform">
        <Setter.Value>
            <SkewTransform CenterX=".5" CenterY=".5" AngleX="-10" AngleY="15" />
        </Setter.Value>
    </Setter>
</Style>

W przypadku gdybyśmy pisali w Silverlighcie właściwość TargetType ustawia się troszeczkę inaczej. Mianowicie zamiast TargetType{x:Type Button} piszemy TargetType{Button}

Właściwość TargetType określa nam dla jakiego typu obiektów(kontrolek) dany typ jest przeznaczony. Styl z pierwszego przykładu można zapisać następująco:

<Style  TargetType={x:Type Button}>
    <Setter Property="FontSize" Value="22" />
</Style>

Dzięki użyciu właściwości TargetType, kompilator wie, że dany styl jest przeznaczony dla Buttona, dlatego też możemy w Setterze użyć skróconej nazwy właściwości(FontSize zamiast Button.FontSize). Ponadto dzięki użyciu TargetType, możemy pominąć definiowanie klucza po jakim nasz styl będzie rozpoznawany. Od tej chwili wszystkie buttony będą renderowane z użyciem powyższego stylu (oczywiście jeżeli styl ten będzie w resourcach danej kontrolki).

Dziedziczenie styli

Style mogą być dziedziczone. Oznacza to tyle, że styl pochodny będzie rozszerzał styl bazowy. W przypadku gdy styl bazowy ma zdefiniowany TargetType, styl dziedziczący nie może go zmienić. W celu zdefiniowania dziedziczenia używa się właściwości BasedOn. Przykładowe dziedziczenie styli pokazano poniżej

<Style x:Key="baseStyle">
    <Setter Property="FontSize" Value="12" />
    <Setter Property="Background" Value="Orange" />
</Style>
<Style x:Key="boldStyle" BasedOn="{StaticResource baseStyle}">
    <Setter Property="FontWeight" Value="Bold" />
</Style>

W stylu dziedziczącym można przesłaniać właściwości ze stylu bazowego. W przypadku gdy nie zostaną one przesłonięte, użyte zostaną propertisy ze stylu bazowego. W celu zaaplikowania stylu do jakiejś kontrolki posługujemy się następującą składnią

<Button Style="{StaticResource myStyle}"></Button>

myStyle - klucz stylu zdefiniowanego w zasobach.

Commands - czyli interakcja widoku z ViewModelem cz.2

Sun, 27 Nov 2011 16:05:00 GMT

Tak jak wspomniałem w poprzednim wpisie, tym razem zajmiemy się tworzeniem własnej klasy implantującej interfejs ICommand.

1. Implementacja interfejsu `ICommand` - `WPF`

Klasa implementująca ICommand może wyglądać w następujący sposób

public class DelegateCommand : ICommand
{
    private Action<object> execute;
    private Func<object, bool> canExecute;
    
    public event EventHandler CanExecuteChanged
    {
        add
        {
            CommandManager.RequerySuggested += value;
        }
        remove
        {
            CommandManager.RequerySuggested -= value;
        }
    }
    
    public DelegateCommand(Action<object> execute, Func<object, bool> canExecute)
    {
        this.execute = execute;
        this.canExecute = canExecute;
    }
    
    public bool CanExecute(object parameter)
    {
        if (canExecute == null) return true;
        return canExecute(parameter);
    }
    
    public void Execute(object parameter)
    {
        if (execute == null) return;
        execute((object)parameter);
    }
}

Klasa DelegateCommand przyjmuje w konstruktorze dwa parametry - delegaty do funkcji. Pierwszy z nich jest to delegat do funkcji, która ma się wykonać, gdy komenda może zostać wykonana. Drugi natomiast jest to delegat do funkcji, która sprawdza czy dana komenda może zostać wykonana. Ważnym elementem jest tutaj następujący kawałek kodu:

public event EventHandler CanExecuteChanged
{
    add
    {
        CommandManager.RequerySuggested += value;
    }
    remove
    {
        CommandManager.RequerySuggested -= value;
    }
}

który podłącza naszą klasę do WPF-owego systemu komend.

Teraz wystarczy w ViewModelu stworzyć obiekt typu DelegateCommand przekazać do niego odpowiednie funkcje, a następnie zbindować go do widoku. Może to wyglądać w następujący sposób:

ViewModel

public ICommand AddCommand { get; set;}

public WatchListViewModel()
{
    AddCommand = new DelegateCommand(val => Add(), val => CanAdd());
}

Widok (XAML)

<Button Command="{Binding AddCommand}"/>

2. Implementacja interfejsu `ICommand` `Silverlight`

Przedstawiony powyżej przykład skompiluje się jedynie w aplikacji WPF-owej. Silverlight niestety nie posiada CommandManagera, dlatego też gdy chcemy używać komend właśnie w tej technologii musimy zmodyfikować nasz kod na następujący:

public class DelegateCommand : ICommand
{
    public event EventHandler CanExecuteChanged;
    private Action<object> execute;
    private Func<object, bool> canExecute;
    private bool previousState;
    
    public DelegateCommand(Action<object> execute, Func<object, bool> canExecute)
    {
        this.execute = execute;
        this.canExecute = canExecute;
    }
    
    public DelegateCommand(Action<object> execute)
    {
        this.execute = execute;
    }
    
    public bool CanExecute(object parameter)
    {
        if (canExecute == null) return true;
        bool currentState = canExecute((object)parameter);
        if (currentState != previousState)
        {
            previousState = currentState;
            if (CanExecuteChanged != null)
                CanExecuteChanged(this, EventArgs.Empty);
            return currentState;
        }
        return currentState;
    }
    
    public void Execute(object parameter)
    {
        if (execute == null) return;
        execute((object)parameter);
    }
    
    public void RaiseCanExecute()
    {
        if (CanExecuteChanged != null)
            CanExecuteChanged(this, EventArgs.Empty);
    }
}

Jak widać w funkcji

public bool CanExecute(object parameter)

sami musimy zadbać o wywołanie zdarzenie

public event EventHandler CanExecuteChanged;

Ponadto dopisana została funkcja

public void RaiseCanExecute()

funkcję tą musimy wywoływać zawsze gdy zmieni się jakaś właściwość, która ma mieć wpływ na stan przycisku zbindowanego do naszej komendy.

3. Przykład

Załóżmy, że na widoku mamy przycisk edytuj, który powinien być aktywny tylko i wyłącznie wtedy, gdy zaznaczono jakiś element na gridzie. Przycisk ten jest zbindowany do komendy EditCommand. Jak już wcześniej wspomniano, z powodu braku w Silverlighcie CommandManagera sami musimy wywołać zdarzenie informujące o potrzebie zmiany stanu przycisku. Dlatego też, w ViewModelu została stworzona właściwość SelectedItem

public Department SelectedItem
{
    get { return selectedItem; }
    set
    {
        selectedItem = value;
        NotifyPropertyChanged(() => SelectedItem);
        EditCommand.RaiseCanExecute();
    }
}

która reaguje na zmiany zaznaczenia na gridzie. W chwili, gdy zaznaczenie się zmienia, wywoływany jest seter z tej właściwości, w którym to wywołujemy funkcję EditCommand.RaiseCanExecute. Dzięki czemu informujemy kontrolkę o ewentualnej potrzebie zmiany jej stanu.

4. Podsumowanie

Komendy w bardzo prosty i wygodny sposób pozwalają nam wywoływać metody bezpośrednio z ViewModelu. Niestety mają one również swoje ograniczenia:

reagują jedynie na zdarzenie Click,
można je wykorzystać jedynie na kontrolkach dziedziczących po klasie ButtonBase oraz kontrolkach typu MenuItem

Commands - czyli interakcja widoku z ViewModelem cz.1

Sun, 27 Nov 2011 15:21:00 GMT

1. Wstęp

Każdy programista, który napisał chociaż parę linijek kody w WinFormsach wie, że kontrolki używają eventów do powiadamiania o zmianach swojego stanu. W przypadku, gdy interesuje nas odpowiednia reakcja na zdarzenie, podpinamy się do niego odpowiednią funkcją i wykonujemy założone przez nas operację. W analogiczny sposób można postępować w WPF-ie oraz w Silverlighcie, jednakże podejście takie niejako mija się z modelem MVVM. Posiadanie event handlerów w kodzie, ściśle wiąże nam widok (XAML) z code behind lub nawet z samym ViewModelem danego widoku. Ponadto używanie eventów jest problematyczne (a właściwie niemożliwe), gdy widoki zostaną zdefiniowane w Resourcach. Dodatkową wadą używania event handlerów jest fakt, że aplikacje w których widok jest mocno związany z codebehind nie należą do aplikacji, które w łatwy sposób można poddać testom automatycznym.

2. Interfejs `ICommand`

W celu rozluźnienia połączenia między widokiem a ViewModelem wprowadzono interfejs

public interface ICommand
{  
    event EventHandler CanExecuteChanged;    
    bool CanExecute(object parameter);    
    void Execute(object parameter);
}

Funkcja

public bool CanExecute(object parameter)

ma za zadanie sprawdzić, czy daną komendę można wykonać. Jeżeli nie,funkcja zwraca false i kontrolka zbindowana do danej komendy jest wygaszana (właściwość IsEnabled danej kontrolki ustawiana jest na false). Z kolei funkcja

public void Execute(object parameter)

jest to odpowiednik event handlera podłączonego do zdarzenia. Zdarzenie

public event EventHandler CanExecuteChanged;

informuje widok o tym czy dana komenda może się wykonać czy też nie - dzięki temu kontrolka wie kiedy się odświeżyć(zmienić wartość właściwości IsEnabled).

3. Sposób użycia

Załóżmy, że mamy okno na którym znajduje się przycisk. Po naciśnięciu przycisku chcielibyśmy aby wykonała się jakaś czynność. Każdy obiekt typu Window oraz Control posiada kolekcję CommandBindings, która przechowuje wszystkie komendy danego okna. W celu dodania nowej komendy należy zrobić następującą rzecz. Po pierwsze musimy stworzyć nową komendę. Robimy to przy pomocy następującego kodu:

private static RoutedCommand AddCommand = new RoutedCommand();

W celu dodania komendy do danego okna/kontrolki wykonujemy następującą operację

this.CommandBindings.Add(new CommandBinding(AddCommand,ExecuteAddCommand,CanExecuteAddCommand));

Funkcja Add z klasy CommandBindingCollection przyjmuje w parametrze obiekt typu CommandBinding. Konstruktor takiego obiektu składa się z trzech parametrów:

RoutedCommand - obiekt typu RoutedCommand
delegat typu ExecutedRoutedEventHandler - jest to delegat do funkcji, która ma się wykonać w przypadku gdy dana komenda spełnia warunki do “uruchomienia”
delegat typu CanExecuteRoutedEventHandler - jest to delegat do funkcji, która sprawdza czy daną komendę można wykonać. W celu zabronienia wykonania komendy należy ustawić argument ExecutedRoutedEventArgs CanExecute na false.

Na koniec należy jeszcze zbindować naszą komendę z przyciskiem. Przykładowy kod dodawania komendy może wyglądać w następujący sposób.

public partial class WatchList : Window
{
    private static RoutedCommand AddCommand = new RoutedCommand();
    
    public WatchListViewModel viewModel = new WatchListViewModel();
    
    public WatchList()
    {  
        InitializeComponent();
        this.CommandBindings.Add(new CommandBinding(AddCommand, ExecuteAddCommand, CanExecuteAddCommand));
    }
    
    private void CanExecuteAddCommand(object sender, CanExecuteRoutedEventArgs e)
    {
        e.CanExecute = viewModel.CanAdd();
    }
    
    private void ExecuteAddCommand(object sender, ExecutedRoutedEventArgs args)
    {
        viewModel.Add();
    }
}

Bindowanie w przycisku do komendy może wyglądać w następujący sposób

<Button {x:Static local:WatchList.AddCommand}></Button>

gdzie local jest aliasem na namespace, w którym znajduje się okno.

4. Podsumowanie

Użycie komend w pewnym stopniu oddzieliło nam widok od codebehind-a, jednakże wciąż nie jest to rozwiązanie idealne. Z codebehind-a wywołujemy metody ViewModelu, więc niejako ciągle jesteśmy bezpośrednio zależni od widoku. W części drugiej zaprezentuję w jaki sposób można stworzyć własny obiekt implementujący interfejs ICommand, dzięki czemu ograniczymy do minimum ilość kodu pisanego w codebehind.

INotifyPropertyChanged oraz Expresssion Trees

Sun, 27 Nov 2011 10:24:00 GMT

Interfejs INotifyPropertyChangedPropertyChanged znany jest prawdopodobnie każdemu programiście C#. Interfejs ten zawiera jedynie jedno zdarzenie

public event PropertyChangedEventHandler PropertyChanged;

które powinniśmy odpalić w momencie gdy dana właściwość zostanie przez nas zmieniona. Dzięki temu dowolny obiekt, który będzie nasłuchiwał zmian danej właściwości zostanie o tym poinformowany. Przykładowa klasa implementująca ten interfejs może wyglądać w następujący sposób:

public class ViewModelBase : INotifyPropertyChanged
{
    public event PropertyChangedEventHandler PropertyChanged;
    public void NotifyPropertyChanged(string propertyName)
    {
        if (PropertyChanged != null)
            PropertyChanged(this, new PropertyChangedEventArgs(propertyName));
    }
    
    private string viewModelName;
    public string ViewModelName
    {
        get { return viewModelName; }
        set
        {
            viewModelName = value;
            NotifyPropertyChanged("ViewModelName");
        }
    }
}

Jak widać została stworzona funkcja pomocniczna

public void NotifyPropertyChanged(string propertyName)

którą wywołujemy w setterze danej właściwości, podając w parametrze nazwę tej właściwości. Niestety podejście takie jest bardzo podatne na błędy. Po pierwsze bardzo łatwo można przekręcić nazwę właściwości, a co gorsze rozwiązanie takie nie jest uwzględniane podczas refactoringu. Dlatego też w celu poprawienia naszego rozwiązania skorzystamy z mechanizmów dostarczanych przez Expression Trees. Po pierwsze zmieniamy funkcję

public void NotifyPropertyChanged(string propertyName)

public void NotifyPropertyChanged(Expression<Func<object>> propertyExpression)
{
    if(PropertyChanged == null) return;
    
    PropertyChanged(this, new PropertyChangedEventArgs(GetPropertyName(propertyName)));
}

funkcja pomocnicza GetPropertyName ma następującą postać

private string GetPropertyName(Expression<Func<object>> propertyExpression)
{
    var unaryExpression = propertyExpression.Body as UnaryExpression;
    var memberExpression = unaryExpression == null ? (MemberExpression)propertyExpression.Body : (MemberExpression)unaryExpression.Operand;
    var propertyName = memberExpression.Member.Name;
    return propertyName;
}

Teraz wystarczy prosty zapis

NotifyPropertyChanged(()=> ViewModelName)

który odwołuje się bezpośrednio do właściwości a nie jej nazwy. Dzięki temu kod w całości zostanie zrefaktoryzowany. Rozwiązanie to jest teoretycznie odrobinę wolniejsze od używania stringów, jednak w praktyce jest to niezauważalne. Można również funkcję

string GetPropertyName(Expression<Func<object>> propertyExpression)

wyciągnąc do osobnej klasy i zrobić z tej funkcji extension method.

public static string GetPropertyName(this object obj, Expression<Func<object>> propertyExpression)
{
    var unaryExpression = propertyExpression.Body as UnaryExpression;
    var memberExpression = unaryExpression == null ? (MemberExpression)propertyExpression.Body : (MemberExpression)unaryExpression.Operand;
    var propertyName = memberExpression.Member.Name;
    return propertyName;
}

Od teraz wystarczy, że zaimportujemy odpowiedni namespace i możemy wykorzystać naszą funkcję w każdej klasie.

tpodolak.com

ASP.NET Core - adding controllers directly from integration tests

1. Introduction

2. Accessing ApplicationPartManager from integration tests

3. Handling private controllers

Running ASP.NET Core together with Nancy

1. Introduction

2. Legacy API

3. Combining Nancy with ASP.NET Core

Introduce substitute refactoring comes to NSubstitute.Analyzers

.NET Core - missing currency symbol in docker alpine image

MongoDB.Driver - class-based server side projection

1. Introduction

2.Exploring existing options

3. Class-based server-side projection

Performance improvements in NSubstitute.Analyzers 1.0.11

1. Introduction

2. Benchmark comparision of NSubstitute.Analyzers.CSharp

3. Benchmark comparision of NSubstitute.Analyzers.VisualBasic

NSubstitute.Analyzers 1.0.0 released

Announcing NSubstitute.Analyzers (beta)

1. Introduction

2. Diagnostics

ASP.NET Web API 2 - missing swagger query parameters

Solution-wide project properties with Directory.Build.props

1. Problem

2. Solution

ASP.NET Core – custom ILogger and Nlog callsite layout renderer issue

1. Introduction

2. Implementation

3. NLog call site renderer issue

4. The fix

ASP.NET Core - make sure IOptions is initialized

1. Introduction

2. Problem

3. Ensuring initialization

ASP.NET Core - passing command-line arguments to Startup class

1. Introduction

2. ASP.NET Core 2.x

3. ASP.NET Core 1.x

ASP.NET Core - retrieving swagger specification without hosting API

1. Introduction

2. Implementation

Null-propagation operator and conditional statements

ASP.NET Core MemoryCache - GetOrCreate calls factory method multiple times

Finding typos with ReSharper Command Line Tools, ReSpeller and Cake

1. Introduction

2. First attempt

3. The workaround

4. Cake integration

ASP.NET Core 1.x - curios case of missing IOptions array item

1. Introduction

2. Problem

3. Solution

.NET Core - calculating code coverage with OpenCover (on Windows)

1. Introduction.

2. Working example.

3. Cake script.

ASP.NET Core – request serialization issues after migration from classic WebApi

NLog.Web.AspNetCore - make sure you add error message for logging exception

XUnit - MemberDataAttribute and generic type inheritance

1. Introduction.

2. Investigation.

3. Solution.

NSubstitute - returning value from IEnumerable

Dotnet CLI - running tests from multiple assemblies

ASP.NET Core - API versioning by convention

1. Introduction

2. Convention

3. Creating conventions.

4. Adding convention to application

ASP.NET Core - default API version with url path versioning

1. Introduction.

2. Default API version without url path versioning

3. Default Api version with URL path versioning

4. Adding default route with convention

VS Code - forcing partial IntelliSense support for Cake scripts

1. Introduction

2. Investigation

3. My approach

3. Combining Nancy with `ASP.NET Core`

3. `NLog` call site renderer issue

2. Default `API` version without url path versioning

5. Enabling `IntelliSense` in `VS Code`

3. Populating `IOptions<T>` from external data source