When working with software development teams — whether as a developer, architect, or technical manager — one pattern tends to surface repeatedly in inherited or long-running projects: the monolithic solution. Everything lives in a single Visual Studio solution file, regardless of whether the code targets different runtimes, serves different purposes, or is deployed to completely different environments. The intent is usually convenience, but the long-term cost is significant. This post outlines why splitting code into separate, purpose-driven repositories is the better approach — and why mixing .NET versions in a single solution in particular should be avoided. What Does a Monolithic Solution Look Like? A monolithic solution in the .NET world typically includes a mix of project types under one solution file (.sln). For example, a Dynamics 365 / Power Platform project might contain: Plugins targeting .NET Framework 4.6.2 Azure Functions targeting .NET 8.0 (or even .NET 10.0) C...
When setting up a Proxmox VE environment it is common to end up with a node named pve , which is the default hostname assigned during installation. This becomes a problem when managing multiple Proxmox servers since every node will show up as pve in the web UI. This post covers the complete process for renaming a Proxmox node to a meaningful name including the FQDN, and how to handle the pmxcfs filesystem quirks that make this more involved than a standard Linux hostname change. Understanding How Proxmox Uses the Hostname Proxmox VE derives the node name directly from the short hostname (the part before the first dot). This means a server configured with the FQDN pve-node-1.example.lan will appear in the UI as pve-node-1 . It is important to plan the naming convention carefully upfront. A naming scheme like pve-node-1 , pve-node-2 works well because the short hostname is already fully unique, without relying on the domain portion to differentiate nodes. Proxmox stores its ...