Building Asp.NET Core applications in Appveyor

To build your Asp.NET Core 1.0 application in Appveyor, a bit of configuration is required to tell the Appveyor build agent to get the dotnet core compiler. The configuration steps will install the .Net Version Manager and a runtime for your application. The necessary packages and references will also be restored prior to the build. Simply add or amend your appveyor.yml file at the root of your project repository with the contents below:

Kestrel reverse proxy using nginx

When you self-host your Asp.NET Core web application using Kestrel, it is recommended that you don’t expose it to the outside world, but use a reverse proxy instead. If you followed the sample in cross-platform Asp.NET Core then you found out that your self-hosted application is only available from your local machine. To expose your application to the outside world, the recommended approach is to use a reverse proxy using Apache or nginx.

asp.net core linux hello world

On Asp.Net Core 1.0 you can create cross-platform applications that will run without modifications in multiple operating systems and CPU’s. Today we are going to create an Asp.Net Core 1.0 “Hello World” sample in Windows and run it in linux (Centos 7.1 x86_64). First we start with the installation of .Net Core 1.0. For Windows, browse to https://get.asp.net/ and download the installer. After running this installer you will be able to run .

Continuous web page performance testing

Web page performance is very important in a website, as it directly impacts your ROI. A slow website will have a high rate of abandonment and is a source of frustration for your visitors. One of the ways to ensure you are not caught in this situation is to measure web page performance every time you deploy a new feature. To demo this we are going to use: webpagetest.org – The tests will be invoked using its REST API via a Node module Appveyor – A CI service to run the tests First we need to create an API key at webpagetest.

Page performance is a feature

One aspect that is often overlooked, until things go wrong, is the performance of the website. More specifically, the speed the pages load and are ready to be used. Site performance is linked to customer satisfaction and conversion. The slower your site is, less people will be visiting and your conversion figures will drop. Follow these steps to ensure your website is always performing at its best: Client side performance There are many guides that you can follow to improve the client side performance of your website.

Cross cutting concerns in EPiServer using Dynamic Proxies

Cross cutting concerns should be handled in an unobtrusive way, i.e. implemented in a way they don’t require any modifications to your original features. One way to achieve this is by using Aspect Oriented Programming, more specifically using Castle Dynamic Proxies to intercept method calls at runtime with StructureMap. The code examples below were implemented in an EPiServer Alloy MVC site. In this example we’re going to add MiniProfiler and measure how long each method takes to run.

Debug EPiServer Search (lucene)

A quick note to self: To debug EPiServer Search indexing, the below should be added to EPiServerlog.config:   <!--EPiServer.Search.IndexingService.IndexingService--> <logger name="IndexingService"> <level value="All" /> </logger> <logger name="EPiServer.Search"> <level value="All" /> </logger> <!-- Reduce amount of debug logging --> <logger name="EPiServer.Core.ContentProvider" additivity="false"> <level value="Debug" /> </logger> <logger name="EPiServer.Data.Dynamic.Providers.DbDataStoreProvider" additivity="false"> <level value="Error" /> </logger> <logger name="EPiServer.Data.Providers.SqlDatabaseHandler" additivity="false"> <level value="Error" /> </logger> <logger name="EPiServer.Data.Providers.ConnectionContext" additivity="false"> <level value="Error" /> </logger>  

EPiServer workflows – emails not being sent

The most commonly used workflow in EPiServer is the Sequential approval workflow. It is primarily used to assign tasks and send notifications through the various stages of page publication. Troubleshooting workflows is no easy task. You typically have to enable Windows Workflow Foundation diagnostics and examine the logs. You can achieve this by adding the following element to your web.config: <system.diagnostics> <switches> <add name="System.Workflow.Runtime" value="All" /> <add name="System.Workflow.Runtime.Hosting" value="All" /> <add name="

Security misconfiguration – server headers

Revealing specific details about the operating system and the platform you are using to host your website can make it more vulnerable. While knowing that you’re using Windows/Linux as the operating system or IIS/Apache/nginx as your application server won’t make it less secure, it does help an attacker tailor his attack vector against your system. This type of vulnerability is detailed in the Owasp top 10: A5. Revealing information about your system may help an attacker.

Debug live website performance with DebugDiag and Windbg – capture memory dump

In this scenario we have an application that performs slowly and has high CPU usage. Typically pages take longer to load and sometimes might timeout. Start DebugDiag Collector and select “Performance” Select the second option to monitor the HTTP response times of your website Add the urls to the pages that are performing slowly to monitor their response times Enter the page urls and set the timeout after which the rule is triggered.

Debug live website crash with DebugDiag and Windbg – capture memory dump

Application crash In this scenario we want to capture a memory dump at the exact moment the application has crashed. Start the “Debug Diag Collection” tool and select “Crash” Select a specific application pool, i.e the application pool that your site is running. Select the application pool of your website Leave the defaults selected. In DebugDiag 2.0 this will record the call stack for first chance exceptions and a full memory dump for second chance exceptions, i.

Debug live websites with DebugDiag and WinDbg

Debugging and troubleshooting problems in a production environment is always a tricky endeavour. You usually do not have the luxuries of having a debugger that allows you to step through your code and inspect you variables and stack trace. Some of the areas you might look at include the Event Viewer, to look for any error events or the application log files, to analyse any caught exceptions. If the application is crashing and there’s nothing obvious available in the logs, your best bet is to perform post-mortem analysis with DebugDiag/AdPlus and Windbg.

Security by design – common vulnerabilities found in web applications during security testing

Some websites use security through obscurity as their main means of protection. This methodology relies on making the vulnerabilities hard to obtain by not making the system’s design known to the general public. As anyone knows, a secret is never a secret for very long. This is bad practice and careless. Concealing a vulnerability will only delay an attacker and not pass any form of security testing. The right approach is to have security as part of the design process of a system.

CDN strategies

A global website needs to have relevant content for their multi-cultural, sometimes worldwide, audience. This content needs to be provided to a visitor as quickly as possible to engage them in a great experience. One solution is to deploy and mirror your application to several datacentres across the world. A much more cost effective solution is to use a CDN (Content Delivery Network) to serve your content from a geographical location close to your visitor.

EPiServer remote events troubleshooting

EPiserver uses WCF to send and receive events between servers configured in a multi-server setup (load-balanced or enterprise). A site in a server will send events (publisher) to one or many sites in other servers (subscriber). This is an example of an enterprise setup, with one publishing server and two public facing web servers. To enable remote events (events between EPiServer sites), the following has to be enabled in your episerver.

EPiServer UDP remote events in secure environments

In a production environment access between various servers is usually restricted to what is the minimum required for the solution to operate. In an enterprise scenario it is common to find a setup where you have multiple load-balanced servers for public users and a separate publishing environment for web editors. These environments usually follow a “deny all” approach where all access has to be explicitly permitted. EPiServer by default uses UDP multicast to transmit event messages (e.

International address validation

When building an e-commerce solution it is important to have the correct delivery details of your customers. By doing so you ensure the orders are being sent to the correct address, decreasing the number of lost parcels and returns. Your customers will be happy and in turn, you will be happier. There are a number of service providers that can help you complete and validate your customers details. The most typical application is to lookup an address from a partial entry, helping a user complete their details, speeding up the process of registration.

Log4net visualiser

When we are implementing an EPiServer web site (or any other software solution) it is imperative to have good error handling. EPiServer uses log4net for its error handling so it is natural to use it as the logging framework for your application. If your website is not behaving properly, you want to know about it and act accordingly. This is a good habit to have and it is a best practice in software development.

LoaderExceptions when building in Release mode – sgen.exe

Recently we faced a problem where an application would build and run in debug mode but it would not do the same in release, throwing the following error at the end of a build. sgen = http://msdn.microsoft.com/en-us/library/bk3w6240(v=VS.100).aspx Knowing that sgen is responsible for generating the xml serialisation assembly for the application, the error was most likely related to an assembly that was injected during runtime into the AppDomain, in release mode.

EPiServer DataFactory deadlock exception

Recently we faced a problem in one of our websites where some pages would randomly fail to load and a deadlock exception would be thrown from EPiServer.DataAccess.DatabaseFactory: “Failing because of deadlock.” At this point we suspected that some other process might be locking some rows out thus causing the loading of our page to fail. Drilling down the logs, we found out a bit more of what was causing the pages to fail: