In this blog post we are going to be showing you can configure Azure Application Insights to send your logs, exceptions and performance metrics from a .NET 6 API.

Installation
Start by installing the Microsoft.ApplicationInsights.AspNetCore nugget package.

Now in your startup class you will need to configure some options for the telemetry collection.
You can use the AddApplicationInsightsTelemetry extension method on the IServiceCollection and pass your options as so:

public class Startup
{
    public virtual void ConfigureServices(IServiceCollection services)
    {
        services.AddApplicationInsightsTelemetry(GetApplicationInsightsServiceOptions());    
    }

    private static ApplicationInsightsServiceOptions GetApplicationInsightsServiceOptions()
    {
        return new ApplicationInsightsServiceOptions
        {
            AddAutoCollectedMetricExtractor = false,
            EnableEventCounterCollectionModule = false,
            EnableDiagnosticsTelemetryModule = false,
            EnablePerformanceCounterCollectionModule = true,
            EnableDependencyTrackingTelemetryModule = true,
            EnableRequestTrackingTelemetryModule = false,
            ConnectionString = Configuration[ConfigurationConstants.ApplicationInsightsConnectionString],
        };
    }
}

This is where we define the types of telemetry we want to collect.
The documention of the options are here: https://learn.microsoft.com/en-us/azure/azure-monitor/app/asp-net-core?tabs=netcorenew#use-applicationinsightsserviceoptions
We are also getting the connection string of the application insights resource from our appsettings.

Telemetry modules
Now if we want to go further, we can even specify what metrics to collect for each module.
For instance, let’s say we want to indicate which performance metrics to collect. Then you can do the following:

        services.ConfigureTelemetryModule<PerformanceCollectorModule>((module, applicationInsightsServiceOptions) =>
        {
            module.DefaultCounters.Add(new PerformanceCounterCollectionRequest(@"\Process(??APP_WIN32_PROC??)\Private Bytes", @"\Process(??APP_WIN32_PROC??)\Private Bytes"));
            module.DefaultCounters.Add(new PerformanceCounterCollectionRequest(@"\Process(??APP_WIN32_PROC??)\% Processor Time", @"\Process(??APP_WIN32_PROC??)\% Processor Time"));
        });

You can view the documentation on configuring telemetry modules here: https://learn.microsoft.com/en-us/azure/azure-monitor/app/asp-net-core?tabs=netcorenew#configure-or-remove-default-telemetrymodules

Extensibility
To add or remove properties from collected telemetry (before it gets sent to Azure) you can create classes that implement the ITelemetryInitializer class from the Azure Application Insights SDK (https://learn.microsoft.com/en-us/azure/azure-monitor/app/asp-net-core?tabs=netcorenew#add-telemetryinitializers).

A classic example for a telemetry initializer is a correlation id initializer. You would get a correlation id from your http request and pass it to all telemetry so that you can have a nice trace of everything that went through your system:

public class CorrelationIdInitializer : ITelemetryInitializer
{
    private readonly IHttpContextAccessor _httpContextAccessor;
    private const string CorrelationIdProperty = "CorrelationId";

    public CorrelationIdInitializer(IHttpContextAccessor httpContextAccessor)
    {
        _httpContextAccessor = httpContextAccessor;
    }

    public void Initialize(ITelemetry telemetry)
    {
        ISupportProperties telemetryProperties = (ISupportProperties)telemetry;

        // This is just an extension method where you would extract the correlation id from the request headers according to your header name.
        string correlationId = _httpContextAccessor.HttpContext.GetCorrelationId();

        if (!string.IsNullOrWhiteSpace(correlationId) && !telemetryProperties.Properties.ContainsKey(CorrelationIdProperty))
        {
            telemetryProperties.Properties.Add(CorrelationIdProperty, correlationId);
        }
    }

To register the telemetry initializer, simply register the class and its respective interface (always ITelemetryInitializer) on your service collection: services.AddSingleton<ITelemetryInitializer, CorrelationIdInitializer>();

Filtering
Additionally, you also have the ability to filter out telemetry from being collected. This is a great feature that allows you to focus only storing what you really care about and will save you a LOT of costs.
Do keep in mind that filtering out telemetry does mean that you won’t be able to query it and therefore can make your tracing a bit difficult.
This is all related to telemetry processors (https://learn.microsoft.com/en-us/azure/azure-monitor/app/asp-net-core?tabs=netcorenew#add-telemetry-processors).

Imagine you have thousands of fast dependencies (see the list of automatically tracked dependencies https://learn.microsoft.com/en-us/azure/azure-monitor/app/asp-net-dependencies#automatically-tracked-dependencies) that are being stored by your system but you come to a conclusion that they only make it hard to monitor your system and you don’t really need them.
Filtering them out is the way to go OR you could consider sampling instead https://learn.microsoft.com/en-us/azure/azure-monitor/app/asp-net-core?tabs=netcorenew#sampling.
Lets create a processor that filters out successful dependencies that had a duration under 500 milliseconds:

public class FastDependencyProcessor : ITelemetryProcessor
{
    private ITelemetryProcessor Next { get; set; }

    public FastDependencyProcessor(ITelemetryProcessor next)
    {
        Next = next;
    }

    public void Process(ITelemetry item)
    {
        if (!ShouldFilterTelemetry(item))
        {
            Next.Process(item);
        }
    }

    public bool ShouldFilterTelemetry(ITelemetry item)
    {
        bool shouldFilterTelemetry = false;

        DependencyTelemetry dependency = item as DependencyTelemetry;

        if (dependency != null
            && dependency.Duration.TotalMilliseconds < 500
            && dependency.Success.HasValue && dependency.Success.Value)
        {
            shouldFilterTelemetry = true;
        }

        return shouldFilterTelemetry;
    }
}

After creating the class, you have to register the telemetry processor as part of your service collection like so:
services.AddApplicationInsightsTelemetryProcessor<FastDependencyProcessor>();

Keep in mind that if your telemetry processors will be executed in the order in which you’ve called them in your register process.

Final notes

– Azure Application Insights is a great tool that gives you visibility on how your application is doing.
You can use the SDK to collect most telemetry automatically or you could even instrument specific scenarios manually by making use of the TelemetryClient instance (https://learn.microsoft.com/en-us/azure/azure-monitor/app/asp-net-core?tabs=netcorenew#how-can-i-track-telemetry-thats-not-automatically-collected).
– It is important to monitor your costs as it is easy to end up storing everything and not only what you need. So start by defining what you need to collect and what metrics will be relevant for you.
Then you can filter out the irrelevant data and from there on you could even create alerts from the data you collect, using Azure Monitor.
If you are trying out Application Insights on a test environment, you can even set a daily cap of X GB so that you control your spending. Simply navigate to the Azure Application Insights resource through the Azure Portal and click “Usage and estimated Costs” on the sidebar:

– From what I’ve seen so far, the collection of dependencies/exceptions can represent the majority of costs as you may have a lot of dependencies flowing through your system and because exceptions are a type of telemetry that occupies a lot of space. Filtering out irrelevant dependencies will definitely help.
As for exceptions, you may consider using the Result pattern instead of using exceptions for the normal control flow of your code. This also has the advantage of decreasing the impact on performance lead by exceptions to your application since you reduce the amount of exceptions thrown.

The post Configuring Azure Application Insights on a .NET 6 API appeared first on Blog IT.

Unit Tests, Integration Tests, and End-to-End Tests: What’s the Difference?

• Unit tests focus on testing individual units or components of your application in isolation. This type of test verifies whether the unit/component works correctly and adheres to its business logic.
• Integration tests aim to test multiple units or components together, ensuring that they interact properly. Integration tests can uncover issues related to data flow, communication between components, and external dependencies like databases.
• End-to-end (E2E) tests simulate a complete user scenario by testing the entire application from start to finish. E2E tests can help identify issues related to multiple components, external APIs, and user interfaces.

public class InMemoryDbAppFactory : WebApplicationFactory<Program>
{
    private readonly string _environment;

    public InMemoryDbAppFactory()
    {
        _environment = "IntegrationTests";
    }

    protected override void ConfigureWebHost(IWebHostBuilder builder)
    {
        Environment.SetEnvironmentVariable("ASPNETCORE_ENVIRONMENT", _environment);
        builder.UseEnvironment(_environment);
        builder.UseSetting("https_port", "8080");

        builder.ConfigureTestServices(services =>
        {
            services.RemoveAll<ITestRepository>();
            services.TryAddTransient<ITestRepository, TestRepositoryTest>();

            // Anonymous authentication
            services
                .AddAuthentication("Test")
                .AddScheme<AuthenticationSchemeOptions, TestAuthenticationHandler>("Test", options => { });
        });
    }
}

public static partial class ServiceCollectionExtensions
{
    public static IServiceCollection AddDbContexts(
        this IServiceCollection services,
        IConfiguration configuration,
        IWebHostEnvironment environment
    )
    {
        if (environment.IsEnvironment("IntegrationTests"))
        {
            var connDb = new SqliteConnection("DataSource=db;mode=memory;cache=shared");
            connDb.Open();
            services.AddDbContext<dbContext>(options => options.UseSqlite(connDb));
        }
        else
        {
            services.AddDbContext<dbContext>(
                options => options.UseSqlServer(configuration.GetConnectionString("ConnectionString")).UseExceptionProcessor(),
                ServiceLifetime.Scoped
            );
        }

        return services;
    }
}

[Collection("MemoryDbIntegrationTests")]
public class ApiTests : IClassFixture<InMemoryDbAppFactory>
{
    private readonly InMemoryDbAppFactory _factory;
    private readonly HttpClient _client;

    public ApiTests(InMemoryDbAppFactory factory)
    {
        _factory = factory;
        _client = factory.CreateClient();

        // Ensures a clean database before each test
        factory.ResetDb();
    }

    [Fact]
    public async Task GetList_Should_Return_List()
    {
        // Arrange

        // Act
        var response = await _client.GetAsync("/api/list");
        var content = await response.Content.ReadFromJsonAsync<IEnumerable<Dto>>();

        // Assert
        response.EnsureSuccessStatusCode(); // Status Code 200-299
        content.Should().NotBeNull();
        content.Should().HaveCount(2);
    }
}

Using an in-memory database for integration tests has both advantages and disadvantages:

Advantages:

• Faster test execution: In-memory databases provide quicker test execution times since the data is stored in memory instead of on disk. This can significantly improve your overall testing performance and help you find issues faster.
• Easy to set up and tear down: In-memory databases are easy to create, modify, and delete without the need for external dependencies or configuration changes. This makes it easier to write, run, and maintain your tests.
• Consistent test data: In-memory databases allow you to create a known set of data for your tests, ensuring that each test starts with the same initial conditions. This can help reduce the likelihood of inconsistent test results and make it easier to identify issues related to data flow or dependencies between tests.

Disadvantages:

• Limited scalability: In-memory databases have limited capacity and may not be suitable for testing large datasets or complex scenarios that require high levels of concurrency.
• Lack of realism: In-memory databases may not accurately represent the behavior or performance of a production database, especially when dealing with complex queries or data modification operations. This can make it difficult to identify issues related to database schema, indexing, and query optimization.
• Limited support for advanced features: using SQLite as our in memory database we don’t have support for multiple schemas and some advanced query features.
• Seed data: the need to create seed data can be tedious and time consuming.

When deciding whether to use an in-memory database, mock data, or a real web server in memory for your integration tests, consider the specific requirements of your project and weigh the advantages and disadvantages of each approach. In many cases, using a combination of testing types and approaches can help you ensure the stability, reliability, and performance of your .NET WebAPI application.

The post Integration Tests in .NET WebApi appeared first on Blog IT.

Every value seems correct, but the error is definitely pointing us here. Here’s a simplified version of the offending line:

Console.Writeline(AConfig.ASubConfig);

And the corresponding appsettings:

{
    "AConfig" : {
        "ASubConfig" : []
    }
}

“But an empty array is not the same as a null value! And even if it was, it’s a value inside the “ASubConfig” property! There’s no way for this to be null!” was what I thought. And I thought wrong.

How the file is actually parsed

Actually, there’s a way for it to be null. Or at least, the JSON Provider which is gonna look at ours JSONs thinks so. Since .NET’s config system is ready to take in different providers, it was built with the common points of said providers in mind… And hierarchies aren’t one of those points.

What happens is that the JSON Provider’s parser is going to look at our JSON file and it’s going to map all those informations to a dictionary, in which every value is mapped with a key which corresponds to the path to that value in the file.

The “gotcha” here is in the way the arrays are processed: Each index of each array is processed as a part of the path. Meaning, that the following appsettings:

{
    "AnArray" : ["AThing", "AnotherThing", "AThirdThing"]
}

Will originate a dictionary with the following entries:

• AnArray:0 = “AThing”
• AnArray:1 = “AnotherThing”
• AnArray:2 = “AThirdThing”

Why do empty arrays cause an issue?

What happens if the array is empty? Well, by convention, an empty array wont originate any entries in our dictionary… So, to the .NET binder which is gonna look at our dictionary, that array doesn’t exist at all.

Even moreso, as there is no value inside that array which we can map to some path, every object on top of it in the hierarchy won’t have any value we can map either, meaning those objects won’t exist themselves (assuming they don’t have any other properties with not null values).

In practice, our dictionary will be empty, our .NET binder won’t be able to map anything, and the number of “WTH”s per second will spike before lunch time.

TLDR: .NET’s config system treats any object in appsettings.json that does not have any value associated with it’s properties as if it didn’t exist, and the same happens if that value is an empty array.

If anyone wants to read more on this, here’s a link for the github issue where I found most of this information:

https://github.com/dotnet/extensions/issues/1341

Happy coding everyone!

The post TWIL: The weird way .NET’s config system parses JSONs appeared first on Blog IT.

Let’s say we have the following table Documents:

CREATE TABLE [dbo].[Documents](
    [Id] [integer] PRIMARY KEY,
    [UserId] [integer] NOT NULL,
    [Title] [nvarchar](50) NOT NULL,
    [Body] [nvarchar](250) NOT NULL,
    [CreatedOn] [datetime] NOT NULL
)

and that we want to get the two most recent documents for each user. For instance, if we have the following records:

the query should return

To do this query using EF Core and LINQ we can try to group the Documents by UserId and then sort each group by the CreatedOn column to pick the first two documents for each user.

We can start by trying to group all documents for each user

 var usersDocs = await ctx
        .Documents
        .GroupBy(doc => doc.UserId)

and then for each group we try to sort its elements by the CreatedOn column

    var usersDocs = await ctx
        .Documents
        .GroupBy(doc => doc.UserId)
        .SelectMany(userDocs => userDocs.OrderByDescending(doc => doc.CreatedOn).Take(2))
        .ToArrayAsync();

If we try to execute this query using a previous version of EF Core 6 we get the following error:

    .OrderByDescending(doc => doc.CreatedOn)' could not be translated. Either rewrite the query in a form that can be translated, or switch to client evaluation explicitly by inserting a call to 'AsEnumerable', 'AsAsyncEnumerable', 'ToList', or 'ToListAsync'. See https://go.microsoft.com/fwlink/?linkid=2101038 for more information.'

This is because the previous versions of EF don’t know how to translate the GroupBy inner expressions to sql. After following their suggestion I ended up with this query

    var usersDocs = await ctx
        .Documents
        .Select(doc => doc.UserId)
        .Distinct()
        .SelectMany(userId => 
            ctx
            .Documents
            .Where(doc => doc.UserId == userId)
            .OrderByDescending(doc => doc.CreatedOn)
            .Take(2)
        )
        .ToArrayAsync();

However this query has two main issues. It does a distinct over the UserId column, loads all the user ids to application memory and then it does a query for each user resulting in a n+1 query problem.

One way to solve these issues is to forget LINQ and rewrite the query using raw sql with a partition by UserId and the ROW_NUMBER() window funtion, doing a CTE .

Now, with the EF Core 6 we can use the first version of the query, since the EF Core team has added the support for translating some GroupBy inner expressions and it can translate this LINQ query to a single sql query.

    var usersDocs = await ctx
        .Documents
        .GroupBy(doc => doc.UserId)
        .SelectMany(userDocs => userDocs.OrderByDescending(doc => doc.CreatedOn).Take(2))
        .ToArrayAsync();

You can read more about these features and other improvements added to GroupBy queries here and check the related github issues 12088 13805 

Happy coding!

The post .NET EF Core 6 support for groupby top(n) queries appeared first on Blog IT.

Both use https and I want the main site, which uses the primary domain, to only be accessible through it’s www version. For the second site, since it’s a sub-domain, I only want it to only be available in https.

Let’s say the domain is mydomain.com and the subdomain is mysub.mydomain.com. The only URLs I want to be available are:

• https://www.mydomain.com
• https://mysub.mydomain.com

Typically I would make the non-www to www redirection through the DNS provider, but for this website it was not possible.

The following is the configuration I used in my Web.config:

<rewrite>
    <rules>
        <rule name="Redirect from non www mydomain.com" stopProcessing="true">
            <match url=".*" />
            <conditions>
                <add input="{HTTP_HOST}" pattern="^mydomain.com$" />
            </conditions>
            <action type="Redirect" url="https://www.mydomain.com/{R:0}" redirectType="Permanent" />
        </rule>
        <rule name="Redirect from non https mydomain.com" stopProcessing="true">
            <match url=".*" />
            <conditions>
                <add input="{HTTPS}" pattern="^OFF$" />
                <add input="{HTTP_HOST}" pattern="^www.mydomain.com$" />
            </conditions>
            <action type="Redirect" url="https://www.mydomain.com/{R:0}" redirectType="Permanent" />
        </rule>
        <rule name="Redirect from non https mysub.mydomain.com" stopProcessing="true">
            <match url=".*" />
            <conditions>
                <add input="{HTTPS}" pattern="^OFF$" />
                <add input="{HTTP_HOST}" pattern="^mysub.mydomain.com$" />
            </conditions>
            <action type="Redirect" url="https://mysub.mydomain.com/{R:0}" redirectType="Permanent" />
        </rule>
    </rules>
</rewrite>

Hope this helps!

The post Redirecting 2 domains from http to https and non-www to www appeared first on Blog IT.

From the get-go there were some challenges we needed to overcome in order to create an usable system, that was user-friendly, fast, reliable, and where no conflitcts would come up when data was being updated from multiple users.

The solution was a new Umbraco Package we called Search Manager (since the database tables ultimately feed an Azure Search index) that uses Telerik’s Kendo UI Grid, WebAPI and Entity Framework. The following presents the process it took to reach the end result.

Step 1

We created a simple Umbraco Package that implemented a Kendo UI Grid which got its data from a WebAPI method that returned all rows from a table using Petapoco.

This allowed us to have the complete table data in memory using a Kendo UI Grid. It worked great but had major problems:

• A table with around 40k rows was actually a 40 MBs json download in order to populate the grid
• Users could be working with outdated data, since it was loaded in memory and changes could have been made to the source

Step 2

We started using the server paging feature of the Kendo Grid. This dropped the download size greatly, but we still had problems:

• Even though we are working with only a subset of results client-side, we were still getting the complete table data server-side, using petapoco.

We needed an easy way to translate the client-side queries, such as filters, paging, order, etc to SQL queries.

Step 3

We changed the type of queries being generated by the Grid to OData. Using the OData WebAPI nuget package we are able to map the odata query  to a C# object and then directly apply the query to any IQueryable data.

Petapoco does not provide any IQueryable data support, so we changed our ORM to Entity Framework, which does, and voilá!

Finally

With everything in place, we are able to have a filtered subset of results in a Grid, that gets exactly what it needs to display from a dynamically generated SQL query.

• It is fast because we only get exactly what we need:

An OData query generated by the Kendo UI Grid looks like this:

http://localhost:14231/umbraco/backoffice/SearchManager/PricesApi/Read?%24inlinecount=allpages&%24top=20&%24skip=40&%24orderby=ProviderName+desc&%24filter=(NatureProcCode+eq+%27exames%27+and+AvgAmtClaimed+gt+10)

Which is translated to the follwing SQL query:

exec sp_executesql N'SELECT 
    [Project1].[Approved] AS [Approved], 
    [Project1].[DiffWeightedRate] AS [DiffWeightedRate], 
    [Project1].[SubmitPrvId] AS [SubmitPrvId], 
    [Project1].[PracticeSeq] AS [PracticeSeq], 
    [Project1].[NatureProcCode] AS [NatureProcCode], 
    [Project1].[GroupProcCode] AS [GroupProcCode], 
    [Project1].[Network] AS [Network], 
    [Project1].[AmtClaimedWeighted] AS [AmtClaimedWeighted], 
    [Project1].[ManualPrice] AS [ManualPrice], 
    [Project1].[IsImported] AS [IsImported], 
    [Project1].[DiffCalculatedRate] AS [DiffCalculatedRate], 
    [Project1].[AmtContract] AS [AmtContract], 
    [Project1].[AvgAmtClaimed] AS [AvgAmtClaimed], 
    [Project1].[ProviderName] AS [ProviderName], 
    [Project1].[ClinicName] AS [ClinicName]
    FROM ( SELECT 
        [Extent1].[Approved] AS [Approved], 
        [Extent1].[DiffWeightedRate] AS [DiffWeightedRate], 
        [Extent1].[SubmitPrvId] AS [SubmitPrvId], 
        [Extent1].[PracticeSeq] AS [PracticeSeq], 
        [Extent1].[NatureProcCode] AS [NatureProcCode], 
        [Extent1].[GroupProcCode] AS [GroupProcCode], 
        [Extent1].[Network] AS [Network], 
        [Extent1].[AmtClaimedWeighted] AS [AmtClaimedWeighted], 
        [Extent1].[ManualPrice] AS [ManualPrice], 
        [Extent1].[IsImported] AS [IsImported], 
        [Extent1].[DiffCalculatedRate] AS [DiffCalculatedRate], 
        [Extent1].[AmtContract] AS [AmtContract], 
        [Extent1].[AvgAmtClaimed] AS [AvgAmtClaimed], 
        [Extent1].[ProviderName] AS [ProviderName], 
        [Extent1].[ClinicName] AS [ClinicName]
        FROM (SELECT 
    [PriceGrid].[Approved] AS [Approved], 
    [PriceGrid].[DiffWeightedRate] AS [DiffWeightedRate], 
    [PriceGrid].[SubmitPrvId] AS [SubmitPrvId], 
    [PriceGrid].[PracticeSeq] AS [PracticeSeq], 
    [PriceGrid].[NatureProcCode] AS [NatureProcCode], 
    [PriceGrid].[GroupProcCode] AS [GroupProcCode], 
    [PriceGrid].[Network] AS [Network], 
    [PriceGrid].[AmtClaimedWeighted] AS [AmtClaimedWeighted], 
    [PriceGrid].[ManualPrice] AS [ManualPrice], 
    [PriceGrid].[IsImported] AS [IsImported], 
    [PriceGrid].[DiffCalculatedRate] AS [DiffCalculatedRate], 
    [PriceGrid].[AmtContract] AS [AmtContract], 
    [PriceGrid].[AvgAmtClaimed] AS [AvgAmtClaimed], 
    [PriceGrid].[ProviderName] AS [ProviderName], 
    [PriceGrid].[ClinicName] AS [ClinicName]
    FROM [dbo].[PriceGrid] AS [PriceGrid]) AS [Extent1]
        WHERE ([Extent1].[NatureProcCode] = @p__linq__0) AND ([Extent1].[AvgAmtClaimed] > @p__linq__1)
    )  AS [Project1]
    ORDER BY [Project1].[ProviderName] DESC, [Project1].[AmtClaimedWeighted] ASC, [Project1].[AmtContract] ASC, [Project1].[Approved] ASC, [Project1].[AvgAmtClaimed] ASC, [Project1].[ClinicName] ASC, [Project1].[DiffCalculatedRate] ASC, [Project1].[DiffWeightedRate] ASC, [Project1].[GroupProcCode] ASC, [Project1].[IsImported] ASC, [Project1].[ManualPrice] ASC, [Project1].[NatureProcCode] ASC, [Project1].[Network] ASC, [Project1].[PracticeSeq] ASC, [Project1].[SubmitPrvId] ASC
    OFFSET @p__linq__2 ROWS FETCH NEXT @p__linq__3 ROWS ONLY  option (Recompile)',N'@p__linq__0 varchar(8000),@p__linq__1 decimal(2,0),@p__linq__2 int,@p__linq__3 int',@p__linq__0='exames',@p__linq__1=10,@p__linq__2=40,@p__linq__3=20

• It’s user-friendly and reliable because users can filter the data as if they were using an excel file on steroids
• It avoids conflicts because we only get a subset of the results each time and each change is commited in a single transaction

Code samples:

grid = $("#grid").kendoGrid({
                dataSource: new kendo.data.DataSource({
                    transport: transport,
                    schema: schema,
                    serverFiltering: true,
                    serverPaging: true,
                    serverSorting: true,
                    type: "odata",
                    pageSize: 20
                }),
                dataBound: onDataBound,
                pageable: true,
                filterable: true,
                sortable: true,
                scrollable: false,
                navigatable: true,
                resizable: true,
                batch: true,
                columnMenu: true,
                editable: true,
                toolbar: [
					{ template: '<a class="k-button k-button-icontext k-grid-save-batch" href="\\#""><span class="k-icon k-i-update"></span>Guardar Alterações</a>' },
					{ name: "cancel", text: "Cancelar" },
                ],
                columns: [...]
            });

[HttpGet]
        public IHttpActionResult Read(ODataQueryOptions<PriceGrid> opts)
        {
            Mapper.CreateMap<PriceGrid, PriceGridBO>();

            using (var context = new EntitiesContext())
            {
                using (var qh = new HintScope(context, QueryHintType.Recompile))
                {
                    List<PriceGrid> results = opts
                        .ApplyTo(context.PriceGrids)
                        .Cast<PriceGrid>()
                        .ToList();

                    List<PriceGridBO> boEntities = results.Select(x => Mapper.Map<PriceGrid, PriceGridBO>(x)).ToList();

                    PriceResponse response = new PriceResponse()
                    {
                        Entities = boEntities,
                        Total = Request.ODataProperties().TotalCount.HasValue ? Request.ODataProperties().TotalCount.Value : 0
                    };

                    return Ok(response);
                }
            }
        }

The post KendoUI Grid, OData, WebAPI and Entity Framework appeared first on Blog IT.

ASP.NET doesn’t provide a native way of donut output caching, so we must resort to a great NuGet package called MVCDonutCaching. You can read all about it here: http://www.devtrends.co.uk/blog/donut-output-caching-in-asp.net-mvc-3.

Since Umbraco is built on top of ASP.NET MVC, we can easily use this package on our websites. There are, however, some caveats, because Umbraco doesn’t use the native MVC routing.

For Umbraco, every page that uses the same document type is processed through the same route, therefore, if we have 100 news articles that use the NewsItem document type, from the moment we open one news article page, every other news item page will display the same information, despite having a different URL!

The way to bypass this issue is the following:

Create a Global.cs file that includes the logic to cache a page based on their url and not the document type

namespace CreateIT.Web
{
    using System;
    using System.Collections.Generic;
    using System.Linq;
    using System.Web;
    using Umbraco.Web;

    public class Global : UmbracoApplication
    {
        public override string GetVaryByCustomString(HttpContext context, string custom)
        {
            if (custom.ToLower() == "url")
            {
                return "url=" + context.Request.Url.AbsoluteUri;
            }

            return base.GetVaryByCustomString(context, custom);
        }
    }
}

Then, instruct Umbraco to use this class when launching the UmbracoApplication by changing the Global.asax file:

<%@ Application Codebehind="Global.cs" Inherits="CreateIT.Web.Global" Language="C#" %>

Finally, setup an Output Cache profile in your Web.config:

<system.web>
    (...)
    <caching>
      <outputCacheSettings>
        <outputCacheProfiles>
          <add enabled="true" name="CreateIT.Actions" duration="900" location="Server" varyByCustom="url" varyByParam="*" />
        </outputCacheProfiles>
      </outputCacheSettings>
    </caching>
</system.web>

And decorate the chosen controllers (that you used to hijack the Umbraco routes) with the Donut Output Cache attribute:

[DonutOutputCache(CacheProfile = "CreateIT.Actions")]
public class HomepageController : Umbraco.Web.Mvc.RenderMvcController
{

If you wish to exclude a certain part of your page from the cache, just create a Surface Controller action that returns a partial view and use the extension method provided by MVCDonutCaching for @Html.Action().

The post Umbraco and Donut Output Cache appeared first on Blog IT.

If you need to find which part of your Umbraco application is slowing the site down, follow these steps:

1. Set the debug property of the compilation section of your Web.config to true: <compilation defaultLanguage=”c#” debug=”true” batch=”false” targetFramework=”4.5″>
   • If you’re using an older version of Umbraco, you also probably need to set the umbracoDebugMode app setting to true in the same config file: <add key=”umbracoDebugMode” value=”true” />
2. Add the query string ?umbdebug=true to your Umbraco page URL
3. Thats it!

It uses Mini Profiler, so you can add your own profile stops, but out-of-the-box it already analyses the time it takes to render each view.

Happy profiling!

The post Umbraco profiler appeared first on Blog IT.

The Visual Studio resx editor was slow and using it to change resources that were more than a single line of text was a pain. I still have nightmares where I’m trying to edit complete email templates on a single field of a resx file…

The biggest problem with resource files, however, is that they are included in the project. This creates a problem for both the developers and the content managers, since the content managers are not able to change resources themselves, and the developers need to be changing resources files when they could be doing something productive.

The following will show a way to handle resource items in a MVC website project, where the resources can be stored wherever they are more easily handled by content managers: a SharePoint list, a database table, an excel file, or something completely different.

The process is really simple:

1. Select every resource item key needed to render the current page
2. Fetch the resources associated with the keys provided at the end of the current action
3. Populate a ViewModel property with the resource items
4. Use the resource items in their respective places in the markup

1 – Compile a list of resource keys

Typically in a website, there are certain areas of the layout that are common across all pages, the header and the footer being the most prominent candidates. There are, however, other areas that can be reused across a smaller subset of pages such as a common banner in the FAQ pages. Taking this into account, we split the resource keys by groups, where each group (a list of strings) contains every resource key needed for that area and load them on each action, like so:

model.ContentResourceKeys = new List<string>();
model.ContentResourceKeys.AddRange(ResourceHelper.SOCIALNETWORK_RESOURCE_KEYS);
model.ContentResourceKeys.AddRange(ResourceHelper.HOTEL_BANNER_RESOURCE_KEYS);
model.ContentResourceKeys.AddRange(ResourceHelper.DOCUMENTS_RESOURCE_KEYS);
model.ContentResourceKeys.AddRange(ResourceHelper.GENERAL_FOOTER_BANNERS_RESOURCE_KEYS);
model.ContentResourceKeys.AddRange(ResourceHelper.LANDING_PAGE_SEARCH_AREA_RESOURCE_KEYS);
model.ContentResourceKeys.AddRange(ResourceHelper.LANDING_PAGE_MODULES_RESOURCE_KEYS);

The ContentResourceKeys property is defined in a MasterModel that is extended by every View Model used across the site, as can be seen here: http://blogit.create.pt/andresantos/2014/11/07/pre-set-common-viewmodel-preperties-before-action-result/. That post also describes the Action Filter that is executed after every action on the site and it’s the place where we append the footer and header resources to the ContentResourceKeys list:

List<string> resourceKeys = new List<string>();
resourceKeys.AddRange(ResourceHelper.HEADER_RESOURCE_KEYS.ToList());
resourceKeys.AddRange(ResourceHelper.LOGIN_RESOURCE_KEYS.ToList());
resourceKeys.AddRange(ResourceHelper.FOOTER_RESOURCE_KEYS.ToList());
resourceKeys.AddRange(ResourceHelper.LOADING_RESOURCE_KEYS.ToList());
resourceKeys.AddRange(ResourceHelper.HEADER_COOKIES_RESOURCE_KEYS.ToList());

if (model.ContentResourceKeys != null && model.ContentResourceKeys.Count > 0)
{
    resourceKeys.AddRange(model.ContentResourceKeys);
}

2 – Fetch the resources

After compiling the resource keys needed, we go on and fetch the associated resource items. The project where this was implemented used a WebAPI to serve all the page content and the resource items were no exception. So, we send a POST request to the resource WebAPI method and fetch the needed resources, for the user language, from the available backoffice (we used a SharePoint list).

model.Resources.AddRange(ResourceFacade.ListResources(model.CurrentLanguageCode, resourceKeys));

3 – Add them to the View Model

The Resources property available in the View Model where we added the result of the call to the resources WebAPI method is a string Dictionary. Since C# Dictionaries don’t provide an AddRange method, we create an extension method that enables us to append resources to a dictionary that’s not empty. Moreover, with this extension method we are able to scrap duplicate keys:

public static class IDictionaryExtensions
{
    public static void AddRange<T, S>(this IDictionary<T, S> source, IDictionary<T, S> collection)
    {
        if (collection == null)
        {
            throw new ArgumentNullException("Collection is null");
        }

        foreach (var item in collection)
        {
            if (!source.ContainsKey(item.Key))
            {
                source.Add(item.Key, item.Value);
            }
        }
    }
}

4 – Use the resources in the views

Since every View Model extends the MasterModel, we are able to use the same property everywhere:

<footer id="footer">
  <div class="container">
    <div class="newsletter">
      <h2>@Model.Resources["Footer.Newsletter.Title"]</h2>

This way, we are able to manage the resource keys in a SharePoint list, or any other backoffice solution.

The post Remote resource handling in a MVC website project appeared first on Blog IT.

AngularJS is a MVC javascript framework mainly mantained by Google which primary goal is to aid in the development of single-page applications. It’s use on the Umbraco backoffice was the most notable change when Umbraco 7 was first released.

When the content manager selects one node pending approval we want him to be able to take three quick actions:

• get some information about that node;
• quickly access it in the content section;
• quickly publish it.

New Angular controllers and views must be placed in a specific Umbraco directory, following a specific directory structure:

• the main directory must reside at ~\App_Plugins\ApproveIt – the plugin name
• the views and controllers must reside at App_Plugins\ApproveIt\backoffice\approvalTree\ – the tree controller name

First things first:

Create a package manifest so that Umbraco knows there are new javascript files available, and place it in the root of App_Plugins\ApproveIt directory.

{
	javascript: [
		'~/App_Plugins/ApproveIt/backoffice/approvalTree/edit.controller.js',
		'~/App_Plugins/ApproveIt/approval.resource.js'
	]
}

Then we must create the javascript files referenced by the manifest and the respective angular view.

angular.module("umbraco.resources")
	.factory("approvalResource", function ($http) {
	    return {
	        getById: function (id) {
	            return $http.get("backoffice/ApproveIt/ApprovalApi/GetById?id=" + id);
	        },
	        publish: function (id) {
	            return $http.post("backoffice/ApproveIt/ApprovalApi/PostPublish?id=" + id);
	        }
	    };
	});

This javascript file provides a new Angular Service that can then be used by Angular controllers. This service is no more than a facade for the ApprovalApiController created on Part II. The methods it connects to are created further on.

angular.module("umbraco").controller("Approval.ApprovalEditController",
	function ($scope, $routeParams, approvalResource, notificationsService, navigationService) {

	    $scope.loaded = false;

	    if ($routeParams.id == -1) {
	        $scope.node = {};
	        $scope.loaded = true;
	    }
	    else {
	        approvalResource.getById($routeParams.id).then(function (response) {
	            $scope.node = response.data;
	            $scope.loaded = true;
	        });
	    }

	    $scope.publish = function (node) {
	        approvalResource.publish(node.Id).then(function (response) {
	            $scope.node = response.data;
	            $scope.contentForm.$dirty = false;
	            navigationService.syncTree({ tree: 'approvalTree', path: [-1, -1], forceReload: true });
	            notificationsService.success("Success", node.Name + " has been published");
	        });
	    };

	});

This Angular controller is called when the Approve It section is being used:

• If no node is selected (for instance, when we access this section for the first time) we do nothing;
• If a node is selected ($routeParams.id != -1) we request the node details through our approval.resource service facade
• Finally, the quick publish method is also implemented here. This methods calls the ApprovalResource service which then invokes the publish method of the ApprovalApiController.

<form name="contentForm"
      ng-controller="Approval.ApprovalEditController"
      ng-show="loaded"
      ng-submit="publish(node)"
      val-form-manager>
    <umb-panel>
        <umb-header>
            <div class="span7">
                <umb-content-name placeholder="@placeholders_entername"
                                  ng-model="node.Name" />
            </div>
            <div class="span5">
                <div class="btn-toolbar pull-right umb-btn-toolbar">
                    <umb-options-menu ng-show="currentNode"
                                      current-node="currentNode"
                                      current-section="{{currentSection}}">
                    </umb-options-menu>
                </div>
            </div>
        </umb-header>
        <div class="umb-panel-body umb-scrollable row-fluid">
            <div class="tab-content form-horizontal" style="padding-bottom: 90px">
                <div class="umb-pane">

                    <umb-control-group label="Name" description="Content's name">
                        <input type="text" class="umb-editor umb-textstring" ng-model="node.Name" required />
                    </umb-control-group>

                    <div class="umb-tab-buttons" detect-fold>
                        <div class="btn-group">
                            <a class="btn" ng-href="#/content/content/edit/{{node.Id}}">
                                Show
                            </a>
                        </div>
                        <div class="btn-group">
                            <button type="submit" data-hotkey="ctrl+s" class="btn btn-success">
                                Publish
                            </button>
                        </div>
                    </div>
                </div>
            </div>
        </div>
    </umb-panel>
</form>

The node view presents the waiting approval page name and two buttons: one to quickly navigate to it’s details and another to publish it.

Finally, we need to update the ApprovalApiController.cs to include two new methods:

public IContent GetById(int id)
{
    IContent content = ApplicationContext.Services.ContentService.GetById(id);
    return content;
}

public IContent PostPublish(int id)
{
    IContent node = ApplicationContext.Services.ContentService.GetById(id);
    ApplicationContext.Services.ContentService.Publish(node);

    return node;
}

• GetById: returns the node details to the angular view
• PostPublish: publishes the node being viewed

By following these steps we are able to create a complete new Umbraco backoffice section that provides us with a way to manage every site content waiting approval for publishing:

If you want to see how this plugin as been evolving, you can check its source code in github: https://github.com/ViGiLnT/ApproveIt. You can also download the plugin ready to be installed at Umbraco’s extensions repository: https://our.umbraco.org/projects/backoffice-extensions/approve-it/. Other Umbraco 7 tutorials and information can be found here: http://umbraco.github.io/Belle.

The post Building an Umbraco 7 backoffice extension – Part III appeared first on Blog IT.