Develop an ASP.NET API site together with an Angular JS frontend

Recently I’ve started to play around with Angular JS and ASP.NET core. I’ve created an ASP.NET web API project and (basically) copied the Angular frontend to wwwroot.

All Angular stuff is running by using an index.html file containing the app and all pages are displayed by using an MVC like scheme (aka API calls to the backend services are encapsulated within the path /api (e.g.

After creating a web API project with Visual Studio, it’s not possible to drive static files which are copied to wwwroot. Therefore two more lines are necessary to drive files from within an API app. Please add the following lines before the app.UseMvc() call in Startup.cs:

// switch to index.html on any request not starting with "api/"
// (C# controller) nor being an existing static file
app.Use(async (context, next) =>
    await next();
    var path = context.Request.Path.Value;
    var fileInfo = env.WebRootFileProvider.GetFileInfo(path);
    if (!path.StartsWith("/api", StringComparison.InvariantCulture)
        && !fileInfo.Exists)
      context.Request.Path = "/index.html";
      await next();

The first statement (app.Use(...); ) will handle all not known requests to the backend and route them to index.html (e.g. the angular router will handle the request).

Any request that is not routed via api  and that does not map to an existing file under wwwroot  will be forwarded to index.html. Routing errors (e.g. invalid pages, …) are forwarded to /404 .

app.UseDefaultFiles() will check for default files if a root path or directory is given. In the current scenario this will work only for the root directory which is sufficient.

app.UseStaticFiles() is responsible to serve all files located under

Example code can be found at

Using with ASP.NET webforms – A generic approach is a flexible HTML table component used in many applications. Recently (in a large ASP.NET webforms legacy application) we’ve had the need to switch from a commercial product towards a product which is easier to maintain and which does not contain 5000 features where we use only 10 out of them (and some of the others are creating problems).

Using is very easy and requires only limited knowledge on JavaScript in case you are providing table data together with the data to be displayed. You can find tons of examples on the home page.

In case you are going to display data which is

  • hard to generate on the fly (volume, complex queries) or

  • is changing during paging or other table operations

you need to load data from the server even after the page has been requested. The term used in is “server side processing”.

By using a .NET handler class and a generic interface that encapsulates the data provider we’ve generated a solution which can be easily adapted to create a generic data table provider implementation in ASP.NET web pages.

I’ve created a short demo on github that shows the general approach and might help as a base to use an own implementation.

Reading streamed data from Excel or CSV

Recently I stumbled over the task to read either CSV or Excel files and transfer data in an independent format to a server.

The existing software part implemented to similar approaches to

1. Read the file

2. Transfer the file into an intermediate format (a DataTable)

3. Transfer the file up to the server

The server took the file, read all data, translate number according to a given number format sent by the client, …

Reviewing the code resulted into a couple of drawbacks: redundant code, performance, use of language depending information on the server side, etc.

As a result I looked for an approach to

1. combine CSV and excel load within one flow and

2. have data translated on the client side into a format which can be read by the server without knowledge of the client user language (or the date format used for loading files)

Based on a code example for IDataReader ( I had the idea to create a library which streams data independent of the input format.
Continue reading “Reading streamed data from Excel or CSV”

I18n: Parsing Decimal values

At Tideum and for TimeJack we are developing line of business applications which usually handle numbers. As we are developing our software for international markets we usually face the problem of users entering numbers in a format that is not the same as the current locale (e.g. Germans are entering numbers in English locale and vice versa). This happens very often if data is copied from 3rd party applications (e.g. SAP or Excel).

Parsing those numbers with the standard .NET functions (aka. Decimal.Parse()) is parsing only a fixed language, e.g.

string source = "123,45";
decimal value = Decimal.Parse(source);

depends on the current thread culture settings. In case the current settings are “de-DE” (or “de-AT”), the conversion will return value == 123.45, for “en-US” value == 12345 will be returned and for “de-CH”/”fr-CH” a System.FormatException is thrown.
Continue reading “I18n: Parsing Decimal values”