Girish Jain on .Net Framework

I will be writing about my favorite technology which is Microsoft .Net Framework and how to use it to improve developer productivity

ASP.NET 5 Logging using Trace Listeners and How-to Filter Log Entries

clock January 13, 2016 05:47 by author Girish Jain

Source code available at GitHub

Pluggable logging framework by ASP.NET 5...

ASP.NET 5 is the new open-source and cross-platform framework for building modern web applications using .NET. The new framework has in-built support for logging and it allows you to integrate with other logging frameworks too. You may need to write some code as a bridge between ASP.NET logging framework and your preferred logging provider by implementing interfaces provided by ASP.NET 5 such as ILoggingProvider and ILogger.

Can we plug trace listeners...?

In this post, I am going to cover how to use existing tracing framework in ASP.NET 5 projects. Tracing has been available in .NET since its inception. People have made investments into using trace listeners which write trace messages to a variety of destinations such as local file, database table, etc. They should be able to reuse their investment in ASP.NET 5 project as well. Let’s see how.

No more web.config...

Using tracing in in ASP.NET 4.x was fairly straight forward. You would define trace source and add trace listeners using web.config file. Something very simple as follows:

  <trace autoflush="true"></trace>
    <source name="MyServiceTraceSource" switchvalue="All">
        <add name="MyServiceListener" type="System.Diagnostics.TextWriterTraceListener" initializedata="MyServiceLog.txt"></add>
And then in your code, you would write messages to trace source which would be received by the trace listener configured for trace source. That has changed with ASP.NET 5, as it does not use web.config file, we’ve lost that configuration-ability that we are so used to. Though, there’s nothing stopping us from defining trace listener configuration using new JSON config file and then using the same in code to create trace listeners that would listen for specific trace sources. For now, in this article, I am going to use trace listeners directly in code. 

Add tracing provider...

ASP.NET 5 has its own logging framework so we would need to plug trace listener provider to ASP.NET 5 logging framework. To use trace listeners in ASP.NET 5, you would need to add a NuGet package to your project called, Microsoft.Extensions.Logging.TraceSource. It has been developed by team as part of aspnet/Logging project. It lets you use TraceSource and TraceListener in your ASP.NET 5 project by using TraceSourceLogger class. 

You need to add Microsoft.Extensions.Logging.TraceSource package to your project as a dependency in project.json file as shown below:

"dependencies": {
    "Microsoft.AspNet.IISPlatformHandler": "1.0.0-rc1-final",
    "Microsoft.AspNet.Mvc": "6.0.0-rc1-final",
    "Microsoft.AspNet.Server.Kestrel": "1.0.0-rc1-final",
    "Microsoft.AspNet.StaticFiles": "1.0.0-rc1-final",
    "Microsoft.Extensions.Configuration.FileProviderExtensions": "1.0.0-rc1-final",
    "Microsoft.Extensions.Configuration.Json": "1.0.0-rc1-final",
    "Microsoft.Extensions.Logging": "1.0.0-rc1-final",
    "Microsoft.Extensions.Logging.Console": "1.0.0-rc1-final",
    "Microsoft.Extensions.Logging.Debug": "1.0.0-rc1-final",
    "Microsoft.Extensions.Logging.TraceSource": "1.0.0-rc1-final"


Add Trace Listener...

Next, you need to add a trace source listener to logger factory:

public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory)
        new SourceSwitch("AspNet5LoggingSwitch", "Verbose"),
        new TextWriterTraceListener("AspNet5LoggingService.txt")

Note: TextWriterTraceListener is not available in .Net Core but .Net Framework only so once you use it in your code, you may get compile error for the same. If you do, you would need to remove dnxcore50 target framework from your project by modifying project.json file i.e. remove highlighted line below:

    "frameworks": {
      "dnx451": { },
      "dnxcore50": { }


Get Logger...

Lastly, you need to get logger instance in your classes by injecting a dependency to your class for logger instance. There is couple of options available for adding a dependency to class constructor for logger instance:

1. One option is to use ILoggerFactory type as a dependency and then manually creating a logger by calling CreateLogger method on factory instance and passing in a category name.

2. Another option is to use Logger<T> as a dependency in your constructor by specifying generic type parameter.

When using ILoggerFactory, you need to manually create a logger whereas with Logger<T> you could directly start using it for logging. For most situations, using Logger<T> would suffice but when you don’t know the generic type parameter to be used or if you would like to create a logger with a certain category name, you could use ILoggerFactory. Let’s look at an example using both approaches:

    public class ValuesController : Controller
        private readonly ILogger<ValuesController> logger;
        public ValuesController(ILogger<ValuesController> logger)
            this.logger = logger;
    public class ValuesController2 : Controller
        private readonly ILogger logger;
        public ValuesController2(ILoggerFactory loggerFactory)
            this.logger = loggerFactory.CreateLogger("AspNet5LoggingService");


Use Logger...

Voila! You are done and now you can start using this logger instance to write log entries.

    public class ValuesController : Controller
        private readonly ILogger logger;
        public ValuesController(ILogger logger)
            this.logger = logger;
        // GET: api/values
        public IEnumerable Get()
            logger.LogInformation("Processing GET request for values.");
            return new string[] { "value1", "value2" };

When executed, it would write log entry in trace destination by trace listener, which in my case was the log file specified with TextWriterTraceListener.


Noisy log entries...

You would find that log file is created in wwwroot folder and it contains all log entries. But as you would have noticed, the log file also contains all log entries which are generated by ASP.NET 5 framework. You would see something like this:

    Microsoft.AspNet.Hosting.Internal.HostingEngine Verbose: 4 : Hosting starting
    Microsoft.AspNet.Hosting.Internal.HostingEngine Verbose: 5 : Hosting started
    Microsoft.AspNet.Hosting.Internal.HostingEngine Information: 1 : Request starting HTTP/1.1 GET http://localhost:50998/api/values
    Microsoft.AspNet.Hosting.Internal.HostingEngine Information: 1 : Request starting HTTP/1.1 DEBUG http://localhost:50998/ text/html
    Microsoft.AspNet.StaticFiles.StaticFileMiddleware Verbose: 1 : DEBUG requests are not supported
    Microsoft.AspNet.StaticFiles.StaticFileMiddleware Verbose: 4 : The request path /api/values does not match a supported file type
    AspNet5LoggingService Information: 0 : Processing GET request for values.    

This behavior is by design. All logging providers will get all logging messages and it’s for individual provider to filter the "category" of messages they are interested in. Most likely, you wouldn’t want all those entries in log file along with log entries created by your service code and that brings us to next step.


How to filter for log entries...?

You can filter log entries by adding a filter to TraceListener, which is defined as a property on TraceListener base class. It’s of type TraceFilter:

public System.Diagnostics.TraceFilter Filter { get; set; }


If you lookup TraceFilter class definition, you would notice that it’s an abstract class. There are few default TraceFilter implementations available and you could use them or create your own filter very easily. All you would need to do is derive a class from TraceFilter and override ShouldTrace method. For this example, I am going to use existing SourceFilter class, which comes with .NET.

You could add a TraceFilter to your listener as follows:

    var listener = new TextWriterTraceListener("AspNet5LoggingService.txt");
    listener.Filter = new SourceFilter("AspNet5LoggingService");
        new SourceSwitch("AspNet5LoggingSwitch", "Verbose"),


Where are my filtered log entries...?

Depending upon your project and the number of log entries being generated, it may happen that you don’t see any new trace messages in your log file, especially after you filtered for trace messages generated by your service code. If you are using a TextWriterTraceListener, you may not see your log entries immediately in log file, though the log file would be created immediately (if it does not exist already). This is where I struggled and ended up spending quite some time debugging why I don't see log entries in my file, only to find out later about a feature with the specific listerner that I was using. This happens because TextWriterTraceListener writes data to the file stream and those trace messages are buffered. It does not flush the buffered data with each write. In previous versions of .NET, you would normally add following to your web.config file.

<trace autoflush="true" />


which would cause trace listeners to flush trace messages immediately. To achieve the same in ASP.NET 5, you can add following in code:

    public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory)

        // This would prevent TextWriterTraceListener from buffering trace messages but cause
        // it to flush them as each trace message is sent to listener
        if (env.IsDevelopment())
            Trace.AutoFlush = true;

        var listener = new TextWriterTraceListener("AspNet5LoggingService.txt");
        listener.Filter = new SourceFilter("AspNet5LoggingService");
            new SourceSwitch("AspNet5LoggingSwitch", "Verbose"),

I am opting for AutoFlush behavior only in case of development environment because that's where we would need log entries to be reflected in file immediately whereas in production environment buffering log messages would give better performance. If you don’t set AutoFlush property, you would need to wait until buffered data in stream is written to file on disk.


In this article we saw how to

1. Use trace listener in ASP.NET 5 project

2. Filter trace entries at the trace listener level

3. Use Trace.AutoFlush in code to prevent trace messages from being buffered in memory

NOTE: Please note that this article was written using ASP.NET 5 RC1 and by the time RTM comes out, which is expected in another couple of months, there may be some changes.

Happy Coding.

Vande Mataram!

(A salute to motherland)

Asynchronous Programming in .Net with QnA

clock April 9, 2015 03:33 by author Girish Jain


In this post, I am going to talk about asynchronous programming in Microsoft .Net Framework in the form of questions and answer. It will help reader with understanding scenarios where to use asynchronous code and how it will benefit application. Would love to hear your comments and questions, so feel free to use comments area.

Please Note:

1. This article is not about how to write asynchronous code, you need to use your google skills for that. I am going to talk about some of the basic concepts of Task based Asynchronous Pattern (TAP) and try answer questions which come to developer's mind on his journey to learning asynchronous programming. Well, I had these questions so I found answer to these and am hoping this would help fellow developer.

2. I am talking about asynchronous code execution in CLR and hence, concepts discussed in here need to be seen in that context. For example, when talking about threads, I am referring to managed threads in CLR.


I am going to give a brief overview of asynchronous programming in .Net and then move on to questions and answers. Support for asynchronous execution has always been there in .Net since early version of framework. Remember IAsyncResult interface? Yes, of course, it resulted in too complex code in the first place and then it was a nightmare to maintain it or make changes to it. Even for simplest of functional scenarios, it resulted in too much of code. No wonder, developers dreaded it.

Fast forward to .Net 4 and Microsoft introduced Task, async, and await which greatly simplifies writing asynchronous code. These new constructs made it super easy for developer to write methods which can spawn a background operation and then later join with its result. All heavy-lifting is shifted to compiler to generate code for making this possible. I must say, it has been one of the best feature additions to .Net based compilers, C# (and I believe VB.Net too), an engineering marvel.

Task based Asynchronous Pattern (TAP) is based on concept of a task, represented by Task type in System.Threasing.Tasks namespace. It represents an asynchronous operation which you could wait for completion, cancel it, or specify a continuation to execute when this asynchronous operation is complete. It provides an object-oriented approach to writing asynchronous code. This frees up developer from worrying about semantics of language or execution environment for executing asynchronous operation and he can rather focus on functional aspects of application. Core idea here is to enable developer to execute methods on a separate thread seamlessly.

Let's drill deep into this TAP to understand more about it with the help of questions and answers.

Q1. What's most common use case scenario for asynchronous code?

I am not going to show you a code sample for how to write asynchronous code. Google is your best friend for that. Let's try and understand this with the help of a real-life like scenario:

To give you an analogy, let's consider case of a restaurant. We all know how it works in a restaurant, waiter takes order and then passes it to chef to prepare and waiter continues with other tasks while chef is preparing food. This is an example of asynchronous execution of tasks in real-life as Waiter is free after passing order to chef and can cater to other customers or serve a completed order to customer and so on. Let's see how it relates to software applications. Your front-end application (waiter) which takes multiple requests (orders) from end users (customers)

can schedule these requests on a background worker (chef) thread. Similar to waiter, while worker thread is executing long running action, your front-end application is free to respond to further user requests. This would be most common use case scenario for asynchronous code.

First example that you would come across when learning asynchronous code execution in .Net would be a Windows UI application being blocked while executing a long running task, as part of a button click event handler, and then asynchronous code would come to rescue and solve this problem. Task based asynchronous pattern helps to a great extent in case of UI applications.

Biggest pain point solved by asynchronous code, in case of windows applications, is to do with application responsiveness. Asynchronous code helps you prevent those scary freeze moments (imagine waiter going to kitchen to prepare your order). We've all had that experience many times with Windows XP. Long running tasks can be scheduled on background thread so that main UI thread can respond to user actions in parallel, thereby enabling optimum utilization of processor time and responsive UI.

Q2. Is asynchronous code only for UI applications? How about windows or web services, there is no UI thread in there so is there any benefit of using asynchronous code with these background applications?

Asynchronous code is not only for windows UI applications, it can help with background applications too. In case of background applications such as windows or web services, we don't have UI threads but we have I/O threads. Each call to a web service is serviced by an I/O thread in your IIS worker process. If work performed by your web method does not trigger a long running task, you are good but you may have some methods which could take longer to complete. In case of such methods, using asynchronous code to start long running task on a background worker thread (chef) will help free up your I/O thread (waiter) to perform other activities in parallel.

Hence, asynchronous code in background applications helps with optimum utilization of processor time and hence, should be used with windows and web services too.

Q3. Still unsure with above answer for how asynchronous code would help in case of a web service. I/O thread would not really be free until worker thread finishes, so in essence, it won't go back to thread pool to serve more requests after invoking long running task but, wait for it to finish. What we are doing is taking work from I/O thread, scheduling it on a worker thread, and then making I/O thread wait for worker thread to finish. Where's net gain?

It is correct that I/O thread will not be going back to thread pool until it finishes executing the web method (unless long running task was invoked as fire-and-forget, in which case, it would finish execution of web method and go back to pool). But, it does NOT need to wait while worker thread is executing long running task and that's where you gain with asynchronous code. You can continue executing code on I/O thread in parallel while worker thread is executing long running task. Remember from earlier restaurant analogy, waiter does not need to wait for chef to complete an order but can continue in parallel. Hence, gain comes from ability for I/O thread to continue executing in parallel with worker thread. At certain point though, I/O thread will need result from long running task and it may go into wait mode for worker thread to finish.

Q4. I don't have anything else to execute in parallel while worker thread is executing long running task. Should I still execute long running task asynchronously?

Would you create a restaurant with the assumption that you may not have lot of customers coming in and hence, one person as waiter-cum-chef will do? I am sure no, then why create software like that. Waiter and chef have different roles and responsibilities and hence, you should build these roles separately in your software too.

So yes, it would still make sense to execute long running task asynchronously at least from a design perspective. Don't put yourself into a corner. Also, it does not take lot of effort to write asynchronous code in first place and hence, Microsoft recommends you to trigger long running activity as an async task.

Q5. Functional requirements of my application require a given (long running) method to be invoked synchronously, will writing it as an async method help?

Yes, it will help. Don't create tight coupling between your implementation and business requirements, which have a high tendency to change frequently and when that happens, you will need to modify your implementation. It is best to keep your long running task method as async and you can always call an asynchronous method synchronously. So, create method performing long running task as async and depending upon your business requirements, you can decide to invoke this method and wait for it to finish.

Q6. Can we invoke an async method synchronously?

Yes, you can invoke an asynchronous method synchronously too. Here's an example:


Q7. Is it required to have multiple processors on system to take advantage of asynchronous code?

Not really, you can benefit from asynchronous code on a machine with single processor too.

Q8. How would asynchronous code execution help on a single processor machine? If there's just a single processor then it is going to execute any one thread at a time (main or worker), so how does offloading long running task to a separate thread help?

At a logical level, I am sure that restaurant analogy has made it clear to you for how delegating a long running task to a separate worker helps main worker continue in parallel. This question would arise in developer's mind more from technical perspective to understand how it would work in case of a single processor machine because end of the day, you have a single processor and it would execute one thread at a time, so how would creating multiple threads help. Let's try and understand that.

Processor is a shared resource from perspective of a process. Each process utilizes CPU in a time-sharing manner:

So each process gets a fraction of processor time. Processor executes threads in a process. A process can have multiple threads. Unlike processes, wherein each process gets processor time, not every thread in a process will get executed by processor. Processor will execute &ldquo;active&rdquo; threads in a process, ones which are currently executing and it will continue from where it last left off, as it goes around processes.

So within a given process, threads need to efficiently utilize processor time made available to process. A greedy thread who wants to do it all will not help and this is where your application can be smart to spawn another thread where you execute a potentially long running task and provide multiple threads to processor to execute. If main thread in your UI application is executing a long running database query then it is not best utilization of processor time because most of the time, this thread would be blocked waiting for response from database server. Hence, if you have multiple threads of execution then processor time made available for a process can be utilized in optimum manner, by executing other threads which are available and ready for executing instructions. Hence, even when you have a single processor machine, asynchronous code would help with executing in parallel threads.

Q9. If having more threads in a process helps, should I keep that as a goal and create as many threads as possible?

Will increasing number of waiters in your restaurant without increasing chefs in kitchen help? Similarly, increasing threads in the process without increase in processor capacity would not help. Threads are executed by processors and we are limited on number of processors available. Having too little threads may lead to underutilization of processor but, at the same time, creating too many threads would be overkill for the process and rather degrade performance of application.

Q10. What happens when I invoke an asynchronous method? Does it immediately start executing on a separate worker thread of its own?

That depends upon availability of chef, am sorry, processor here as threads are executed by processor. When you start a new task, it is queued by CLR to thread pool and it will be executed as processor executes threads from pool. CLR manages queueing of a task using thread pool extremely well and hence, we don't have to worry about low-level details of scheduling and managing thread pool.

Q11. How do I decide whether a given method needs to be created as async?

Microsoft suggests any method which could potentially take longer than 50ms to complete, is a candidate for being async method. Caller of such method should have an option to invoke it asynchronously.

Q12. Should I consider target hardware for my application or service before writing asynchronous code?

For most cases, no, because CLR manages scheduling of worker threads for you so you don't have to worry about factoring underlying hardware capacity or availability. CLR makes optimum utilization of processor capacity so, leave it for CLR to take care of, it does a good job.

If you have more questions about asynchronous programming, please use comments area below and I will try to answer them. Thanks.

Happy Coding.

Vande Mataram!

(A salute to motherland)

P.S. In addition to blogging, I use Twitter to share tips, links, etc. My Twitter handle is: @girishjjain

CLR Journey from PInvoke to WinRT

clock June 21, 2013 11:20 by author Girish Jain


In this blog post, I am going to talk about Microsoft .Net Common Language Runtime (CLR) journey from its early days to latest Windows Runtime (WinRT) platform, which is released with Windows 8. I would suggest you read my previous blog post on WinMD files before reading further to gain better understanding of WinMD files introduced with Windows 8.

WinRT is the new platform released with Microsoft’s latest operating system Windows 8 and .Net Framework 4.5. It is important to remember that for WinRT APIs to work it needs at least Windows 8 as operating system (or Windows Server 2012 for server family of operating systems), and hence, WinRT is not available for previous platforms.

Coming back to WinRT, did we need another set of runtime libraries and a new file extension, WinMD? I am sure you are having this basic question in mind for what good this new WinRT library is going to do and why on earth Microsoft added a new file type? I will try and answer it in this blog post.


Windows Runtime (WinMD at heart)

WinRT is the new platform which exposes underlying operating system APIs in object-oriented manner to developers (across languages) and enables them to make best use of underlying platform capabilities to build great immersive apps.

WinMD files are at the heart of new Windows Runtime (WinRT) concept. These new WinMD files only contain metadata for WinRT types. WinMD files themselves do not contain any code. Hence, when you open any WinMD file using ILDAsm tool you see that all class methods are marked as "runtime managed" which, as per ECMA-335 CLI specification, means the managed implementation for the method will be provided by CLR. Please read my earlier blog post for more details on WinMD files.

Underneath, CLR bridges the gap of converting managed calls to low-level operating system (native) API calls and vice versa i.e. invoking managed callback functions from native world. This is a great step forward now because CLR is taking care of lot of complexities related to making these native API calls from managed code and vice-versa. Native APIs are written as C/C++ libraries, and before WinRT was introduced, these were consumed using Platform Invoke feature of CLR, commonly referred to as PInvoke.

With the introduction of WinRT, there has been a paradigm shift for managed developers for how they consume platform capabilities which otherwise are not already wrapped up in BCL. Let’s understand this evolution starting from its early days to latest WinRT platform. This will help you understand the internal workings of CLR and role of WinMD files too. We have come a long way with introduction of WinRT, it’s time for a little flashback.


.Net is Born!

To be able to best understand why we need Windows Runtime (WinRT) and WinMD files or how it is helpful, we need to go back a little into history and understand what kind of problems were there, before WinRT was born, which are now addressed by it. With the introduction of CLR, Microsoft developed rich metadata to describe types and their members in libraries (which is defined in ECMA-335 spec). This was a great step forward as existing libraries (DLLs) did not have a way to manifest it in themselves but we had to separately produce type library (TLB) files for components so that these components could be consumed in other applications. For example, you could write a COM component in C++ and then consume it in VB6 application. With the advent of .NET, assemblies themselves contained code as well as rich metadata, which was great as assemblies could describe its own types, members, and the external assemblies that it references (this was key feature which solved lot of DLL referencing related issues along with CLR assembly binder), which made assemblies self-contained and deployable unit. Hence, referencing and consuming these assemblies from other applications was a lot easier as compared to olden days, where referencing correct version of DLL, building code, and deploying binaries itself was a big challenge, commonly known as “DLL Hell”. The single biggest factor which helped solve DLL hell problem in .Net world was the ability to manifest all the rich metadata within the assembly (library) itself. Traditionally, components had very tight binary linking whereas CLR assemblies had metadata based linking.


PInvoke is born (Re-use existing investment)

To begin with, .Net developers did not have everything in the form of these assemblies, especially when it came to underlying low-level operating system APIs (such as APIs exposed by kernel32.dll) because, these were written and available in the form of C/C++ libraries. Microsoft did wrap certain APIs with managed wrappers over native Windows APIs, such as those for logging entries to event viewer, EventLog*classes in System.Diagnostics namespace which, are just managed wrappers over underlying native APIs. But, Microsoft could not have done it for all APIs (simply because there would be no value addition with creating and maintaining tons of managed wrappers over native APIs).

Therefore, Microsoft provided a way to enable .Net developers to consume these libraries using PInvoke. The way PInvoke works is that you would define API method signature in code and mark it as external i.e. the method implementation being available in another DLL (mentioned using attributes). Underneath, CLR would create Runtime Callable Wrapper (RCW) stub which would take care of marshalling calls between .Net Apps and native libraries. CLR would rely on method signature which you re-create in code to take care of marshalling requirements. Methods, marked as external, and type definitions re-created in source code helped CLR get the required metadata for it to be able to generate the RCW stub for marshalling and forwarding calls to libraries. In essence, metadata for native types/structures and methods was key input for CLR to make its magic and connect the two worlds.


PInvoke Limitations

PInvoke was great but it had its own limitations because there was still considerable amount of work to be done for .Net developers to recreate types in code (which were needed for the API call), define marshalling rules for these types, their memory layout, and so on (which was ugly and to make even a basic API call work, it took considerable amount of effort). Lots of these underlying APIs work with pointers whereas .Net developers don't directly work with pointers so they struggled with making API calls using PInvoke (working with IntPtr did not come easy to VB.Net or C# developers, to say the least). Although, they used familiar programming language such as VB .Net or C# but concepts were alien, such as pointers, memory layout, etc.

With PInvoke, CLR would use types and method signature created in source code to derive metadata, which it needed to create RCW stub, required for marshalling the call to native library. Lot of problems with this approach were derived from the fact that developers found it difficult to re-create method signatures and types in C#/VB code equivalents as they were required by CLR. In fact, there was a site ( available, just for managed developers, to help with signature of these native methods and types such that these can be specified in their C#/VB counterparts, and this site proved to be a great asset for .Net developers trying to make native API calls using PInvoke. I am sure every developer who has created CLR applications, would have used this site at some point in time.

Therefore, Microsoft provided a way to enable .Net developers to consume these libraries using PInvoke. The way PInvoke works is that you would define API method signature in code and mark it as external i.e. the method implementation being available in another DLL (mentioned using attributes). Underneath, CLR would create Runtime Callable Wrapper (RCW) stub which would take care of marshalling calls between .Net Apps and native libraries. CLR would rely on method signature which you re-create in code to take care of marshalling requirements. Methods, marked as external, and type definitions re-created in source code helped CLR get the required metadata for it to be able to generate the RCW stub for marshalling and forwarding calls to libraries. In essence, metadata for native types/structures and methods was key input for CLR to make its magic and connect the two worlds.

For example:

[DllImport("kernel32.dll", CharSet=CharSet.Auto, SetLastError=true)]
internal static extern IntPtr GetProcAddress([In] IntPtr hModule, [In, MarshalAs(UnmanagedType.LPStr)] string lpProcName);


WinRT to Rescue (Partially)

.Net developers had to re-create metadata in source code such as method signatures and type definitions for CLR to do RCW magic. And this was the biggest pain area for most developers. This is where WinRT makes life easy for developers as Microsoft came up with these new WinMD files which define WinRT libraries classes and methods in rich metadata format supported and understood by CLR . Now, developers don’t need to re-create method signatures in code but just add WinMD files as reference to the project.

Now, with following three things falling in place with Windows 8 (and Windows Server 2012),

1. underlying operating system providing runtime libraries (WinRT), exposing native APIs in object-oriented manner

2. rich metadata available for WinRT classes from WINMD files and

3. RCW magic of CLR already in place,

Microsoft added new WinRT Interop functionality (on top of COM Interop infrastructure) to CLR and made life easy for managed developers. Now we can consume WinRT APIs just as you would consume any other managed API (in natural and familiar manner). With Windows Runtime you don’t have to deal with pointers and lot of complexities related with native Windows APIs but they are dealt for you by CLR. You still write code in managed language which you are familiar with.

So, WinMD files enable developers to consume native APIs from .Net apps in a natural and familiar manner (which they otherwise had to do painfully using PInvoke). So this solved an existing pain area for developers and then Microsoft went a step further which enabled developers to consume these native APIs from an array of programming languages, which are traditionally not used for .Net apps development, such as JavaScript by introducing a new feature called as "language projection".

So, to answer the question as WHY Microsoft introduced new WINMD files - it was to manifest rich metadata for operating system APIs so that developers can consume these platform APIs from managed code in a natural and familiar manner. This is the reason why Microsoft says that WinRT is NOT a new layer in itself BUT only exposes underlying operating system APIs to managed world developers.


Does WinRT replace PInvoke?

WinRT does not replace PInvoke as WinRT does not cover every API supported by native Windows libraries and hence, for certain APIs you would still need to use PInvoke. Rather, WinRT is enhanced version of PInvoke minus its complexities. WinRT builds on top of existing PInvoke and COM Interop infrastructure and build on existing concepts of RCW and CCW, which is great as it is re-using existing infrastructure and at the same time reducing complexities of it.


WinRT only for .Net?

Windows Runtime libraries (for e.g. Windows.UI.dll) are not implemented in managed code but some low-level language (my guess is C++) and made available to managed code using Windows Runtime Interop (built on top of COM Interop infrastructure) and .winmd files. The types which we see in WinMD files are defined and actually implemented by these WinRT libraries. But is WinRT only available for .Net developers? Not really, WinRT libraries can be accessed from outside CLR as well, for example, when you use JavaScript to build Metro apps, you are not using CLR to host your application but “Chakra” engine, which is used by Internet Explorer too, and internally it is consuming these WinRT libraries. So that proves the point that WinRT is not just for managed developers.

In fact, you can create classic-style COM components using Windows Runtime C++ Template Library (WRL) which can consume WinRT APIs and the COM component can then be accessed from any COM enabled technology including classic desktop apps.


WinRT Duplicates APIs?

Why Windows Runtime libraries duplicate certain sets of classes, especially those related to UI controls and thread pool when these are already available with .Net Framework? Why this duplication? – This duplication is there for a reason. As we saw above, WinRT is not just for managed developers but is consumed from other application hosts as well and it became necessary to make these basic sets of classes available through WinRT too. Managed developers had some of these classes already available to them and it looks like duplication for them but these classes exist in WinRT for a reason.


WinRT for Desktop Apps

Only a subset of WinRT Classes/APIs are available to desktop apps. Also, it is important to remember that WinRT is only available Windows 8 onwards so your target platform for the desktop app must be at least Windows 8 for the ability to access WinRT APIs.

S Hanslman has written this excellent blog post which shows manual steps for how to access WinRT APIs from desktop apps.



Microsoft has introduced new set of runtime libraries for Windows platform, commonly referred to as WinRT library, which expose native functionality in object oriented manner. These new libraries are based on solid principles of COM but Microsoft has shielded developers from complexities of COM. To make it easy for developers to interact with this underlying platform library, Microsoft developed WinMD files and supporting interop functionality to different runtime environments such as CLR and Chakra engine so that developers can consume these libraries from different languages (Java Script, VB .NET, C#, C++, etc) in natural and familiar manner. WinRT and its interop with runtime environments makes platform capabilities available to an array of programming languages in natural and familiar manner.


In my next blog post, I will try to go further into this new magical world of WinRT and further explore its internal working.

Happy Coding.

Vande Mataram!

(A salute to motherland)

P.S. In addition to blogging, I use Twitter to share tips, links, etc. My Twitter handle is: @girishjjain

Metro Apps Text Styles in VS 2012

clock November 30, 2012 15:52 by author Girish Jain

When you create a new Metro style App project in Visual Studio 2012 it also adds a static resource dictionary file to the project, Standardtyles.xaml under Common folder. This file defines many styles for different controls such as TextBlock, Button, etc. These are handy to produce consistent look-n-feel for Metro style apps.

While developing a new Metro Style App for Windows 8 in Visual Studio 2012 I was trying to pick the right text style. Only way was to actually use the style and then see if it suits the purpose. I rather ended up creating another page in the app where I created texts using all these pre-defined styles for quick reference. Am sharing it here on the blog for everyone's quick reference:

Hope you find it useful! Happy Coding!

Vande Mataram!

(A salute to motherland)

P.S. In addition to blogging, I use Twitter to share quick posts, tips, links, etc. My Twitter handle is: @girishjjain

WINMD Files Under the Hood

clock October 13, 2012 00:04 by author Girish Jain


I have recently installed Windows 8 on my laptop and am having a go with new Windows 8 operating system and the newly introduced Windows Runtime (WinRT) layer. As part of this blog post, I am going to dig deep into WINMD files, which are at the heart of this new WinRT layer.


WINMD File Format

First of all I wanted to understand more about file format of WINMD files. I wanted to know more internal detail about this new file extension so I decided to check it with the old friend DUMPBIN.exe utility using following command:

D:\DDrive\Girish\temp>dumpbin /HEADERS /CLRHEADER 
"C:\Windows\System32\WinMetadata\Windows.System.winmd" /OUT:output.txt


Great news, it worked with dumpbin.exe! I was happy to see that it worked with dumpbin.exe tool (as that confirmed that the file format is familiar) and the tool did give lot of information about the file as well. Find below the output of same, I have highlighted certain key aspects of same:

Dump of file C:\Windows\System32\WinMetadata\Windows.System.winmd

PE signature found

File Type: DLL

             14C machine (x86)
               1 number of sections
        5010588C time date stamp Wed Jul 25 21:35:24 2012
               0 file pointer to symbol table
               0 number of symbols
              E0 size of optional header
            2102 characteristics
                   32 bit word machine

             10B magic # (PE32)
           11.00 linker version
               0 size of code
               0 size of initialized data
               0 size of uninitialized data
               0 entry point
               0 base of code
               0 base of data
          400000 image base (00400000 to 00405FFF)
            1000 section alignment
             200 file alignment
            6.02 operating system version
            0.00 image version
            6.02 subsystem version
               0 Win32 version
            6000 size of image
             200 size of headers
           127B8 checksum
               3 subsystem (Windows CUI)
             540 DLL characteristics
                   Dynamic base
                   NX compatible
                   No structured exception handler
          100000 size of stack reserve
            1000 size of stack commit
          100000 size of heap reserve
            1000 size of heap commit
               0 loader flags
              10 number of directories
               0 [       0] RVA [size] of Export Directory
               0 [       0] RVA [size] of Import Directory
               0 [       0] RVA [size] of Resource Directory
               0 [       0] RVA [size] of Exception Directory
               0 [       0] RVA [size] of Certificates Directory
               0 [       0] RVA [size] of Base Relocation Directory
               0 [       0] RVA [size] of Debug Directory
               0 [       0] RVA [size] of Architecture Directory
               0 [       0] RVA [size] of Global Pointer Directory
               0 [       0] RVA [size] of Thread Storage Directory
               0 [       0] RVA [size] of Load Configuration Directory
               0 [       0] RVA [size] of Bound Import Directory
               0 [       0] RVA [size] of Import Address Table Directory
               0 [       0] RVA [size] of Delay Import Directory
            1000 [      48] RVA [size] of COM Descriptor Directory
               0 [       0] RVA [size] of Reserved Directory

   .text name
    45D0 virtual size
    1000 virtual address (00401000 to 004055CF)
    4600 size of raw data
     200 file pointer to raw data (00000200 to 000047FF)
       0 file pointer to relocation table
       0 file pointer to line numbers
       0 number of relocations
       0 number of line numbers
40000020 flags
         Read Only

  clr Header:

              48 cb
            2.05 runtime version
            1050 [    4580] RVA [size] of MetaData Directory
               1 flags
                   IL Only
               0 entry point token
               0 [       0] RVA [size] of Resources Directory
               0 [       0] RVA [size] of StrongNameSignature Directory
               0 [       0] RVA [size] of CodeManagerTable Directory
               0 [       0] RVA [size] of VTableFixups Directory
               0 [       0] RVA [size] of ExportAddressTableJumps Directory
               0 [       0] RVA [size] of ManagedNativeHeader Directory


        5000 .text


As you can see from the highlighed parts, it is clear that:

1. WINMD files are standard PE/COFF format files.

2. WINMD files are standard Win-32 DLL files.

3. WINMD files contain CLR headers as well which means WINMD files comply with ECMA-335 CLI specification for file format and hence, contain rich metadata (which means they are not just native Win 32 DLLs but contain rich metadata just like any other CLR assembly)

In simple terms, WINMD files are DLL files (or CLR assemblies) with rich .Net framework metadata to expose underlying Windows operating system APIs.


Disassemble WINMD Files

Now we know that WINMD files comply ECMA-335 CLI specification for file format and hence, they are .Net assemblies. In that case, we should be able to open these using ILDAsm (IL Disassembler) tool or Reflector. I tried to open Windows.System.winmd file and I was able to open it in ILDASM, refer below screenshot:

Remember, you have to use latest version of ILDAsm supplied with Visual Studio 2012 as previous versions would not work with WINMD files.

Excellent! Now you would think that you can browse through all the types and methods and method IL code but there is a surprise. When you try to open any method body you will get to see below:

.method public hidebysig newslot virtual final 
        instance void  Enable() runtime managed
  .override Windows.System.Threading.Core.ISignalNotifier::Enable
} // end of method SignalNotifier::Enable


You will notice that there is no IL code in the method body and the method is marked with runtime managed flag, to understand the meaning of the flag we will need to refer ECMA-335 Common Language Infrastructure (CLI) specification.

Find below extract from ECMA-335 Common Language Infrastructure (CLI) specification. for method flags:

Runtime 0x0003 Method impl is provided by the runtime
Managed 0x0000 Method impl is managed
... ... ...


It tells us that runtime managed means method does not have a body AND the managed implementation will be provided by runtime. This brings us to following conclusion that WINMD files (under C:\Windows\System32\WinMetadata folder) do not contain code but metadata only. Since these files do not contain code but rich metadata only hence, that also explains why these files are so small in size.


WINMD and no code?

Does it mean that WINMD files cannot contain code? Not really. Usually, WINMD files will not contain code but not that they cannot. Usually, WINMD files will only contain rich metadata but if you create a new custom windows runtime component of your own using Visual Studio 2012, it will produce a WINMD file and it will contain both, code and rich metada and you will be able to verify the same using ILDAsm tool.



1. WINMD stands for Windows Meta Data and as the name suggests these files contain rich metadata for Windows operating system APIs, making these APIs available to managed world.

2. WINMD files use DLL file format but with a different extension. Question is why did Microsoft choose to create a new file extension (WINMD) and not reuse existing DLL extension? I believe the reason would be that WINMD files can contain just metadata unlike traditional DLL files which are generally used as library of functions and therefore contain code too. Nonetheless, WINMD files are DLL files.

3. WINMD files contain CLR header and rich metadata about its types, methods, etc. and hence, these files are .Net Framework assemblies. This makes Windows APIs available to managed world in a natural and familiar manner.

4. Lastly, as we saw that these meta data only files do not contain code, it tells me that WinRT is NOT a new layer in itself but, exposes the underlying Windows operating system API layer to managed world (more about this in future post).

In my next blog post, we will go further into this new world of Windows Runtime (WinRT) introduced with Windows 8.

Happy Coding!!

Vande Mataram!

(A salute to motherland)

P.S. In addition to blogging, I use Twitter to share tips, links, etc. My Twitter handle is: @girishjjain

About the author

Girish Jain works on Microsoft .Net framework technologies and is a big fan of WPF, WCF, and LINQ technologies. He is currently based in India with his wife and a daughter. When not spending time with family, Girish enjoys creating small tools, utilities, frameworks to improve developer productivity.

Sign In