In this episode of the m365.fm podcast, Mirko Peters talks with Microsoft MVP Gábor Ruzsinszki about the evolution of modern .NET development, from legacy WPF desktop applications to ASP.NET Core, cloud-native architectures, and gRPC services.

Gábor shares his journey from teaching IT and programming to becoming a software architect specializing in C# and .NET. He explains how .NET has transformed from a Windows-only framework into a fast, cross-platform ecosystem used for cloud services, APIs, IoT, and enterprise applications. He highlights major performance improvements in recent .NET releases and discusses how upgrading frameworks alone can significantly improve application speed.

A large part of the conversation focuses on WPF and why many enterprise companies still rely on it today. Gábor explains the strengths of WPF, its XAML-based architecture, and how it influenced newer technologies like .NET MAUI and WinUI. He also compares alternatives such as Avalonia and Uno Platform while discussing migration challenges for large legacy systems.

The episode then shifts to ASP.NET Core and modern backend development. Gábor explains the rise of SaaS platforms, microservices, and Minimal APIs, sharing when lightweight APIs make sense and when traditional controller-based architectures are still the better choice. He also discusses software architecture patterns, modular monoliths, and the complexity of microservices.

Another key topic is gRPC, where Gábor explains how it differs from REST APIs and why many teams adopt it for high-performance backend communication.

Finally, the conversation explores AI tools like GitHub Copilot, emphasizing that developers still need strong architectural thinking and communication skills in the AI era.

Apple Podcasts podcast player iconSpotify podcast player iconYoutube Music podcast player iconSpreaker podcast player iconPodchaser podcast player iconAmazon Music podcast player icon

You experience modern .net development by connecting wpf, web, and gRPC. The m365.fm Modern .NET Development Podcast brings expert insights from Mirko Peters and Gábor Ruzsinszki. You see practical benefits when you combine wpf desktop apps with web solutions and high-performance gRPC services. You often face challenges like data synchronization and user experience. For example, you might migrate a legacy wpf application to asp.net core mvc and use gRPC for fast communication. Many enterprises choose asp.net core for web development because it offers strong performance and seamless integration. You need modern .net development skills to keep your projects current and efficient.

Key Takeaways

  • Integrate WPF, ASP.NET Core, and gRPC for a unified solution that enhances performance and scalability.
  • Use shared libraries to maintain consistent business logic across WPF and ASP.NET applications, reducing code duplication.
  • Modernize legacy applications by migrating to ASP.NET Core and utilizing gRPC for fast communication.
  • Leverage the cross-platform capabilities of .NET Core to deploy applications on Windows, Linux, and macOS.
  • Implement strong security measures, including HTTPS and token-based authentication, to protect your applications.
  • Adopt CI/CD pipelines to automate testing and deployment, ensuring faster and more reliable releases.
  • Utilize design patterns like Dependency Injection and MVVM to improve code maintainability and testability.
  • Stay updated with the latest .NET resources, including podcasts and official documentation, to enhance your development skills.

Modern .NET Development Integration

Benefits and Challenges

You see many benefits when you integrate WPF, asp.net core mvc, and grpc in your projects. This approach gives you a unified solution for desktop, web, and service communication. The m365.fm Modern .NET Development Podcast, hosted by Mirko Peters and featuring Microsoft MVP Gábor Ruzsinszki, often highlights how this integration helps you build modern, scalable applications.

Here is a table that shows the main benefits of combining these technologies:

BenefitDescription
Performanceasp.net core is among the fastest web frameworks. It supports HTTP/2 and grpc for efficient communication.
ScalabilityIntegration allows you to build microservices and RESTful APIs. This enhances the scalability of your applications.
Cross-Platform CapabilitiesWPF for desktop and asp.net core for web applications give you a unified development experience across platforms.

You also face some challenges. You need to manage data synchronization between WPF and asp.net core mvc. You must ensure a consistent user experience across desktop and web. Security and authentication become more complex when you use grpc on asp.net core for communication between services. You must also handle versioning and updates for each part of your solution.

Tip: You can use shared libraries to keep your business logic consistent across WPF, asp.net core mvc, and grpc on asp.net core. This reduces code duplication and helps you maintain your solution.

Real-World Scenarios

You can learn a lot from real-world examples. Many organizations have migrated legacy WPF applications to asp.net core mvc and grpc on asp.net core. These migrations show you how to modernize your software and improve performance.

Here is a table with some examples:

OrganizationMigration DetailsKey Focus
Abto SoftwareMigrated a desktop healthcare analysis tool (WPF) to the web (Blazor WASM). 300K LOC. Kept the C# calculation engine (shared library) but rewrote the UI.Performance was critical.
Amazon Q DeveloperTransformed a Windows-only desktop app into a modern, cross-platform web application using existing WPF desktop samples.Handling complex legacy code.

You might start with a WPF desktop app that your users rely on every day. You want to reach more users, so you build a web version using asp.net core mvc. You use grpc on asp.net core to connect your desktop and web apps to shared backend services. This setup lets you reuse your business logic and keep your data in sync.

You can also use grpc to connect microservices in your solution. grpc on asp.net core gives you fast, reliable communication between services. This is important when you need real-time updates or high performance.

When you follow these integration patterns, you create flexible and future-proof solutions. You can add new features, support more platforms, and scale your applications as your needs grow.

.NET Evolution and Modernization

.NET Framework to .NET Core

You have seen .NET change a lot over the years. The move from .NET Framework to .NET Core brought big improvements for developers and businesses. When you use .NET 6 or .NET 7, your applications run faster and use less memory than older versions. You notice better throughput and shorter execution times, which helps when you build high-traffic web apps. Optimized execution engines and new runtime features make your code more efficient. Each new release brings more speed and better memory management. You can also deploy your apps on different operating systems, which makes your work easier.

Here is a table that shows the main differences in deployment and maintenance between .NET Framework and .NET Core:

Aspect.NET Framework.NET Core
Deployment FlexibilityLimited to IIS or Windows ServerSupports self-contained deployments and cloud hosting
Cost EfficiencyRequires Windows licensing and proprietary hostingSupports Linux, reducing infrastructure costs
MaintenancePrimarily closed-source with limited updatesOpen-source with active community support and frequent updates
Performance ImprovementsLess frequent updatesContinuous performance improvements and security fixes

Cross-Platform and Cloud-Native

You can now build and run .NET applications on Windows, Linux, and macOS. This cross-platform flexibility gives you more choices for deployment. You can use microservices and containers to split your applications into smaller parts. This makes it easier to scale and update your solutions. Deep integration with Azure lets you use tools and services made for .NET developers. You can also use serverless computing with Azure Functions, which means you focus on your code and not on managing servers. These features help you build high-performance, scalable apps that work well in the cloud. The strong developer ecosystem and modern tools make your work faster and more reliable.

Modernizing Legacy Apps

You may have legacy applications that need updates to stay useful and secure. Modernizing legacy applications starts with a clear plan. First, list all your dependencies, such as third-party libraries and internal DLLs. Next, look for old patterns like WebForms pages or Forms Authentication. Check your code quality and find tightly coupled parts or outdated APIs. Then, decide if you want to rewrite parts of your app or replace old libraries. Move to modern ASP.NET technologies like Razor Pages or ASP.NET Core MVC. Adopt new practices such as dependency injection, automated testing, and CI/CD pipelines. Use tools like .NET Upgrade Assistant to help with the process.

Modernizing legacy applications can take time and resources. For a single business app with 50,000 to 100,000 lines of code, you might spend four to six months. Costs often range from $100K to $1M, with a median of about $180K. If you manage a legacy application portfolio with many apps, the process may last two to three years, broken into smaller projects. You gain better performance, security, and easier maintenance when you modernize your legacy systems.

Modernize WPF Desktop Applications

WPF in Enterprise Development

You use WPF to build desktop applications quickly. Visual Studio gives you tools to design and code with ease. Many organizations choose WPF because it simplifies deployment. You can distribute apps through shared drives or ClickOnce installers. This makes WPF a favorite for internal tools and rapid prototyping.

WPF excels when you need high graphic performance and responsiveness. You handle large datasets or complex visualizations with WPF. It stands out as a strong alternative to web-based technologies.

Microsoft continues to develop WPF. You see new features like hardware acceleration and Fluent theme for modern UI design. WPF fits critical line-of-business applications in many industries. You find WPF in about 500,000 to 1,000,000 actively developed applications worldwide. You create and deploy apps fast with WPF, needing less setup than other tech stacks.

Migration Strategies

You often need to modernize legacy Windows Presentation Foundation applications. You want to modernize WPF desktop applications to take advantage of new .NET features.

.NET Core/5+/6+/8+ Migration

You start by backing up your projects. You install the .NET Upgrade Assistant. You right-click your project in Solution Explorer and select Upgrade. You choose between in-place or side-by-side upgrades. You pick the target framework and components to upgrade.

You set up your environment with Visual Studio 2019 and .NET Core 3.0. You check API compatibility using .NET Portability Analyzer. You create a new .csproj file for your project. You specify the assembly name and default namespace. You suppress auto generation of AssemblyInfo.

Tools you use for migration include:

Uno Platform for Cross-Platform

You modernize WPF by exploring cross-platform solutions. Uno Platform lets you run WPF-like apps on Windows, Linux, macOS, iOS, Android, and WebAssembly. You reuse your business logic and UI components. You reach more users and devices with less effort. Uno Platform helps you modernize your desktop apps for a wider audience.

Integration with ASP.NET and gRPC

You modernize WPF desktop applications by connecting them to web and service technologies. You use ASP.NET Core to build web APIs and user interfaces. You use gRPC for fast, reliable communication between your desktop app and backend services. You share business logic across WPF, ASP.NET, and gRPC. You keep your data in sync and improve performance. You modernize your workflow by integrating WPF with modern web and service stacks.

ASP.NET Core MVC for Web Apps

ASP.NET Core Overview

You use asp.net core mvc to build modern web applications that are fast, secure, and easy to maintain. This framework gives you a unified way to create both web user interfaces and APIs. You can run your asp.net core application on Windows, Linux, or macOS. The cross-platform nature of asp.net core means you can deploy your apps in many environments, including the cloud.

Here is a table that shows the core features that make asp.net core mvc a strong choice for web development:

FeatureDescription
Unified development modelSingle framework for both web UIs and APIs.
ScalabilityLightweight, modular architecture capable of handling over 7 million requests per second.
Security featuresBuilt-in protection against CSRF, XSS, and SQL injection, along with enterprise-grade authentication.
Development efficiencyUnifies MVC and Web API into a single programming model, reducing learning curves and maintenance.
Deployment flexibilityCross-platform nature and excellent Docker support for consistent deployments across environments.
MVC FoundationUtilizes the Model-View-Controller architectural pattern for clear separation of concerns.

You start getting started with asp.net core by installing the .NET SDK and setting up your first project. The asp.net core setup process is simple and well-documented. You can use Visual Studio or the command line to create your asp.net core mvc project.

Building APIs

You build APIs with asp.net core mvc to connect your web apps, mobile apps, and desktop clients. The framework supports RESTful design, which helps you organize your endpoints and data models. You can use controllers to handle requests and return data in JSON format. This makes it easy for other applications to use your API.

To create scalable and maintainable APIs, you should follow these best practices:

  • Structure your project using Clean Architecture. Organize your code with Controllers, Services, Repositories, and Models or DTOs.
  • Use Async and Await for I/O operations. This improves performance and lets your app handle more users at once.
  • Add global exception handling with middleware. This helps you manage errors in one place.
  • Enable API versioning. This keeps your APIs compatible with different clients.
  • Use logging to track errors and important actions.

You can connect your asp.net core mvc APIs to other services, such as gRPC or WPF clients. This lets you build powerful solutions that work across platforms.

Security and Authentication

You protect your asp.net core application by using built-in security features. The framework guards against common threats like CSRF, XSS, and SQL injection. You can add authentication and authorization to control who can access your APIs. Many developers use JWT tokens to secure endpoints and protect sensitive data.

You should always keep your asp.net core application updated. Regular updates help you fix security issues and improve performance. You can also use middleware to manage authentication and authorization across your entire app.

Tip: Secure your APIs with strong authentication and keep your dependencies up to date. This helps you build safe and reliable web applications.

Deployment Options

You have many ways to deploy your ASP.NET Core MVC applications. Each option gives you different benefits. You should choose the one that fits your project needs and your team's skills.

1. On-Premises Deployment

You can deploy your app on your own servers. This method gives you full control over your environment. You install IIS (Internet Information Services) on Windows or use Kestrel with a reverse proxy like Nginx or Apache on Linux. You manage updates, security, and scaling yourself.

Tip: Use Kestrel for high performance. Pair it with Nginx or Apache to handle HTTPS and load balancing.

2. Cloud Deployment

You can deploy your app to the cloud. Popular choices include Microsoft Azure, Amazon Web Services (AWS), and Google Cloud Platform (GCP). Cloud platforms offer easy scaling, high availability, and managed services.

Cloud PlatformKey FeaturesExample Service
AzureDeep .NET integration, App Service, FunctionsAzure App Service
AWSFlexible compute, global reachAWS Elastic Beanstalk
GCPContainer support, managed VMsGoogle App Engine

You can use Azure App Service to deploy your app with just a few clicks. You upload your code, and Azure handles the rest. You can also use Azure DevOps for automated deployments.

3. Containerization with Docker

You can package your app in a Docker container. This method makes your app portable and easy to deploy anywhere. You write a simple Dockerfile to define your app's environment.

FROM mcr.microsoft.com/dotnet/aspnet:8.0
COPY . /app
WORKDIR /app
ENTRYPOINT ["dotnet", "YourApp.dll"]

You build and run your container locally, then push it to a container registry. You can deploy containers to Kubernetes or cloud services like Azure Kubernetes Service (AKS).

4. Continuous Integration and Continuous Deployment (CI/CD)

You can automate your deployment process with CI/CD pipelines. Tools like GitHub Actions, Azure DevOps, and GitLab CI help you build, test, and deploy your app automatically.

Note: CI/CD reduces errors and speeds up your release cycle. You can roll back changes quickly if something goes wrong.

5. Cross-Platform Hosting

You can host ASP.NET Core MVC apps on Windows, Linux, or macOS. This flexibility lets you choose the best environment for your needs.

Summary Table: Deployment Options

OptionControl LevelScalabilityEase of SetupBest For
On-PremisesHighManualModerateFull control, compliance
CloudMediumAutomaticEasyFast scaling, less setup
ContainersHighAutomaticModeratePortability, microservices
CI/CDMediumAutomaticEasyFast releases, automation

You should review your requirements before choosing a deployment method. Each option has strengths. You can combine them for even better results. For example, you can use containers in the cloud with CI/CD pipelines for fast, reliable deployments.

gRPC in .NET

What is gRPC

You use grpc to build fast and reliable communication between your applications. grpc stands for Google Remote Procedure Call. It is an open-source framework that lets you call methods on a server from a client as if they were local. You can use grpc for high-performance remote procedure call scenarios. This means you send and receive data quickly, even when your apps run on different machines.

grpc uses Protocol Buffers, a language-neutral and platform-neutral way to serialize data. You define your service contracts in a .proto file. This file describes the messages and services you want to use. You generate code for your client and server from this file. You can use grpc in many types of applications, including wpf desktop apps, asp.net web apps, and cloud services.

gRPC vs REST

You might wonder how grpc compares to REST. REST uses HTTP and JSON to send data between clients and servers. grpc uses HTTP/2 and Protocol Buffers. This gives you better performance because HTTP/2 supports multiplexing and streaming. Protocol Buffers create smaller messages than JSON, so your data moves faster.

Here is a table to help you compare grpc and REST:

FeatureREST (JSON)gRPC (Protocol Buffers)
Data FormatJSONProtocol Buffers
TransportHTTP/1.1HTTP/2
PerformanceGoodBetter performance
StreamingLimitedFull support
ContractOpenAPI/Swagger.proto files

You choose grpc when you need highly scalable systems or real-time communication. You use REST when you want simple APIs that work with browsers. Many developers use both in the same solution.

Setting Up gRPC Services

You set up grpc services in .NET with a few steps. First, you create a new project in Visual Studio or with the .NET CLI. You select the "gRPC Service" template. This template gives you a sample .proto file and the code to start your service.

You define your service and messages in the .proto file. For example:

syntax = "proto3";

service Greeter {
  rpc SayHello (HelloRequest) returns (HelloReply);
}

message HelloRequest {
  string name = 1;
}

message HelloReply {
  string message = 1;
}

You build your project. The tools generate C# classes for your grpc client and server. You implement your service logic in C#. You can host grpc services in asp.net core or even inside a wpf app for advanced scenarios.

To test your grpc services, you use tools like grpc-dotnet, Grpc.Net.Client, and Grpc.AspNetCore.Server. These libraries help you build, host, and consume grpc services in .NET. You can also use FINT for testing your grpc endpoints.

You connect your wpf client or asp.net app to your grpc services by adding the generated client code. This lets your apps talk to each other quickly and securely. You can migrate from older technologies like WCF to grpc for a modern, scalable solution.

Tip: Use grpc when you need fast, reliable, and highly scalable communication between your .NET applications.

Consuming gRPC in WPF and ASP.NET

You can connect your WPF and ASP.NET Core applications to gRPC services. This lets you share data and business logic across desktop and web apps. You get fast, reliable communication that works well for modern solutions.

WPF Client Integration

You can add gRPC to your WPF desktop app. Start by installing the Grpc.Net.Client NuGet package. This package gives you the tools to call gRPC services from your WPF project.

Follow these steps to set up a gRPC client in WPF:

  1. Add the .proto file
    Place the .proto file from your gRPC service into your WPF project. Set its build action to "Protobuf" in the project file.

  2. Install NuGet packages
    Open the NuGet Package Manager. Install Grpc.Net.Client and Google.Protobuf.

  3. Configure the gRPC client
    Create a channel and client in your code. For example:

    using Grpc.Net.Client;
    using Greet;
    
    var channel = GrpcChannel.ForAddress("https://localhost:5001");
    var client = new Greeter.GreeterClient(channel);
    var reply = await client.SayHelloAsync(new HelloRequest { Name = "WPF User" });
    MessageBox.Show(reply.Message);
    
  4. Handle threading
    Use async and await to keep your UI responsive. Do not block the main thread.

Tip: You can share data models between your WPF and ASP.NET Core projects by using shared libraries. This keeps your code clean and consistent.

ASP.NET Client Integration

You can also use gRPC clients in your ASP.NET Core applications. This is useful when your web app needs to call other services, such as microservices or backend APIs.

Here is how you set up a gRPC client in ASP.NET Core:

  1. Add the .proto file
    Include the .proto file in your ASP.NET Core project. Set its build action to "Protobuf".

  2. Install NuGet packages
    Add Grpc.Net.ClientFactory and Google.Protobuf using NuGet.

  3. Register the gRPC client
    In your Startup.cs or Program.cs, register the client with dependency injection:

    builder.Services.AddGrpcClient<Greeter.GreeterClient>(o =>
    {
        o.Address = new Uri("https://localhost:5001");
    });
    
  4. Inject and use the client
    Inject the client into your controller or service:

    public class HomeController : Controller
    {
        private readonly Greeter.GreeterClient _greeterClient;
    
        public HomeController(Greeter.GreeterClient greeterClient)
        {
            _greeterClient = greeterClient;
        }
    
        public async Task<IActionResult> Index()
        {
            var reply = await _greeterClient.SayHelloAsync(new HelloRequest { Name = "Web User" });
            ViewBag.Message = reply.Message;
            return View();
        }
    }
    

Note: You can use gRPC clients in background services, controllers, or any part of your ASP.NET Core app.

You can now connect your WPF and ASP.NET Core apps to the same gRPC backend. This gives you a unified and high-performance solution for your business needs.

Practical Integration Walkthrough

Solution Architecture

You can build a modern solution by connecting wpf, asp.net core mvc, and grpc. This architecture helps you deliver a seamless experience across desktop and web. You start with a wpf desktop application. You add asp.net core mvc for your web interface. You use grpc to connect both clients to your backend services.

Here is a simple diagram to help you understand the structure:

LayerTechnologyPurpose
Desktop ClientwpfRich user interface for Windows
Web Clientasp.net core mvcWeb-based UI for browsers
Communication LayergrpcFast, typed communication between layers
Backend Servicesasp.net coreBusiness logic, data access, APIs

You can use this setup for many scenarios. For example, you can modernize a legacy wpf app by adding asp.net core mvc and grpc. You can also build new solutions that need both desktop and web clients. This architecture works well for microservices because grpc supports high-speed communication.

Tip: You can share business logic between wpf, asp.net core mvc, and asp.net core by using shared libraries. This keeps your code clean and reduces duplication.

Creating gRPC Service in ASP.NET Core

You can create a simple grpc service in asp.net core. This service will let your wpf and asp.net core mvc clients talk to your backend. You start by opening Visual Studio and creating a new project. Choose the "gRPC Service" template. This template gives you everything you need to get started.

Follow these steps:

  1. Open Visual Studio and select "Create a new project."
  2. Choose "gRPC Service" and click Next.
  3. Name your project and select asp.net core 8.0 or later.
  4. Click Create.

You will see a sample "Greeter" service in your project. The service uses a .proto file to define the contract. You can edit this file to add your own methods and messages.

Here is an example of a .proto file:

syntax = "proto3";

service Greeter {
  rpc SayHello (HelloRequest) returns (HelloReply);
}

message HelloRequest {
  string name = 1;
}

message HelloReply {
  string message = 1;
}

You implement the service in C#. The template gives you a GreeterService.cs file. You can add your logic there.

public class GreeterService : Greeter.GreeterBase
{
    public override Task<HelloReply> SayHello(HelloRequest request, ServerCallContext context)
    {
        return Task.FromResult(new HelloReply
        {
            Message = $"Hello, {request.Name}"
        });
    }
}

You run your asp.net core project. The grpc service listens for requests from your clients. You can now connect your wpf and asp.net core mvc apps to this service.

Note: grpc uses HTTP/2, so make sure your server supports it. Visual Studio handles this for you when you use the template.

Consuming gRPC in WPF

You can connect your wpf application to your grpc service. This lets your desktop app use the same backend as your web app. You start by adding the .proto file to your wpf project. Set its build action to "Protobuf."

Follow these steps to set up the client:

  1. Install the Grpc.Net.Client and Google.Protobuf NuGet packages.
  2. Add the .proto file to your project.
  3. Create a grpc channel in your code.

Here is a sample code snippet:

using Grpc.Net.Client;
using Greet;

var channel = GrpcChannel.ForAddress("https://localhost:5001");
var client = new Greeter.GreeterClient(channel);
var reply = await client.SayHelloAsync(new HelloRequest { Name = "WPF User" });
MessageBox.Show(reply.Message);

You use async and await to keep your wpf app responsive. You can call grpc methods from your view models or services. This approach lets you share data and logic between your wpf and asp.net core mvc clients.

Tip: You can reuse your data models by placing them in a shared library. This makes it easier to keep your wpf and asp.net core mvc projects in sync.

You now have a solution where wpf and asp.net core mvc both use grpc to talk to your backend. This setup gives you speed, reliability, and a modern architecture.

Data Contracts and Protobuf

You define data contracts in gRPC using Protocol Buffers, also known as Protobuf. Protobuf lets you describe the structure of your messages in a .proto file. This file acts as a contract between your client and server. You use it to generate C# classes that both sides understand.

When you add a .proto file to your .NET project, you need to configure it correctly. The table below shows the main settings you use:

ConfigurationDescription
<Protobuf> IncludeAdds the .proto file to your project.
GrpcServices AttributeControls which C# assets get generated: Both, Server, Client, or None.

You should keep your .proto files simple and clear. Use clear names for your messages and fields. Avoid using reserved words or special characters. Always use version numbers in your message names or package names if you plan to update your contracts in the future.

Here are some best practices for working with Protobuf in .NET:

  • Place your .proto files in a shared folder or library. This helps you keep your contracts in sync across WPF, ASP.NET Core, and other projects.
  • Use the Both option for GrpcServices if you want to generate both client and server code from the same .proto file.
  • Keep your data types simple. Use basic types like string, int32, or bool for most fields.
  • Add comments to your .proto files. Comments help other developers understand your contracts.

Tip: When you update a .proto file, make sure you regenerate the C# code in all projects that use it. This keeps your client and server in sync.

Error Handling and Logging

You need strong error handling and logging to keep your .NET applications reliable. When you use WPF, ASP.NET Core, and gRPC together, you should follow a few key strategies:

  • Set up global exception handlers in both ASP.NET Core and WPF. This helps you catch errors that might otherwise go unnoticed.
  • Use centralized logging. This makes it easier to track problems and maintain your code.
  • In ASP.NET Core, use the IExceptionHandler interface to handle exceptions across your entire app.
  • In WPF, create a global exception handler to catch unhandled errors and log them.
  • Always log important events, errors, and warnings. Use tools like Serilog, NLog, or built-in logging providers.
  • Make sure your logs include enough detail to help you find and fix issues quickly.

Note: Good error handling and logging help you spot problems early. They also make your applications easier to support and improve over time.

Authentication and Security

Securing gRPC Services

You need to secure your grpc services to protect your data and users. Start by using HTTPS for all grpc communication. This step encrypts the data between your client and server. You should also use authentication and authorization to control access. When you set up authentication and authorization, you decide who can call your grpc methods and what actions they can perform. You can use certificates or tokens to verify the identity of each client. Many developers use JWT tokens for this purpose. Always validate these tokens on the server before processing any request.

Tip: Use role-based authorization to limit access to sensitive grpc methods. Assign roles to users and check their permissions before allowing them to perform actions.

Authentication in WPF and ASP.NET

You must implement authentication and authorization in both your WPF and asp.net applications. In asp.net, you can use built-in middleware to handle authentication and authorization. This middleware checks user credentials and enforces authorization rules for each request. You can add authentication/authorization feature by configuring services in your Startup or Program file. For WPF, you often connect to a backend service for authentication and authorization. The WPF client sends user credentials to the server, which returns a token if the credentials are valid. The client then uses this token for future requests. Always store tokens securely on the client side.

A table below shows common authentication and authorization methods:

MethodDescriptionUse Case
JWT TokensCompact, secure tokens for stateless sessionsWeb APIs, grpc services
OAuth2Delegated authorization for third-party accessExternal integrations
Windows AuthUses Windows credentials for authenticationInternal enterprise

Note: Always use secure storage for tokens in WPF apps. Never store sensitive data in plain text.

Token Management

You need to manage tokens carefully to keep your applications secure. When you use authentication and authorization, your server issues a token after a successful login. The client stores this token and sends it with each request. You should set token expiration times to reduce risk. When a token expires, the client must request a new one. In asp.net, you can configure token lifetimes and refresh logic. For grpc, always check the token before processing a request. If the token is missing or invalid, deny access using your authorization rules.

You should also revoke tokens when a user logs out or when you detect suspicious activity. This step prevents unauthorized access. Regularly review your authentication and authorization setup to ensure it meets your security needs.

Tip: Automate token renewal in your clients to keep sessions active without user interruption.

Deployment and Maintenance

Multi-Tier Deployment

You can organize your .NET solution using a multi-tier deployment. This approach separates your application into layers. Each layer has a specific job. For example, you might have a presentation layer for WPF or ASP.NET Core MVC, a service layer for grpc communication, and a data layer for your database. This structure helps you manage your code and scale your solution.

A typical multi-tier setup looks like this:

TierTechnology ExamplePurpose
Presentation LayerWPF, ASP.NET Core MVCUser interface
Service Layergrpc, Web APIBusiness logic, communication
Data LayerSQL Server, PostgreSQLData storage

You deploy each tier on different servers or containers. This separation improves security and performance. You can update one tier without affecting the others.

Tip: Use grpc in your service layer to connect your presentation and data layers quickly and reliably.

CI/CD Pipelines

You can automate your build and deployment process with CI/CD pipelines. CI stands for Continuous Integration. CD stands for Continuous Deployment. These pipelines help you deliver updates faster and with fewer errors.

Here are the main steps in a CI/CD pipeline:

  1. You push your code to a source control system like GitHub or Azure DevOps.
  2. The pipeline builds your application and runs tests.
  3. If tests pass, the pipeline deploys your app to a test or production environment.

You can use tools like GitHub Actions, Azure Pipelines, or GitLab CI. These tools support .NET, ASP.NET Core, and grpc projects. You can set up automatic deployments for your WPF, web, and grpc services.

Note: CI/CD pipelines help you catch problems early. You can roll back changes if something goes wrong.

Monitoring and Updates

You need to monitor your applications to keep them healthy. Monitoring tools track errors, performance, and usage. You can use Application Insights, Prometheus, or Grafana. These tools work with .NET, ASP.NET Core, and grpc services.

You should set up alerts for important events. For example, you can get a message if your grpc service fails or your web app slows down. Regular updates keep your system secure and fast. You should patch your servers, update your libraries, and review your logs often.

A simple checklist for maintenance:

  • Monitor all services, including grpc endpoints.
  • Set up alerts for errors and slowdowns.
  • Update your .NET runtime and libraries.
  • Review logs and fix issues quickly.

Tip: Schedule regular maintenance windows. This helps you apply updates without disrupting users.

Best Practices and Next Steps

Design Patterns

You improve your .NET projects by using proven design patterns. These patterns help you write code that is easy to understand, test, and maintain. In modern .NET development, you often use patterns like Dependency Injection, Repository, and MVVM (Model-View-ViewModel).

  • Dependency Injection lets you manage dependencies between classes. You register services in your startup code and inject them where needed. This pattern makes your code flexible and testable.
  • Repository Pattern separates your data access logic from business logic. You create repository classes to handle database operations. This keeps your code organized.
  • MVVM works well for WPF applications. You separate your UI, business logic, and data models. This pattern helps you build responsive and maintainable desktop apps.

Tip: The Modern .NET Development Podcast on m365.fm often highlights how these patterns help you scale your solutions and prepare for future changes.

Testing Strategies

You need strong testing strategies to deliver reliable software. Testing helps you catch bugs early and ensures your code works as expected. In .NET, you use different types of tests:

Test TypePurposeTools
Unit TestsTest small pieces of code in isolationxUnit, NUnit, MSTest
Integration TestsTest how components work togetherTestServer, WebApplicationFactory
UI TestsTest user interfaces and workflowsSelenium, Playwright

You write unit tests for your business logic. You use integration tests to check how your services and databases interact. For WPF and web apps, you add UI tests to make sure your user experience stays smooth.

  • Use test-driven development (TDD) to write tests before your code.
  • Automate your tests in CI/CD pipelines for fast feedback.
  • Mock dependencies to isolate your tests.

Note: Automated testing saves you time and reduces errors during updates.

Documentation and Collaboration

You keep your projects healthy by writing clear documentation and working well with your team. Good documentation helps new developers understand your code. It also makes it easier to maintain and extend your applications.

  • Write README files that explain your project’s purpose and setup steps.
  • Use XML comments in your code to describe classes and methods.
  • Create API documentation with tools like Swagger for ASP.NET Core.

You collaborate better when you use version control systems like Git. You track changes, review code, and resolve conflicts as a team. Communication skills matter as much as technical skills. The Modern .NET Development Podcast often discusses how strong communication and clear documentation help teams succeed, especially as AI tools become more common in development.

Tip: Schedule regular code reviews and share knowledge with your team. This practice leads to better code and a stronger team.

Learning Resources

You can grow your .NET development skills by using a variety of learning resources. The .NET ecosystem changes quickly, so you need to stay updated with the latest tools, frameworks, and best practices. Here are some top resources that help you keep your knowledge current and practical.

📚 Recommended Podcasts and Shows

  • Modern .NET Development Podcast (m365.fm)
    Listen to Mirko Peters and Microsoft MVP Gábor Ruzsinszki as they discuss real-world .NET topics. You get expert advice on WPF, ASP.NET Core, gRPC, and more. The podcast covers AI in development, communication skills, and future .NET features.

    Tip: Subscribe to the Modern .NET Development Podcast on your favorite platform for regular updates.

  • .NET Rocks!
    This show features interviews with industry leaders. You learn about new trends, tools, and techniques in .NET.

📖 Official Documentation and Guides

🛠️ Community and Interactive Platforms

  • Stack Overflow
    You can ask questions and find answers from experienced .NET developers. Search for solutions or share your own knowledge.

  • GitHub
    Explore open-source .NET projects. You can read code, contribute to repositories, and learn from real-world examples.

  • Microsoft Q&A
    This forum lets you connect with Microsoft engineers and the .NET community.

📅 Conferences and Online Events

  • .NET Conf
    You can watch live sessions and workshops. Learn about the latest .NET releases and features.

  • Local Meetups
    Join .NET user groups in your area. Meet other developers, share experiences, and work on projects together.

📝 Table: Quick Reference to Learning Resources

Resource TypeExample/LinkWhat You Gain
PodcastModern .NET Development Podcast (m365.fm)Expert insights, real stories
DocumentationMicrosoft Learn, ASP.NET Core DocsTutorials, guides, samples
CommunityStack Overflow, GitHub, Microsoft Q&AQ&A, code, networking
Events.NET Conf, Local MeetupsLive learning, networking

Note: You should set aside time each week to explore new resources. Continuous learning helps you stay ahead in modern .NET development.

You can combine these resources to build a strong foundation. Try new tools, follow expert advice, and join the .NET community. You will improve your skills and keep your projects modern and efficient.


You learned how to connect WPF, asp.net, and grpc for modern .NET development. You saw practical steps for migration, integration, and security. You can use grpc to build fast communication between desktop and web apps. You improve your projects by following best practices from the Modern .NET Development Podcast. You should try grpc in your next solution. You can explore m365.fm for more expert advice.

Join the .NET community and experiment with sample projects to grow your skills.

FAQ

What is the main advantage of using WPF for desktop applications?

You can build rich and responsive user interfaces with WPF. The framework supports advanced graphics and data binding. You design enterprise-grade desktop apps quickly and efficiently.

How does ASP.NET Core improve web development?

You gain cross-platform support and high performance with ASP.NET Core. The framework lets you build secure web apps and APIs. You deploy your solutions on Windows, Linux, or macOS.

Why should you use grpc for service communication?

You achieve fast and reliable communication between services with grpc. The framework uses HTTP/2 and Protocol Buffers. You reduce latency and improve scalability in your applications.

Can you connect WPF and ASP.NET Core using grpc?

You integrate WPF and ASP.NET Core by using grpc. The framework lets your desktop and web apps share data and business logic. You create unified solutions for modern business needs.

What tools help you migrate legacy .NET applications?

You use .NET Upgrade Assistant and Visual Studio for migration. These tools analyze your code and guide you through the upgrade process. You modernize your apps with less effort.

How do you secure your ASP.NET Core and grpc services?

You protect your services by enabling HTTPS and using authentication tokens. You implement role-based authorization to control access. You keep your data safe and your users secure.

Where can you find expert advice on modern .NET development?

You listen to the Modern .NET Development Podcast on m365.fm. The podcast features real-world examples and practical tips. You learn from industry experts and stay updated on new technologies.

🚀 Want to be part of m365.fm?

Then stop just listening… and start showing up.

👉 Connect with me on LinkedIn and let’s make something happen:

  • 🎙️ Be a podcast guest and share your story
  • 🎧 Host your own episode (yes, seriously)
  • 💡 Pitch topics the community actually wants to hear
  • 🌍 Build your personal brand in the Microsoft 365 space

This isn’t just a podcast — it’s a platform for people who take action.

🔥 Most people wait. The best ones don’t.

👉 Connect with me on LinkedIn and send me a message:
"I want in"

Let’s build something awesome 👊

1
00:00:00,000 --> 00:00:20,000
Yeah, hello, my name is Michael Peters and I will say welcome to another edition of the M65 show today my guest is Garbar Zysinski and he is an MVP and we talk about modern dot net development from B a pf to as net and G RPC.

2
00:00:20,000 --> 00:00:33,000
So Garbo welcome to the show I hope I pronounced your last name right can you introduce you a little bit to yourself to the audience.

3
00:00:33,000 --> 00:00:43,000
Yes, thank you for inviting me. Hello everybody, my name is Gabar Zysinski. I'm from Hungary and as me.

4
00:00:43,000 --> 00:01:08,000
I'm a Microsoft MVP in development technologies specializing in C sharp I joined the Microsoft MVP program in 2021 and since then I won this achievement five times in a row.

5
00:01:08,000 --> 00:01:34,000
In my personal life or in my professional career I started as a high school teacher and a university teacher then in 2016 I moved to professional software development and since then I have been developing applications for a living now.

6
00:01:34,000 --> 00:01:44,000
And in the past eight years I worked as a software architect. I think that summarizes my personal life.

7
00:01:44,000 --> 00:02:03,000
What kind of teacher you were a IT teacher or yes I teach IT subjects so I graduated when the big recession hit the market and nobody was hiring software developers at that time.

8
00:02:03,000 --> 00:02:29,000
And I needed a job and as a side course I took some teaching lessons at the university so it was quite natural for me to start a teaching career and mainly I have a teaching programming and subjects related to that data science algorithms.

9
00:02:29,000 --> 00:02:35,000
So the database is all that stuff.

10
00:02:35,000 --> 00:02:51,000
That is interesting on databases I think more on SQL and Python and so on. How did you your journey into dot net in C sharp develop again.

11
00:02:51,000 --> 00:03:07,000
Well, at the age of 18 I started programming seriously mainly because I know that I have known that at the university we will have some subjects related to that.

12
00:03:07,000 --> 00:03:34,000
I wanted to have a head start and dog myself deep into it and my language of choosing was definitely mainly because it seemed easy it has had a nice user interface and I was feeling like I was making really good progress with not so much of a deep knowledge on the subject.

13
00:03:34,000 --> 00:03:45,000
And of course at the university we had C and C++ which were a quite different kind of beast to say the least from the.

14
00:03:45,000 --> 00:03:59,000
But after that we had a course on C sharp and I think the lecture mentioned that the same guy designed the languages, the end I know that.

15
00:03:59,000 --> 00:04:27,000
And that the feeling or the impression that if they could convince the same guy to design language for them that is mainly C based but very much so better than the C++ standard that that time was I knew that I had to learn that language and I started.

16
00:04:27,000 --> 00:04:42,000
And I was investing in dot net around 2008 maybe seriously when dot net 3.5 was a thing and I think this was the very hyped new operating system.

17
00:04:42,000 --> 00:04:53,000
So yeah, back in the days I started it and ever since I have been developing C sharp applications.

18
00:04:53,000 --> 00:05:00,000
For my hobby projects and I do this for a living for more than 10 years now.

19
00:05:00,000 --> 00:05:13,000
I think you are most known on LinkedIn for VPF development can you explain what is is and what is making so appealing to you.

20
00:05:13,000 --> 00:05:29,000
Yeah, I started a little bit of history context WPF was the new graphical user interface introduced in dot net 3.5.

21
00:05:29,000 --> 00:05:39,000
It is a vector based description language for creating UIs mainly for windows.

22
00:05:39,000 --> 00:05:51,000
But the core philosophy of it the example descriptive language and the whole philosophy of it lives here this day.

23
00:05:51,000 --> 00:06:17,000
For example, the Maui platform which is quite new in the dot net ecosystem is also based on exam or not to mention that the windows UI that Microsoft tries to push for native application developments is also based on exam and the core philosophy is of WPF.

24
00:06:17,000 --> 00:06:46,000
Why I started to learn this technology back then was because at the time internet explorer 6 was still a thing and quite frankly developing web applications back at those times were not my kind of work to say the least because of the quirks that you have to implement.

25
00:06:46,000 --> 00:06:54,000
And the implement on the UI side and yeah WPF just worked.

26
00:06:54,000 --> 00:07:00,000
I'm not saying it's a perfect UI development platform.

27
00:07:00,000 --> 00:07:20,000
It has its own quirks and quite a bit of learning curve but once you get used to it it offers very good flexibility and you can do anything inside of it.

28
00:07:20,000 --> 00:07:30,000
So if you have a kind of a UI imagination then you can be sure that you can implement it.

29
00:07:30,000 --> 00:07:36,000
Unfortunately the age is starting to show on it.

30
00:07:36,000 --> 00:07:48,000
I mean it's more than 10 years or at this point 15 years old and they are the adding some new features.

31
00:07:48,000 --> 00:08:04,000
Mainly it's on life support so I would suggest moving on to a new platform like Vini UI or Maui if you are new and want to learn something similar like it.

32
00:08:04,000 --> 00:08:26,000
For legacy applications it's still used in even in our company there are several applications that are still using it and unfortunately because of their size they won't be moving to anything new in the upcoming future.

33
00:08:26,000 --> 00:08:44,000
So you have years of seeing how .NET ecosystem has evolved so if you explain more than .NET to someone who last used .NET framework 2012 what will you say?

34
00:08:44,000 --> 00:08:54,000
It's a hard question because I would say it's the same .NET but even better.

35
00:08:54,000 --> 00:09:12,000
If you are using .NET then you have some kind of love for that framework because it provides you a lot of options and even the C# languages designed to be user friendly and solve your problems.

36
00:09:12,000 --> 00:09:24,000
The modern approach that they are taking that it's multi-platform and they are pushing new and new features I would say it's even better.

37
00:09:24,000 --> 00:09:33,000
What I would say as a main benefit of using modern .NET is the speed difference.

38
00:09:33,000 --> 00:09:59,000
For example in the core releases which they have every two years the speed is incredibly increased so porting from .NET 8 to 10 gives you a significant speed boost that you can quite easily notice in your applications without changing much of your code base.

39
00:09:59,000 --> 00:10:06,000
I think that's the main benefit there and another benefit is that it's really multi-platform.

40
00:10:06,000 --> 00:10:19,000
So currently I'm working on a project at the company which uses .NET and primarily developed for Linux systems.

41
00:10:19,000 --> 00:10:37,000
We have the task now to make it multi-platform and I think that's the easiest job I had in the last three or four weeks now because it can be easily switched to Windows without any hassle.

42
00:10:37,000 --> 00:10:51,000
WPF has been around for a long time yet many companies still relay on it heavily. How do they remain relevant?

43
00:10:51,000 --> 00:11:18,000
It remains relevant because it's still supported in modern .NET versions so you don't have to be worried that it will go away soon because they are still supporting it adding some new features to it and making sure that it works.

44
00:11:18,000 --> 00:11:30,000
Another part that is still relevant is because of a lot of applications were written in the post.

45
00:11:30,000 --> 00:11:36,000
That's because there wasn't anything better to begin with.

46
00:11:36,000 --> 00:11:55,000
I know that Windows UI is quite odd at this point but back in the day when it was new with Windows 8 my impression was that it will be the next big thing but it's not there yet.

47
00:11:55,000 --> 00:12:08,000
Due to some security constraints that were imposed on it at that time and because of the lack of support that they had.

48
00:12:08,000 --> 00:12:28,000
Back in the day Stack Overflow was our main source of truth and when you had an issue with Vini UI you were almost certain to not get any relevant answers because lack of developer experience.

49
00:12:28,000 --> 00:12:44,000
On the other hand if you had the same problem in WPF you could be certain that somebody faced that problem and had an exact solution for it.

50
00:12:44,000 --> 00:13:06,000
But with the newer AI models I think it's not more a decision factor to use WPF anymore because you can get support for almost any new technology with these AI models at this point.

51
00:13:06,000 --> 00:13:18,000
This is really interesting so we have also a topic from WPF to us.

52
00:13:18,000 --> 00:13:36,000
As we can say is it short companies, two tall, yeah, or in the future start with WPF or say that's not a good choice.

53
00:13:36,000 --> 00:14:00,000
It depends on what you are developing and what your goals are. My suggestion would be if you want to develop applications primarily focused on Windows then BPF might be a good starting point for that.

54
00:14:00,000 --> 00:14:24,000
I am saying this because it's easy to deploy it has an excellent tooling in the Visual Studio and it has a lot of existing knowledge base and user controls and what not that you can just grab and use without reinventing the wheel.

55
00:14:24,000 --> 00:14:36,000
On the other hand with Windows UI you almost have the same options but you are much more limited in terms of pre-existing controls.

56
00:14:36,000 --> 00:15:04,000
So you will have a lot of work porting existing WPF controls for Windows UI. It could work but it's definitely much more work to make it nice looking and you will have to spend a lot of time developing your own controls for them.

57
00:15:04,000 --> 00:15:27,000
But if you want to have a multi-platform UI for example your goal is to support Mac OS as well then WPF is not a good choice since in its name the WU stands for Windows meaning that it only works on Windows.

58
00:15:27,000 --> 00:15:55,000
So for that I would suggest the .NET Maui system which is a bit different than WPF but if you have the knowledge of XAML then it's not so much of a big deal to transition to it because they kept the same core philosophies.

59
00:15:55,000 --> 00:16:09,000
OK you say .NET Maui what did you think about a Valonia or the UNO platform?

60
00:16:09,000 --> 00:16:26,000
Valonia and UNO platform are really good I think the only downside I think is the licensing which for me sounds a little bit confusing.

61
00:16:26,000 --> 00:16:51,000
I know it's free for personal projects but when you try to make some money on those applications you require an additional license which might have some costs associated to it that might become unacceptable to your company.

62
00:16:51,000 --> 00:17:17,000
It really depends on your company. From a technical perspective I cannot say anything negative about them they are really doing a great job on making .NET appealing for more and more people and proving that you can do anything in C#.

63
00:17:17,000 --> 00:17:31,000
So even develop applications that run inside your browser and have the same user experience on every imaginable platform.

64
00:17:31,000 --> 00:17:38,000
OK you from the title we know you recently worked more with us.

65
00:17:38,000 --> 00:17:53,000
What triggered that transition? It was triggered because of another project that I was putting inside of the company.

66
00:17:53,000 --> 00:18:06,000
So mainly the world has shifted a bit. So desktop applications are not really a thing at this moment.

67
00:18:06,000 --> 00:18:15,000
Everything tries to be a software as a service solution and for that web technologies are used.

68
00:18:15,000 --> 00:18:29,000
Our application that we are currently developing tries to do the same. It tries to be a software as a service that runs on IoT Edge devices as well.

69
00:18:29,000 --> 00:18:44,000
So the obvious choice was to use C# because the company has a really good knowledge base and a lot of developers that know this technology.

70
00:18:44,000 --> 00:19:04,000
So it was obvious for us to use C# to develop it and if we are using C# then it's quite obvious choice to use ASP.NET to develop these backend services that we need for this kind of project.

71
00:19:04,000 --> 00:19:11,000
OK. And what excited you most about the modern AppNet Core?

72
00:19:11,000 --> 00:19:22,000
The most exciting part I think is that how much has it changed in the last few years?

73
00:19:22,000 --> 00:19:36,000
Mainly I was developing desktop applications in the past but I always tried to be up to date with the newer ASP things.

74
00:19:36,000 --> 00:19:52,000
And in the last, I don't know, three or four years, it was quite noticeable that they made a lot of effort in developing it as flexible as possible.

75
00:19:52,000 --> 00:20:17,000
Heck in the last two years, I think they introduced this minimal API kind of syntax for developing rest applications and it's really really good to say the least because you don't have to deal with controllers and all that nasty stuff.

76
00:20:17,000 --> 00:20:34,000
Even if you are developing some kind of a small microservice, it's a really good choice that you have options and flexibility and basically you can control anything inside of it.

77
00:20:34,000 --> 00:20:44,000
So the most exciting part I think is that they reinvented it from the ground up.

78
00:20:44,000 --> 00:20:56,000
OK. Yeah, I think I have read a little bit about the minimal APIs and there are some people they say it's absolutely revolutionary and the other say it's completely alive.

79
00:20:56,000 --> 00:20:58,000
What do you think?

80
00:20:58,000 --> 00:21:18,000
I know it's a dividing topic and I get that some people don't like it compared to the MVC style controller approach, but on the other hand, I think it's really really good.

81
00:21:18,000 --> 00:21:32,000
I'm seeing this because I had some experience in Python and it's quite similar to the principles of the flask framework, which is quite popular in Python.

82
00:21:32,000 --> 00:21:38,000
So for me, it was natural that it's try to be the same.

83
00:21:38,000 --> 00:21:41,000
It has its downsides, I get it.

84
00:21:41,000 --> 00:21:59,000
And but on the other hand, it has its own benefits. So for example, if I have to develop a service that maybe has three or four endpoints, a controller based layout, I think is it's overkill for it.

85
00:21:59,000 --> 00:22:25,000
It's much more easier to do it in minimal API, but on the other hand, I get it if you have a really big application with hundreds of endpoints, then I wouldn't stick with the minimal API layout because eventually you really invent the controller layout and style of organizing your code that way.

86
00:22:25,000 --> 00:22:37,000
Even if you are using, even if you have started with the minimal API approach, so it depends on what you want to do, I think.

87
00:22:37,000 --> 00:22:39,000
Okay, awesome.

88
00:22:39,000 --> 00:22:49,000
When you think about clean and many main title dot net architecture, what makes it to you?

89
00:22:49,000 --> 00:23:17,000
In my own. So if we are talking about the architecture, I think the most important part of any architecture is documenting your concepts and trying to make it understandable and approachable for the team members.

90
00:23:17,000 --> 00:23:37,000
Because you can invent a really complicated, really clean architecture, but if nobody understands it, then sooner or later your code will become an entangled mess and hard to maintain.

91
00:23:37,000 --> 00:23:57,000
Which ever architecture model you are choosing, I think the most important part is documenting it and educating the people that will work on that project when you are concepts and your ideas, how it should be organized.

92
00:23:57,000 --> 00:24:15,000
But to say something concrete, personally in the last couple of years, I'm a really big fan of the hexagonal architecture or the ports and adapters.

93
00:24:15,000 --> 00:24:42,000
But those are the same things, but with two different names. So I would say that hexagonal architecture is a really good choice for web applications.

94
00:24:42,000 --> 00:24:52,000
But now you are muted. Yep. I'm finished with what I wanted to say.

95
00:24:52,000 --> 00:24:56,000
Yeah, it's a no problem.

96
00:24:56,000 --> 00:25:03,000
When we think about monolith for those microservices, where did you stand?

97
00:25:03,000 --> 00:25:16,000
It depends on the goals in my personal opinion, nothing starts as a microservice based solution.

98
00:25:16,000 --> 00:25:23,000
If you are making an organic growth in your application.

99
00:25:23,000 --> 00:25:44,000
So for example, what I'm trying to say is that if you are a startup and you are developing an application, then it's an overkill to start with microservices from the beginning because they have a lot of additional effort associated with them.

100
00:25:44,000 --> 00:26:08,000
First of all, you need a really good DevOps pipeline to make them deployable and not to mention you need the headcount to actually have microservices because if you have maybe six or seven developers and you are building a microservice based architecture and you have nine or ten microservices.

101
00:26:08,000 --> 00:26:21,000
That means that the developers are constantly changing their focus and constantly context switching between services.

102
00:26:21,000 --> 00:26:37,000
So in my opinion, organically nothing starts with microservices. It's don't get me wrong. It's a necessity at some point to evolve to microservices.

103
00:26:37,000 --> 00:27:02,000
But I think a working monolith, which is centered around some building blocks and had some thoughts about separation and probably following the solid principles, could be ported to a microservice architecture later.

104
00:27:02,000 --> 00:27:15,000
But yeah, say the least if you are not an Amazon type of company or not, you don't really need to start with microservices in my opinion.

105
00:27:15,000 --> 00:27:44,000
Or if you have the business requirement upfront that, okay, you probably will need to serve, I don't know, five million concurrent requests, then you have that upfront requirement and you probably should go with microservices, but with the necessary amount of people to actually do it.

106
00:27:44,000 --> 00:27:49,000
And what's your opinion on cloud native.net development?

107
00:27:49,000 --> 00:27:56,000
They made some really good progress in it with the aspire platform.

108
00:27:56,000 --> 00:28:25,000
Personally, we don't use it in our projects due to the IoT nature of our application and some limited constraints, but it's really nice that you can start your visual studio, click some few things and have a scaffolding, microservice based solution for your whole architecture.

109
00:28:25,000 --> 00:28:34,000
And you don't have to spend a lot of time configuring it and making it work.

110
00:28:34,000 --> 00:28:45,000
You can just start developing your application and probably the default configurations that aspire gives you will work just fine.

111
00:28:45,000 --> 00:28:55,000
And the later step when it doesn't really work out for you, you can always customize it dig into the topics.

112
00:28:55,000 --> 00:29:08,000
So I think it's a really good addition to the dotnet stack that they are spending some effort on that as well.

113
00:29:08,000 --> 00:29:22,000
And well, many think about all the gears you're working with dotnet. Is there a feature that's introduced in the recent years you have impressed you or that's the best you most.

114
00:29:22,000 --> 00:29:51,000
And a language perspective, I would say the most important thing that we will have in dotnet is the discriminated type unions that are coming in dotnet 11 because in the past few years, I always tried to design my applications with this result.

115
00:29:51,000 --> 00:30:02,000
Pattern in mind where you don't really do exceptions instead of that you return results all the time.

116
00:30:02,000 --> 00:30:13,000
And for that to work in dotnet, you had to use external packages and the language support wasn't quite there yet.

117
00:30:13,000 --> 00:30:40,000
So I'm most interested in that. But if I want to say something that's already out in the market and widely available at dotnet, I would say that in dotnet 9 they really ramped up the language integrated query performance.

118
00:30:40,000 --> 00:30:54,000
We had a application that was doing some database manipulation basically building a database from a bunch of exo files.

119
00:30:54,000 --> 00:31:23,000
And by a bunch of exo files, I mean like hundreds of them with thousands of rows. It's not ideal, but the requirement was that. And for that we wrote an application which had a typical runtime about 45 in it to build this database and validate all the data that was given into it.

120
00:31:23,000 --> 00:31:43,000
And yeah, we couldn't make it really much more faster. But then when we switched to dotnet 9, I was convinced that something was terribly broken because the runtime of this application went down to 25 minutes.

121
00:31:43,000 --> 00:32:03,000
And I was convinced that, okay, something is not working. Why I am not seeing any exceptions and what's really happening in our code. And I spent maybe two or three hours trying to figure out what was wrong. And fortunately nothing was wrong.

122
00:32:03,000 --> 00:32:19,000
And the framework got so fast that it cut our use case in half. So I was quite impressed with that not to mention our customers were quite impressed with that as well.

123
00:32:19,000 --> 00:32:28,000
Okay. So for, for listener that unfamiliar with it, how or what exactly is GRPC?

124
00:32:28,000 --> 00:32:49,000
GRPC is a technology by Google or it was invented by Google. It's an I would say an alternative approach to communication compared to a rest API's.

125
00:32:49,000 --> 00:33:03,000
It's an RPC style of communication, meaning that between each call you can have an internal state of your application.

126
00:33:03,000 --> 00:33:30,000
Another cool thing about GRPC is that it has its own descriptor language called protocol buffers. And you define your messages and your services inside of this language and the prototype compiler scaffolds your code to make the communication work.

127
00:33:30,000 --> 00:33:50,000
So it's quite popular when you have to connect to or more systems which are written in different languages because the protobuff even can scaffold C++ code from your proto buff definitions.

128
00:33:50,000 --> 00:34:11,000
And you can quite easily connect together Python C++ C sharp and all different kinds of services with only one data definition language or service definition language.

129
00:34:11,000 --> 00:34:34,000
I think that's the most important part while we at our company chose it for our project because we have to communicate with services that are written in other technologies and developed by other teams.

130
00:34:34,000 --> 00:34:49,000
And it was the most convenient way that we found don't get me wrong. You can achieve the same with rest API and Jason documents as well.

131
00:34:49,000 --> 00:35:08,000
But unfortunately at this moment the Jason shame is still not an officially accepted standard. So the tooling is quite different between the languages.

132
00:35:08,000 --> 00:35:21,000
For some languages like don't know you have excellent tooling and for others you have the bare minimum that is available.

133
00:35:21,000 --> 00:35:38,000
And based on that gRPC for us seemed a really good choice because it eliminated these problems for us.

134
00:35:38,000 --> 00:35:47,000
So what what or a one show developers choose gRPC over rest of this what you say it's.

135
00:35:47,000 --> 00:35:53,000
I think two decision factors coming to play.

136
00:35:53,000 --> 00:36:18,000
So gRPC uses the binary format then it's communicating. So if you want to have a service service connection meaning a backend communicates with another backend and no human interaction is involved and the speed is really important for you.

137
00:36:18,000 --> 00:36:44,000
And the other driving factor for choosing it I think is if you have multiple services in different languages that you need to connect together for that gRPC offers a very good solution.

138
00:36:44,000 --> 00:36:59,000
Only right your service definitions and data type definitions once and the rest of the scaffolding is handled by the protobuf compiler.

139
00:36:59,000 --> 00:37:14,000
So what you have to do is implement your communication or transport logic and you have less work to do them sticking with rest I would say.

140
00:37:14,000 --> 00:37:43,000
Will you say gRPC is harder to debug and made it and compare to rest it depends so I won't say that it's harder to maintain but it can be a bit more challenging to debug it because it's a binary format you have some options to investigate the network traffic.

141
00:37:43,000 --> 00:38:07,000
And the code what was sent but yeah that makes it a little bit different harder to debug but usually you don't have to deal with these things because you are just sending classes from one language to another and the rest should be handled by gRPC.

142
00:38:07,000 --> 00:38:28,000
So you shouldn't really have some communication issues in my opinion so I would say it's a different kind of a beast compared to rest but I wouldn't say it's much harder to developing it.

143
00:38:28,000 --> 00:38:46,000
I will think actually rest is market leader API market leader do you think gFc will eventually replace in the game scenarios rest.

144
00:38:46,000 --> 00:39:07,000
So rest is a market leader because of UIs so the browsers speak natively json and javascript so it's an obvious choice to use rest when you are sending data to an interactive front end.

145
00:39:07,000 --> 00:39:36,000
So I wouldn't say that gRPC will replace it and I think it's not even a goal for it to be to replace this but for back ends and in microservice communications the added overhead that you send data in json is I think a little bit costly to say.

146
00:39:36,000 --> 00:40:03,000
Because you have to serialize your format into json and you won't end it in the vast majority of the time you won't be inspecting the traffic between your microservice is by hand so there gRPC is much better choice by thinking but it really depends on what you trying to achieve.

147
00:40:03,000 --> 00:40:19,000
Even you can have a gRPC back end that communicates with your front end but additional logic will be required to decode the binary formatting to something usable.

148
00:40:19,000 --> 00:40:34,000
So it really depends but I wouldn't say it will become a market leader in terms that okay from now on we use gRPC for everything.

149
00:40:34,000 --> 00:40:44,000
But you say it's a good Google it's open source right yes it's open source.

150
00:40:44,000 --> 00:40:54,000
How does dotnet make working with gRPC easier to compare to other ecosystems.

151
00:40:54,000 --> 00:41:19,000
It's quite similar to other ecosystems I would say it makes it easy in tooling I would say so the user experience is quite similar between the languages the only difference is how much effort you will need to spend on setting it up.

152
00:41:19,000 --> 00:41:41,000
Don't let it's quite easy you just add a couple of new get packages to your solution and that's it but you had to do because those new get packages contain the compiler and the necessary build tasks to build the protocol buffer definition and all of that.

153
00:41:41,000 --> 00:42:10,000
scaffolding logic is handled in the background for other languages like for example C++ you will have to spend some time on editing your C make configuration files making sure it compiles but the core development experience once you get it working is quite similar.

154
00:42:10,000 --> 00:42:28,000
But to get there to have a compiling solution is I think most mainly different in favor of the dotnet solutions.

155
00:42:28,000 --> 00:42:43,000
I think when we look a little bit in the future actually also a I coding assistant or I think everywhere now yes how have it changed your development workflows.

156
00:42:43,000 --> 00:43:11,000
I'm in a kind of a love hate relationship with AI to say to be quite open about it because sometimes or at least not sometimes but most of the time it works really well it figures out what I want to do helps me in a lot of scenarios.

157
00:43:11,000 --> 00:43:40,000
I use the auto complete features of it so most of the time what I have to do is just press tab tab and everything everything is looking good working fine what not but sometimes it goes back to a I don't know three year old child that refuses to.

158
00:43:40,000 --> 00:44:05,000
Actually recognize patterns and gives me a really bad headache how it came off it those answers for the input prompts but yeah it depends on the context what you have and what you are trying to achieve.

159
00:44:05,000 --> 00:44:34,000
But say personally it was a huge benefit for coding because even if it doesn't work maybe then we're 15% of the times then it generates something as a starting point I used it several locations where I was lazy about developing my own algorithm.

160
00:44:34,000 --> 00:45:02,000
I just prompted a problem that I want to solve for example connecting to services together what would be the best approach and like stack overflow it gave me some explanation which solution to use what are the benefits what are the downside sides so it makes even decisions.

161
00:45:02,000 --> 00:45:21,000
I can then focus look up everything it suggested and make a better decision what I want to implement or how I want to approach the problem.

162
00:45:21,000 --> 00:45:46,000
We have it has its benefits but I fear it also has its downsides so sometimes I feel like I'm just a pilot or a job giver to another person and it takes out of the joy of coding sometimes.

163
00:45:46,000 --> 00:46:15,000
So that's why I have this kind of a love hate relation ship with it but I get it by companies and developers like it because yeah it really changed the landscape we will see I think in a five or ten years for the better or the worse it has changed the landscape but definitely it has changed.

164
00:46:15,000 --> 00:46:39,000
Yeah I think it's really hard and when you think or do you think you enjoy developers risk relying or they use AI to heavily.

165
00:46:39,000 --> 00:46:50,000
Well it's a complex question because if they use it well it can be a huge benefit for them.

166
00:46:50,000 --> 00:47:06,000
I was learning programming and quite new with C# the only source of truth was stack overflow.

167
00:47:06,000 --> 00:47:28,000
It had its charm back in the day but sooner or later it became quite unbearable because you gave a question and it was closed as it duplicates with a not relevant answer to your problem.

168
00:47:28,000 --> 00:47:46,000
So compared to that if you know how to prompt the AI agent and use it to only research things how you should do it.

169
00:47:46,000 --> 00:48:15,000
So I have this kind of a feeling that the junior developers that are starting today will become much better developers if they use it correctly but on the other hand I also see the risks that if they just prompt it and tell the AI please do this and do that.

170
00:48:15,000 --> 00:48:44,000
And don't care about the implementation details how it's working, what are the quirks, how it's done in the background then they will become much more less educated in those topics and they will have a hard time from transitioning from a junior developer to the new developer.

171
00:48:44,000 --> 00:48:59,000
And it's a good thing to do is to be a newer or even a senior level I think but it really depends I think how one is using the technology.

172
00:48:59,000 --> 00:49:10,000
I wouldn't say it's bad and I wouldn't say it's good it depends on how you are approaching the topic.

173
00:49:10,000 --> 00:49:19,000
So if you have the chance or you called add one thing to see chop what would it be?

174
00:49:19,000 --> 00:49:29,000
The one thing I would add personally is this discriminated type unions but it's finally coming.

175
00:49:29,000 --> 00:49:54,000
So at the moment I don't have any topics that are really missing from C# but if I would have to say something I would say the units of measurements thingy in F# is very very nice.

176
00:49:54,000 --> 00:50:08,000
In the past we had some applications where a lot of scientific calculations were involved with unit conversion and all that nasty stuff.

177
00:50:08,000 --> 00:50:22,000
C# has this units of measurement feature where you can define conversion logic inside of the language for your units and even it's validated in compile time.

178
00:50:22,000 --> 00:50:41,000
So if you are trying to do something really stupid like divide temperature by length then it will say to you that those are two incompatible categories and you cannot perform this application conversion in compile time.

179
00:50:41,000 --> 00:51:05,000
And you don't have to debug your code because you see what went wrong. So that would be another interesting feature but I don't think that it will come any soon into C# because it's a really really niche topic and use case.

180
00:51:05,000 --> 00:51:19,000
Now I have more to pass at the end and the first part is the hot text. I start a sentence and you close it.

181
00:51:19,000 --> 00:51:26,000
The biggest mistake in dotnet developers make is?

182
00:51:26,000 --> 00:51:43,000
I would say making things much more complicated than they need to be. For example using an interface for decoupling everything where it's not necessarily needed.

183
00:51:43,000 --> 00:51:55,000
The future of back end development looks promising and they really aspiring thing to learn if you are starting it.

184
00:51:55,000 --> 00:52:07,000
Because if this trend keeps on going that everything is a service, it's a good career choice I would say.

185
00:52:07,000 --> 00:52:12,000
If you had to learn dotnet from scratch today, you would.

186
00:52:12,000 --> 00:52:28,000
I would read my own book if I can say that but I know it's a little bit of shameless self promotion. So please forgive me this.

187
00:52:28,000 --> 00:52:39,000
No problem, no problem. I think also the people I can say when they look at the show notes all the links are inside so they find also your book.

188
00:52:39,000 --> 00:52:46,000
Yeah, then the last one here.

189
00:52:46,000 --> 00:52:54,000
The most underrated C# feature is better matching I would say.

190
00:52:54,000 --> 00:53:12,000
It's quite new thing but it has some really great potential inside it which should be much more widely used in production code basis I think.

191
00:53:12,000 --> 00:53:33,000
Now we come to the next part, it's the rapid fire round so I just a quick answer game I say start so visual studio obvious code visual studio coffee, energy drink or that he definitely coffee.

192
00:53:33,000 --> 00:53:42,000
Real developers use windows in the news or my guess real developers use what's best for them.

193
00:53:42,000 --> 00:53:49,000
The most underrated about that library. Humanizer I would say.

194
00:53:49,000 --> 00:53:53,000
One word describing modern dotnet.

195
00:53:53,000 --> 00:54:08,000
Awesomeness. The last thing you googled last thing I googled was Hungarian text submitting you date.

196
00:54:08,000 --> 00:54:16,000
Okay, really part of the more was the answer.

197
00:54:16,000 --> 00:54:29,000
Okay, then we come to the end and so is there any advice for developers trying to grow in the dotnet ecosystem you can give them today.

198
00:54:29,000 --> 00:54:43,000
My answer would apply to all ecosystems if you don't mind because quite frankly you need the same skills for every technology I think.

199
00:54:43,000 --> 00:55:12,000
And with the rise of AI I would say the most underrated skill at the moment is communication so back in the day a junior developer I think was someone who can do tasks but was not quite comfortable with presenting those solutions for a broader audience.

200
00:55:12,000 --> 00:55:40,000
So as you remain like management or even the customers and as soon as if you move your journey or professional life soon you will have to learn the skills to not to go into deep technical discussions with people when it's not required.

201
00:55:40,000 --> 00:56:07,000
Yeah, the most important thing I think for a developer in these times is to know some presentation skills and know how to talk unfortunately but the truth because coding I know it's a marketing quite phrase but coding is mostly.

202
00:56:07,000 --> 00:56:21,000
So with AI and other tools so yeah the most important thing I think is to know how to present yourself.

203
00:56:21,000 --> 00:56:44,000
So thank you this was awesome session learned a lot and that's also really deep dive into all these fascinating developer techniques and yeah from a real expert so I think the people can connect with you to learn more on LinkedIn or can my book.

204
00:56:44,000 --> 00:56:50,000
And yeah so I think thank you so much for for being here thank you.

205
00:56:50,000 --> 00:56:56,000
Thank you very much for having me it was an awesome experience.

206
00:56:56,000 --> 00:57:15,000
[ ouch ]

Mirko Peters Profile Photo

Founder of m365.fm, m365.show and m365con.net

Mirko Peters is a Microsoft 365 expert, content creator, and founder of m365.fm, a platform dedicated to sharing practical insights on modern workplace technologies. His work focuses on Microsoft 365 governance, security, collaboration, and real-world implementation strategies.

Through his podcast and written content, Mirko provides hands-on guidance for IT professionals, architects, and business leaders navigating the complexities of Microsoft 365. He is known for translating complex topics into clear, actionable advice, often highlighting common mistakes and overlooked risks in real-world environments.

With a strong emphasis on community contribution and knowledge sharing, Mirko is actively building a platform that connects experts, shares experiences, and helps organizations get the most out of their Microsoft 365 investments.

Gabor Ruzsinszki Profile Photo

Author / Software architect

Since 2022 Gábor has been recognized as a Microsoft MVP in Developer Technologies, a distinction that reflects his long-standing contribution to the software community. He has been working as a software architect since 2019, after making the move into software development in 2016. Before that, he spent several years in education, working as a university lecturer and as a high school teacher. Alongside his professional work, he has written several Hungarian books on C# and other programming topics. Of all his books, the one he is most proud of is Helló világ! Helló C#! (Hello World! Hello C#!), and his works are available to read online for free at https://csharptutorial.hu. In his free time, he likes to mix electronic music in genres of techno, trance and hardstyle.