01
Application domains
Example: Plug-in loading or isolation inside one process
Approach: Separate processes or containers, and AssemblyLoadContext for loading assemblies
.NET Development
C# and .NET development services
Many businesses still run on a .NET Framework system that works but is getting harder to change, host and secure. Agnotic Technologies builds new C# services on current .NET and moves existing ones forward, with tests at every step.
ASP.NET CoreFramework to .NET portsAzure and AWSTested releases
Trusted by global innovators
C# and .NET
What do C# and .NET development services cover?
C# and .NET development services cover building new ASP.NET Core APIs and web applications, moving .NET Framework 4.x systems to a current long-term support release of .NET, and hosting both on Microsoft Azure or AWS. Agnotic Technologies does this work for the client, from the first scoping call to support after release.
This page is about the .NET stack itself. General backend architecture is on our backend development page.
Most .NET work we see is not new. It is a system that has run the business on .NET Framework for years, now held back by a support date, a Windows-only server or a library that no longer ships updates.
What do we build in C# and .NET?
The parts of a .NET system we design, write and test for clients.
ASP.NET Core APIs
REST and gRPC services with OpenAPI descriptions, sign-in through your identity provider and versioning from the first release.
Data access
Entity Framework Core where it fits, Dapper or plain ADO.NET where query control matters, with migrations kept in source control.
Web applications
Razor Pages, MVC or Blazor, chosen by who maintains the app and how interactive it needs to be.
Background and integration services
Worker services, queues and scheduled jobs for imports, exports and messages to other systems.
Ports from .NET Framework
Class libraries, web apps and services moved to current .NET project by project, with tests run at each step.
Testing and release
xUnit or NUnit unit tests, integration tests against real databases in containers, and pipelines that build and deploy.
Decision table
Which migration path fits your .NET version?
We place each application in one of these rows during the assessment. The row decides the path and the evidence we need before cutover.
| Where you are | Likely path | Blockers to check | Test evidence before cutover |
|---|---|---|---|
| .NET Framework 4.8 or 4.8.1, still changing often | Port to the current LTS release of .NET, library by library | WCF services, Windows-only APIs and packages with no current .NET build | Existing tests passing on both builds, plus integration tests on key flows |
| .NET Framework 4.6.2 to 4.7.2 | Move to 4.8.1 first if a port is far off, then port | Support dates for older 4.x versions; packages that dropped old frameworks | Smoke tests on the 4.8.1 build before port work starts |
| ASP.NET Web Forms application | Rebuild screen by screen in Razor Pages or Blazor beside the old app | Web Forms has no direct port; view state and page lifecycle code need redesign | Side-by-side checks of each rebuilt screen against the old one |
| WCF server or .NET Remoting | CoreWCF for WCF, or new gRPC or REST endpoints | Remoting is not supported on current .NET; a WCF server needs CoreWCF | Contract tests for every client that calls the service |
| AppDomains, Code Access Security or Workflow Foundation | Redesign that part: separate processes or containers, or another workflow engine | These are not available on current .NET | Behavior tests written before the redesign and run after it |
| Out-of-support .NET Core or .NET | Upgrade to the current LTS release | Breaking changes listed for each version in between | Full regression run and a performance comparison |
Staying on .NET Framework 4.8.1 and patching is a valid choice for a stable system that rarely changes, on a supported Windows release.
Port blockers
Which .NET Framework features block a straight port?
We scan for these first, because they decide whether a port is a recompile or a redesign.
02
.NET Remoting
Example: Calls between app domains or processes
Approach: Named pipes, gRPC or a message queue between processes
03
Code Access Security
Example: Partial trust sandboxes for add-ins
Approach: Operating system or container isolation, since CAS is no longer a security boundary
04
WCF server
Example: SOAP services that partner systems call
Approach: CoreWCF packages, or a new REST or gRPC endpoint with the old one retired later
05
Windows-only APIs
Example: Registry access, Windows services, System.Drawing on servers
Approach: Keep Windows hosting for now, or swap in cross-platform libraries before moving to Linux containers
Hosting
How do we host .NET applications on Azure or AWS?
The hosting pattern we choose depends on what the code needs from Windows and how the team runs operations.
Build
- Build and test in CI on every change
- Linux container images where possible
- Windows containers or VMs where APIs need them
Run on Microsoft Azure
- Azure App Service
- Azure Container Apps or AKS
- Azure SQL Database
Run on AWS
- Amazon ECS or AWS Elastic Beanstalk
- AWS Lambda for small functions
- Amazon RDS for SQL Server or PostgreSQL
Operate
- Health checks and structured logs
- OpenTelemetry traces and metrics
- .NET servicing updates applied as they ship
Failure points
Where do .NET Framework ports stall?
What we see on stalled ports, and how we keep ours moving.
Challenge
A NuGet package the app depends on has no build for current .NET.
Agnotic approach
We find a maintained replacement, or wrap the old code behind an interface, before the port starts.
Challenge
Configuration lives in web.config transforms nobody understands.
Agnotic approach
Settings move to appsettings files and environment variables, each value traced to where it is used.
Challenge
There are almost no automated tests.
Agnotic approach
We write characterization tests around current behavior first, so the port can be checked against them.
Challenge
Everything is ported at once and nothing ships for months.
Agnotic approach
Shared libraries move first and target both frameworks, so the old app keeps shipping while the port continues.
Challenge
The app runs on one server with hand-installed components.
Agnotic approach
We script the environment and containerize it, so every environment matches.
Who it is for
Teams that bring us .NET work
Teams with C# code to build, move or take over.
Businesses on .NET Framework
A line-of-business system that needs to move to current .NET without stopping feature work.
Product teams adding services
New ASP.NET Core APIs beside an existing product, built to the team's conventions.
Teams inheriting a codebase
A .NET system whose original developers have left, needing a review, tests and a plan.
Microsoft-stack organizations moving to the cloud
Apps that ran on Windows servers on site, moving to Azure or AWS.
C# for startups
A startup choosing .NET for its backend, with a first release scoped and built end to end.
Healthcare and regulated teams
.NET systems that handle sensitive data, built with audit logs and access controls from the start.
Scope and cost
What drives the cost of C# and .NET work?
We do not publish prices. These are what we size on the scoping call.
Codebase size and shape
How many projects, libraries and services, and how tightly they depend on each other.
Port blockers
How much Web Forms, WCF, Remoting or Windows-only code the scan finds.
Test coverage
Whether tests exist or characterization tests must come first.
Hosting target
Staying on Windows servers, or moving to containers on Azure or AWS.
Integrations
Databases, queues and partner systems the code talks to.
New features alongside
Whether feature work continues during the port.
Standards
Standards behind our .NET work
The language, API and security references behind our .NET work.
ECMA-334.NET LTS releasesOpenAPIOWASP ASVSOpenTelemetryOAuth 2.0 and OpenID Connect
Facts and sources
Facts behind C# and .NET development
Support dates and platform rules that shape a .NET plan, each linked to its primary source.
A new major .NET release ships every November; even-numbered releases are long-term support releases with three years of free support and patches, and odd-numbered releases get two years.
Source: .NET and .NET Core official support policy (Microsoft)Application domains, .NET Remoting, Code Access Security and Windows Workflow Foundation are not available on .NET 6 and later; a WCF server can run on current .NET through the CoreWCF packages.
Source: Microsoft Learn: .NET Framework technologies unavailable on .NET 6+Microsoft's lifecycle listing shows .NET Framework 4.6.2 reaching end of support in January 2027, while 4.7 to 4.8.1 have no end date listed.
Source: Microsoft Lifecycle: Microsoft .NET FrameworkThe C# language is standardized as ECMA-334; the 7th edition, published in December 2023, defines the syntax, constraints and semantic rules of C# programs.
Source: Ecma International: ECMA-334
Engagement
How does a .NET engagement work?
Three stages, each with a clear output.
1.
Scoping call and code scan
We review the solution files, packages and blockers, and agree the first release.
Scope2.
Fixed-scope first release
A new service or the first ported projects, built, tested and deployed to your hosting.
Build3.
Continue and support
The remaining projects, new features and support under agreed change control.
SupportFrequently Asked Questions
We do not publish prices. It depends on codebase size, how much Web Forms, WCF or Windows-only code the scan finds, test coverage, the hosting target and whether feature work continues. You get a written proposal after the code scan.
For a stable system that rarely changes and runs on supported Windows, staying and patching can be the right call. If the system changes often, needs Linux containers or depends on libraries dropping .NET Framework, porting pays off.
Yes, and it is often the safest route. New ASP.NET Core services take over features one at a time while the old app keeps running, and shared libraries are built to target both.
Both. We host .NET on Azure App Service, Container Apps or AKS, and on AWS with ECS, Elastic Beanstalk or Lambda, depending on what the code needs and what your team already runs.
Yes. We start with a review of the code, build and tests, write down what we find and agree a plan before changing anything.
It can be: C# is fast, typed and well supported on Linux and the major clouds. The better question is who will maintain it. We help founders choose the stack their future team can hire for.
AI assistants can speed up repetitive port work such as API replacements, but each change goes through code review, the test suite and your release process. Nothing is merged on an AI suggestion alone.