Co-Hosting Orleans and ASP.NET Core

Orleans and ASP.NET Core

With the release of Orleans 3.0 comes the ability to co-host with ASP.NET Core (or any other framework that uses the generic host builder).

What this means is you can run Orleans and ASP.NET Core in the same process.

The advantage to this is both services will share the same service provider, logging, etc that is configured with the host builder.

Orleans and ASP.NET Core

The extension method UseOrleans() is available now on the IHostBuilder. Just like you would configure the ASP.NET Core via ConfigureWebHostDefaults, you can configure the Orleans silo.


One of the nice benefits here is that because both services share service registrations, an ASP.NET Core MVC controller can have the IClusterClient injected into it.

Also since logging is configured it is shared between both ASP.NET Core and Orleans. When I run my demo application, you can see both services in my console logs.

Health Checks

Another benefit of co-hosting Orleans and ASP.NET Core is you can provide a frontend via ASP.NET Core to expose status of your Orleans silo. I’ve written about the ASP.NET Core Health Checks over on the Telerik Blog.

If you’re running in something Docker, AWS ECS or Kubernetes, this would provide you information to determine the health/liveness of your services

Orleans 3.0

If you want more info on the 3.0 release, check out the Announcement for all the details.

Also, check out other related posts:

Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.

Building .NET Core 3 under a Linux TeamCity Agent

TeamCity Agent

I recently needed to (re)build a new TeamCity agent under Linux to build a .NET Core project. There wasn’t anything overly complicated but I figured I’d post everything I had to do in one spot since you have to dig around various/documentation to get it all working.

Hopefully, this helps anyone (including myself) in the future that needs to build a Linux TeamCity Agent for building a .NET Core app.

I’m using an EC2 instance in AWS using the Ubuntu 18.04 image. This is important because all the following steps are based around that and there are differences if you are using different distro or version of Ubuntu.

TeamCity Agent

The first step is to install the TeamCity Agent, you need a few packages before we can even do that including OpenJDK. The agent itself is just in a zip file you can download from your TeamCity server.

The next step is to configure the build agent to connect to your TeamCity Server, eg http://{TeamCityHostName}:{Port}. To do so, modify the with the correct values.


To create a start/stop script, you’ll create a new file /etc/init.d/teamcity with the following contents. Make sure to replace the USER and the path to the buildAgent directory we unzipped earlier.

Once that’s done, make sure the file is executable and we’ll configure the default priorities.


To install the .NET Core SDK is pretty straight forward.


As a bonus, here’s how to install Mono. I also needed this to run my Cake build scripts.

Hopefully, you find this useful. If there any steps or any additional sdk’s that should be included please let me know in the comments or on Twitter. I suspect I’ll create a docker image and put this on Docker Hub if anyone has any interest.

Related: Using Date Version Numbers for Assemblies in TeamCity

Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.

Roundup #57: Dapr, .NET Core API Porting, EF Core 3 NETStandard2, ASP.NET Core Best Practices

Here are the things that caught my eye recently in .NET.  I’d love to hear what you found most interesting this week.  Let me know in the comments or on Twitter.

Announcing Distributed Application Runtime (Dapr)

Dapr is an open source, portable, event-driven runtime that makes it easy for developers to build resilient, microservice stateless and stateful applications that run on the cloud and edge. Dapr embraces the diversity of all programming languages and developer frameworks and simplifies building applications such as the e-commerce example.


.NET Core 3.0 concludes the .NET Framework API porting project

We started in .NET Core 1.0 with a very minimal API set that only included ~18K of the .NET Framework APIs. With .NET Standard 2.0, we tried to make it much more viable to share code between .NET Framework, .NET Core, and Xamarin which resulted in approximately 38K .NET Frameworks APIs being available in .NET Core 2.0. We also built the Windows Compatibility Pack which made another 21K .NET Framework APIs available to .NET Core, resulting in almost 60K additional APIs. And in .NET Core 3.0 we added WPF and WinForms, which increased the number of .NET Framework APIs ported to .NET Core to over 120k, which is more than half of all .NET Framework APIs.


EF Core 3 to target .NET Standard 2.0

The feedback from you and others is that EF Core made the jump to .NET Standard 2.1 too soon. A lot of apps are still transitioning to .NET Core, and the ecosystem of libraries (especially WinForms and WPF) is also still translationing. Even UWP and Unity aren’t ready for .NET Standard 2.1 yet.

After investigating this, we discovered that a lot more of corefx has been backported to .NET Standard 2.0 than we originally anticipated when we made the decision to target .NET Standard 2.1.

Given your feedback and the unexpectedly low cost of maintenance–remember, we’re just a small team of five engineers–we decided it was probably worth implement this.

We hope that one last LTS release on .NET Standard 2.0 will give everyone a chance to catch up to the vision of .NET 5.


ASP.NET Core Performance Best Practices

I never noticed this portion of the docs and found it really interesting to see some best practices, particularly around the performance reliability. I really like the DO vs DO NOT examples.


Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.