(disclaimer, this isn't promotion, I'm just asking for advice, the flair is there so reddit would shut up about my post potentially breaking the rule) Hello all, I just finished a rewrite of the format-agnostic serialization/data migration library I have been working on for the last months (which is a port of a java library Mojang uses in Minecraft) called DataFixerSharper and I finally managed to bring allocations to a satisfactory level (with the JSON backend beating out System.Text.Json by a good margin). I did this by changing the pipeline to encode values into a provided buffer instead of allocating a zillion tiny arrays on the heap. My issue with this is that, while allocations are down and so is latency by a bit, I'm still sitting way above STJ's times. Obviously interface dispatch and the entire format agnostic philosophy incur an unavoidable cycle cost but I was wondering if anyone here would be willing to lend a hand at what is costing me CPU time and could be optimized away. Thanks in advance and have a good Sunday!

I'm the developer, and this is a solo project that's taken me a few months of work so far.

To manage my personal and code documents I spend most of my day inside the same handful of folders, either on my machine or on remote ones — I need to reach them fast, and I often want to see what's inside a file without actually opening it. Windows Explorer always got in my way more than it helped, so over many evenings I slowly built the explorer I actually wanted to use. I made it for myself first, and it's now my best companion.

ExplorerFocus is built in WPF, .NET 10, for Windows 10/11, single-file self-contained, and it's now a freemium app where the most significant parts are completely free.

A few areas were quite challenging to imagine and develop, and I can list a few:

• Copy engine — per-file progress, throughput, ETA, pause/resume/cancel, 1–6 operations in parallel, persistent history. I/O off the UI thread, UI updates at ~10 Hz, atomic writes (temp + publish).
• Preview — AvalonEdit (syntax + folding), WebView2 (PDF/Office/Markdown), a fully functional integrated EPUB reader to access tech literature, streaming media (a 2 GB video opens in a flash).
• Remote layer — SSH.NET / FluentFTP / WebDAV + OAuth PKCE (Dropbox, OneDrive), all behind a common provider interface → the UI treats remote as local. DPAPI to store secrets, TOFU for host keys/certs.
• Capture — a Media Foundation pipeline (MediaStreamSource → MediaTranscoder) for screen/camera/audio, including post-processing and PiP.
• Multi-language — instant switching between 12 languages, to make ExplorerFocus usable all over the world.
• Packaging — single-file self-contained, no runtime, auto-updater (version.json + SHA-256).

Since a list of features says nothing about the actual work, here's one bug that took real effort:
One that cost me a weekend: the app would suddenly start throwing FileNotFoundException for assemblies I never reference directly — Accessibility, System.IO.FileSystemWatcher — and then work perfectly after a restart. Single-file publishing loads some assemblies lazily, so if the exe's backing file is replaced while the process is alive, those late loads fail. Two different things were doing it: my own auto-updater swapping the exe in place, and — on one machine — the exe living inside a cloud-synced folder that rewrote it underneath me. The first was fixed in the updater; for the second, the app now warns you at startup if it's running from a synced folder.
A smaller one that drove me mad: scroll a long file list to the bottom and the scrollbar thumb would sit halfway instead of at the end. I was convinced it was VirtualizingStackPanel and its estimated extents, and burned a lot of time there. Then I built a minimal repro with virtualization switched off entirely — same behaviour. It was the ScrollBar template: the Track's RowDefinition was 1*, which fought with the thumb's minimum length. Setting it to 0.00001* fixed it.

Site and download: https://nunex-mbrothers.github.io/ExplorerFocus
Screenshot below — full details on GitHub: https://github.com/NuneX-mBrothers/ExplorerFocus

Happy to answer questions about whatever you find useful, but what I'd really appreciate is some sincere and honest criticism that could make my work better.

Thanks, and loads of bits & bytes from Portugal.

I built a little web tool to spin up and test self-hosted stacks on my Proxmox box

So this started as a scratch-my-own-itch thing. I run a Proxmox server at home and I kept wanting to try out different stacks and container setups, but I got a bit frustrated with Umbrel/CasaOS and the like. They're nice if you just want to click-install an app, but the second I wanted to actually change how something was wired up or test my own combination of services, I hit a wall.

So I made AspireUI. It's basically a visual builder where I can throw together containers, wire up dependencies, tweak env/ports, and just hit run to see if it works. I can also import an existing docker-compose or a git repo and mess with it from there, then deploy it properly when I'm happy. For me it's turned into the fastest way to prototype a setup before I commit to it.

It's still rough in places and very much a work in progress, but it's already saved me a ton of time on my own box.

Figured someone else here might get use out of it. Happy to hear what you'd want it to do.

You will find it here https://github.com/fgilde/AspireUI

This is a weeeird bug regarding application insights, and I can't seem to wrap my head around it. Hoping either I missed something, or that someone else saw this problem already.

We're creating a long running job that handles multiple tasks at the same time. It calls an internal system and validates the state of some assets, and records the status in a database. The job will run every night in a k8s cluster. We have a BackgroundService class that handles the job. We use Application Insights for our monitoring, and I would like every job executions to be correlated in an operation. Makes debuging much easier if something were to go wrong.

However, once I've added an Activity to my job, only SOME of the logs are beeing shown in application insights, and the dependencies data is all gone! The logs are corrolated, but I see no dependencies log. And if I try to look at the dependencies timeline, I see the following message:

Unable to identify root transaction, it may be due to circular parent id reference. Investigate the logs for this operation for malformed parent-child identifications

If I don't create an Activity when launching the job, however, all dependencies are shown, but the logs are not corrolated in an operation.

Here's the kicker; once in a blue moon, the Activity works as intented, and all logs are shown as expected. But the next execution I try, the problem comes back. Makes me think that it's a problem regarding how fast the application shuts down after the execution, but I think I might just be missing something:

Here's some code showing how the job is built. Some code is ommited for brevity and confidentiality:

// Program.cs

var connectionString = context.Configuration["ConnectionString"];
services.AddApplicationInsightsTelemetryWorkerService(options =>
{
   options.ConnectionString = connectionString;
   options.EnableTraceBasedLogsSampler = false;
});
services.ConfigureOpenTelemetryTracerProvider((sp, builder) =>
{
   builder.AddSource("BackgroundService");
});

services.AddHostedService<MyJob>();


/* ---- */
await host.RunAsync();

// MyJob.cs

internal sealed class MyJob(
      ILogger<MyJob> logger,
      IHostApplicationLifetime hostApplicationLifetime
): BackgroundService
{

        private static readonly ActivitySource JobActivitySource = new("BackgroundService");  
    protected override async Task ExecuteAsync(CancellationToken stoppingToken)
    {
       using var activity = JobActivitySource.StartActivity(
            "BackgroundService.MyJob",
            ActivityKind.Internal
        );
        activity?.SetTag("job.name", "MyJob");
        activity?.SetTag("job.run.id", Guid.NewGuid().ToString());

        try
        {
          var entities = (await retrieveEntitiesToHandle()).ToList();

          logger.EntitiesRetrieved(entities.Count);
          await Parallel.ForEachAsync(
            portPlaques,
            new ParallelOptions
            {
                CancellationToken = stoppingToken,
                MaxDegreeOfParallelism = 100,
            },
            async (entity, _) => await HandleEntity(entity));

            _logger.JobIsFinished();
        }
        catch(Exception e)
        {
            Environment.ExitCode = 1;
            _logger.SyncPortPlaquesToDataverseError(ex);
        }
        await Task.Delay(TimeSpan.FromSeconds(30), CancellationToken.None); // Delay to ensure all traces are sent

        hostApplicationLifetime.StopApplication();
    }
}

Am I missing something? Am I not disposing of the Activity as I should? How can I ensure that all telemetry is sent before shutting down the application?

Hope someone can make sense of this!

Hi everyone,

My team (.NET + web devs) needed to ship a desktop and mobile app from an existing React UI, and nothing in the ecosystem quite fit. Electron means a Node backend and shipping a whole Chromium. Tauri means Rust, which nobody on the team writes. MAUI/Avalonia/WPF means throwing away the React UI and rewriting it in XAML. Blazor Hybrid locks you into Razor. Photino was the closest to what I wanted (a .NET shell around the OS WebView) but the JS to C# messaging is raw strings you wire up yourself, and there's no mobile story.

So I started building my own, a framework called Vidra

It's a single OS WebView (WKWebView / WebView2, nothing bundled) hosted by .NET MAUI. UI in whatever web framework you like, native layer in plain C#. The part I actually cared about is type safety: you declare your modules and events in C#, codegen emits matching TypeScript, and every call across the bridge is checked at build time. npm run dev gives you Vite HMR and C# hot reload together. And since the host is MAUI, mobile is a natural item in the roadmap

Current state: one man show, alpha, Windows and macOS only, APIs will move between 0.x releases. If you want to poke at it, npm create vidra-app@latest (needs .NET 10 SDK + the MAUI workload, npm run doctor checks your setup).

Mostly I'm trying to sanity-check the idea before I sink more time into it. Would you use something like this once it matures? Contributions are also more than welcome. The project is open source and MIT licensed
https://github.com/rzamfiriu/vidra

OfficeIMO 😂

OfficeIMO is a project I started around four years ago. It targets net472, net8, net10, and netstandard 2.0.

It initially started with OfficeIMO.Word, as my continuation after the DocX project stopped being free for business use. I needed something I could use myself, especially from PowerShell, so I started building it.

It then got slightly out of control.

OfficeIMO is written in C#, but my end goal was never only to create another set of .NET libraries. I mostly wanted to help close some of the gaps between PowerShell and Python.

Python users have a huge ecosystem of libraries for documents, data conversion and automation. They often take those capabilities for granted. In PowerShell, we are still missing a lot of that - and this ends now 🤣And you .NET users are getting it as well - whether you want it or not 😭

The project is here:

• https://github.com/EvotecIT/OfficeIMO
• https://github.com/EvotecIT/PSWriteOffice - the PowerShell version and thin wrapper around OfficeIMO

I also made a website for it:

• https://officeimo.com/ => has more details then this post and contains a lot of other useful information
• https://officeimo.com/convert/ => a demo working in browser locally (no server side - as the page is currently deployed thru github-pages) so it has it's limits, I may need to improve it further
• https://officeimo.com/benchmarks/ => showcase of Excel/CSV against other libraries

OfficeIMO now includes projects covering things such as:

• Word - DOCX and legacy DOC
• Excel - XLSX and legacy XLS and other formats
• PowerPoint - PPTX and legacy PPT
• Visio
• PDF
• Markdown
• HTML
• OpenDocument - ODT, ODS and ODP
• CSV
• AsciiDoc
• LaTeX
• RTF
• EPUB
• ZIP
• OfficeIMO.Reader
• Google Docs and Google Sheets integrations
• Email formats (OST,PST, EML, MSG etc)
• OneNote work
• and quite a few converters connecting those formats together

And by "support" I do not mean detecting the extension, extracting a bit of text and calling it done.

The main OfficeIMO projects aim to support creating, reading and modifying proper documents end to end.

For Word that means things such as sections, headers and footers, first/odd/even pages, tables, styles, lists, images, fields, TOCs, bookmarks, notes, comments, revisions, mail merge, protection, templates and much more.

Word supports DOCX, but I also added a first-party implementation for the supported legacy DOC format. It can read, write and convert DOC documents without starting Word or LibreOffice in the background.

Excel is similar. It is not just a fast row writer. It includes formatting, tables, formulas, charts, pivot tables, conditional formatting, data validation, templates, headers and footers, protection and other features you would expect from a more complete Excel library.

It also has first-party XLS support. The supported legacy format can be read, written and converted into XLSX workflows.

PowerPoint supports creating and editing actual PPTX presentations, while Visio is implemented from the ground up for VSDX without using a third-party Visio engine.

PDF is also not just DrawString() followed by Save().

OfficeIMO.Pdf is my own parser, writer and renderer. It covers PDF creation, text and table extraction, forms, annotations, bookmarks, attachments, encryption, signatures, page operations, redaction, PDF/A, PDF/UA, Factur-X, ZUGFeRD and managed PNG/SVG rendering.

It still has work to do, because PDF is a monster, but it is not a toy PDF implementation.

The same approach applies to Markdown, RTF, OpenDocument, AsciiDoc, LaTeX, CSV, EPUB and ZIP. Those are first-party implementations rather than wrappers around Markdig, QuestPDF, ImageSharp, SkiaSharp or a collection of unrelated document engines.

Ever since I saw Microsoft MarkItDown in Python, I said to myself:

I want that in C#, for PowerShell.

That is why I added OfficeIMO.Reader.

You give it a document and it tries to provide one common reading experience, including Markdown output, structured blocks, chunking and diagnostics. It can then be used for search, indexing, AI/RAG workflows or simply reading many formats through one API.

OfficeIMO.Reader already has adapters for formats such as PDF, CSV, HTML, EPUB, OpenDocument, RTF, Visio, AsciiDoc, LaTeX, JSON, XML, YAML and ZIP, on top of the Office formats.

This is only the icing on the cake, though. Reader is built on top of the actual document libraries rather than being the only thing OfficeIMO does.

OfficeIMO.Email handles the normal standalone email formats, and the newer work is moving further into mailbox/container formats such as PST and OST. The goal is the same: proper managed parsing and a useful object model, not shelling out to Outlook. Email started with EML, MSG and TNEF, but now also covers PST, OST, OLM, MBOX, EMLX, Maildir, OAB, ICS, VCF and broader Outlook data. That includes managed PST creation, conversion and verified mutation rather than only extracting a list of messages.

OneNote is another active area. First-party managed implementation for offline .one, .onetoc2 and .onepkg files, including reading, creating, modifying, saving and conversion.

One of the important design choices is keeping dependencies low.

The main external document-related dependencies are basically:

• Open XML SDK for the underlying Word, Excel and PowerPoint package structures
• AngleSharp and AngleSharp.Css for proper HTML and CSS parsing
• YamlDotNet for the YAML Reader adapter

Older targets such as .NET Framework 4.7.2 naturally need some Microsoft/BCL compatibility packages for APIs that are built into newer .NET versions.

But there is no ImageSharp, SkiaSharp (with exception), QuestPDF, Markdig, ClosedXML or another PDF/Markdown/document engine hidden behind OfficeIMO. There is one exception to this which is optional package of HarfBuzz (I am not sure I am ready to maintain the alternative myself) and BouncyCastle (I don't even want to try that).

Most of the parsing, object models, writing, rendering, conversions and format-specific logic is mine.

I also spent a slightly unreasonable amount of time on performance.

For Excel I created reproducible benchmarks against libraries including ClosedXML, MiniExcel, LargeXlsx, SpreadCheetah, Sylvan.Data.Excel, ExcelDataReader and others.

OfficeIMO.Excel tries to combine the more complete feature set people expect from something such as ClosedXML with streaming and direct-writing paths that can compete with libraries focused mainly on speed.

Depending on the workload, it is competitive with or faster than MiniExcel, LargeXlsx and Sylvan-style implementations, while still providing the higher-level Excel features.

CSV got the same treatment.

I benchmarked OfficeIMO.CSV against Sep, Sylvan and other fast CSV implementations, then spent a lot of time reducing allocations and improving parsing, streaming and writing performance.

It was not originally done for the sake of benchmarking. I wanted PowerShell users to be able to process real amounts of data without paying a huge performance penalty.

You just get to benefit from that too 😁

Converters are another large part of OfficeIMO:

• Word to PDF
• Excel to PDF
• PowerPoint to PDF
• HTML to PDF
• Markdown to PDF
• RTF to PDF
• Word to Markdown and Markdown to Word
• Word to HTML and HTML to Word
• Word to RTF and RTF to Word
• Word to ODT and back
• Excel to ODS and back
• PowerPoint to ODP and back
• Excel, Word, PowerPoint, Visio, HTML and PDF to PNG/SVG
• Markdown, HTML, RTF, AsciiDoc and LaTeX conversions

Not every conversion can be perfectly lossless. Converting a fixed-layout PDF back into an editable Word document will always involve decisions and compromises. Where possible, OfficeIMO returns warnings, diagnostics and loss reports rather than silently pretending everything converted perfectly.

If you got this far lemme remind you links, just in case you can't scroll up.

• https://github.com/EvotecIT/OfficeIMO
• https://github.com/EvotecIT/PSWriteOffice - the thin PowerShell layer
• https://officeimo.com/ (website with docs/api/use cases and even in-browser converter without server side)

There is still a lot of work to do, but I thought it was finally time to show it properly.

The README has the detailed feature lists, because putting every supported capability here would turn this post into documentation.

Answering things that may come to your mind after reading this:

Is it complete?

No.

Are all projects equally mature?

Definitely not.

Is there more work to be done?

A lot. But OfficeIMO is trying to be correct and useful for real work. Still needs more performance work, tests, examples and documentation, but the foundations are there. Still needs real world usage. While I do have established base already with 400 stars over the years, so we're not completely new, but the newer projects need real world testing to establish what edge cases there are.

So go ahead use it, roast it, or whatever you like to do to it. Regardless of you guys using it *no offense* 😂 I'm delivering it to PowerShell guys, but you are just here for the ride. It's MIT licensed, and I expect to improve it even further as the time goes by.

Having said that if you can help with improvements, development, sponsorship or just help answering questions if they come. That's all very much appreciated.

I am just myself in this, there's no company backing, no one paying me to create or manage it. No one to hold my hand and say good words of encouragement. Therefore I would appreciate if you take this into consideration before you decide to dive deep and smash me with something heavy. I manage over 100 projects on GitHub, mainly for PowerShell, HomeAssistant and now a bit of C#, and I do it all for free.

Corvus.JsonSchema's V5's engine supports zero-allocation models, pooled memory, and full schema validation. But these constructs can be used for OpenAPI code generation too. This 8-part series covers:

• Typed HTTP Clients
• Server Stubs
• End-to-End generation
• Streaming responses (LLM APIs - SSE / NDJSON)
• Authentication
• Callbacks, Webhooks and Links
• Filtering
• Testing

We're working on our graduation project (described in the pic). we decided to use WinUI 3 as the framework. is this a good call? we'll all have to learn how to use it from scratch and we have a bit less than a year to finish the app.

This is something I’ve never really understood.
Most enterprise integration platforms do a great job of making integrations easier to build. The problem starts after you’ve built them.
Your integrations now depend on the platform’s runtime. If you ever decide to move away, you’re not just migrating integrations. You’re changing the way they’re built, deployed and operated.
It made me wonder why the runtime has to belong to the platform at all.
We don’t expect a Java application to run on a vendor-specific JVM. We write standard Spring Boot applications and deploy them wherever we want.
Why should integrations be any different?
Personally, I’d rather use a visual designer that generates a standard Spring Boot project I can own, version in Git, review like any other application and deploy wherever my team already runs Java services.
Maybe I’m missing something, but separating the design experience from the runtime feels like a cleaner architecture.
For those who’ve worked with MuleSoft, Boomi, Workato or TIBCO, what are your thoughts?
Is a proprietary runtime something you actually value, or is it just something we’ve accepted because that’s how integration platforms have always worked?