DEV Community: MICHAEL-MAURICE

I Got Tired of Rebuilding the Same AI SaaS Plumbing, So I Packaged It

MICHAEL-MAURICE — Fri, 09 Oct 2026 19:24:49 +0000

Originally published on Medium.

A complete multi-tenant AI SaaS in C# and .NET 10: teams, Stripe billing, metered AI credits, RAG with citations and streaming chat. 101 tests, full source, $79.

Every AI product idea I've had lately started the same way. I'd get excited about the actual feature, the clever prompt or the document assistant, and then lose two weeks to everything around it.

Who belongs to which organization? What happens when someone gets removed from a team? How do I stop a free user from burning $40 of GPT tokens in an afternoon? Why did Stripe send subscription.updated before subscription.created, and why did my app just downgrade a paying customer?

None of that is the product. All of it has to work before anyone can pay you.

So I built it once, properly, and tested it. Today I'm releasing it as the AI SaaS Starter Kit for .NET 10: elitesolutions1.gumroad.com/l/ufvbep. For a limited time, the code ELITE40 takes 40% off.

What it actually is

It's not a template with a login page and a "your AI feature here" comment. It's a working, multi-tenant AI SaaS written in C# on ASP.NET Core 10, EF Core 10 and Microsoft.Extensions.AI 10.10. You rename it, plug in your OpenAI and Stripe keys, and customers can sign up, invite their team, pick a plan and pay monthly, while every token they use is counted against that plan.

The part I'm proudest of is small: it runs with no API keys at all. The default provider is a little offline model that streams real answers from your uploaded documents. Clone it, run dotnet test, run the app, sign in with the seeded demo account, and ask "How long do refunds take to arrive?" You get a streamed answer with a citation pointing at refund-policy.md. No account, no credit card, no surprise bill. When you're ready, switching to OpenAI (or any OpenAI-compatible endpoint) is one setting.

What's inside

Here's the honest list, grouped the way I think about it.

Tenancy that doesn't rely on you remembering a Where clause. Organizations with Owner, Admin and Member roles, invitations, and users who can belong to several orgs with a switcher. Every tenant-owned table gets an EF Core global query filter, and SaveChanges has a guard that refuses cross-tenant writes. Membership is re-checked on every request, so someone you remove loses access right away, not when their cookie expires.

Stripe billing that survives real webhooks. Checkout and the Customer Portal over plain REST (no SDK lock-in). Webhooks are signature-verified, recorded in an idempotency ledger, and protected against out-of-order delivery, so a late event can't roll a subscription back. Only your own Price ids can grant a paid plan. There's also a billing simulator, so you can build the whole upgrade flow before you even open a Stripe account.

Metered AI credits. Every model call goes through a DelegatingChatClient that bills the current organization. Plans get monthly credit allowances, models get per-token weights, and there's a live usage dashboard. When an org is out of credits it gets a 402 "upgrade required" before any streaming starts, and when it's nearly out, the answer is capped to what the balance can afford.

RAG with citations. Upload documents, and they're chunked, embedded and searched with cosine similarity. Answers carry numbered citations, and retrieved text is fenced off to blunt prompt injection. Moving to pgvector, Azure AI Search or Qdrant means replacing one method.

Streaming chat. Server-Sent Events using .NET 10's TypedResults.ServerSentEvents, conversation history, errors delivered inside the stream, and partial answers saved if the provider fails mid-reply.

A public API for your customers. Versioned /api/v1 endpoints with hashed, revocable API keys (shown once, like they should be), sharing the same credits and limits as the web app.

The boring production stuff. Per-plan rate limits with 429 and Retry-After, CSRF protection, a strict CSP, an audit log, health checks, OpenTelemetry, a Dockerfile plus docker-compose with PostgreSQL, and GitHub Actions CI. SQLite in development so there's zero setup.

101 xUnit tests, all passing. Unit tests plus full integration tests with WebApplicationFactory, covering tenant isolation, billing edge cases, metering, quotas, rate limits, invitations and API keys.

Two bits of real code

I'd rather show you than tell you it's well built. This is the streaming half of the metering client, straight from the project. The finally block is the whole point: it runs when the stream completes, when it fails, and when the user closes the tab halfway through. The provider charged you for those tokens either way, so the tenant gets billed either way.

public sealed class MeteringChatClient(IChatClient innerClient, UsageMeter meter, string feature = "chat") : DelegatingChatClient(innerClient)
{
    public override async IAsyncEnumerable<ChatResponseUpdate> GetStreamingResponseAsync(
        IEnumerable<ChatMessage> messages, ChatOptions? options = null, [EnumeratorCancellation] CancellationToken cancellationToken = default)
    {
        var list = messages as IList<ChatMessage> ?? messages.ToList();
        var text = new StringBuilder();
        long? input = null, output = null;
        string? model = null;

        try
        {
            await foreach (var update in base.GetStreamingResponseAsync(list, options, cancellationToken).ConfigureAwait(false))
            {
                model ??= update.ModelId;
                foreach (var content in update.Contents)
                {
                    switch (content)
                    {
                        case TextContent t:
                            text.Append(t.Text);
                            break;
                        case UsageContent u:
                            input = (input ?? 0) + (u.Details.InputTokenCount ?? 0);
                            output = (output ?? 0) + (u.Details.OutputTokenCount ?? 0);
                            break;
                    }
                }

                yield return update;
            }
        }
        finally
        {
            // Runs on completion, failure and cancellation alike: the provider charged for what it generated.
            var estimated = input is null || output is null;
            await meter.RecordAsync(
                feature,
                model ?? options?.ModelId,
                input ?? EstimateInput(list),
                output ?? CreditCalculator.EstimateTokens(text.ToString()),
                estimated,
                CancellationToken.None).ConfigureAwait(false);
        }
    }
    // ... GetResponseAsync (non-streaming) does the same, minus the stream
}

If the provider reports token counts, it uses them. If it doesn't, it estimates and flags the record as estimated, so you can tell the difference later. Because it's ordinary Microsoft.Extensions.AI middleware, swapping providers doesn't touch the billing.

The second one is the tenant guard in the DbContext. Query filters stop you from reading another tenant's rows. This stops you from writing them, which is the bug that tends to show up at 2 a.m. in a background job:

private void StampTenant()
{
    foreach (var entry in ChangeTracker.Entries<ITenantOwned>())
    {
        if (entry.State == EntityState.Added && entry.Entity.OrganizationId == Guid.Empty)
        {
            entry.Entity.OrganizationId = CurrentOrganizationId
                ?? throw new InvalidOperationException($"Cannot add {entry.Entity.GetType().Name} without an active organization.");
        }

        if (entry.State is EntityState.Added or EntityState.Modified or EntityState.Deleted &&
            CurrentOrganizationId is { } current && entry.Entity.OrganizationId != current)
        {
            throw new InvalidOperationException(
                $"Cross-tenant write blocked: {entry.Entity.GetType().Name} belongs to another organization.");
        }
    }
}

New rows get stamped with the current organization automatically. Anything that would touch another org's data throws. Code that genuinely needs to cross tenants, like the Stripe webhook handler, has to say so explicitly with IgnoreQueryFilters().

Who I built it for

Solo developers launching a micro-SaaS. You have an idea for an AI tool for lawyers, or landlords, or dental clinics. The kit gives you signup, teams, plans, payments and usage limits on day one, so the next weekend goes into the part your customers will actually notice.

Freelancers and agencies. "Build us an AI assistant that knows our internal docs" is one of the most common client requests right now. That's document upload, grounded answers with citations, per-company isolation and usage tracking, which is this kit. The commercial license covers unlimited personal and client projects. The only thing you can't do is resell the kit itself.

Teams that want a tested reference. Maybe you'll never ship this code as-is. That's fine. Having a working, tested answer to "how should multi-tenant AI billing work in .NET 10?" saves a lot of whiteboard arguments, and the 101 tests tell you exactly which edge cases were thought about.

The time math

I won't pretend there's a precise number, but here's my rough take. Getting tenant isolation right, with filters, the write guard, role checks and invitations, is a week for most people, and longer if you do it carefully. Stripe subscriptions with webhooks that are idempotent and handle out-of-order events is another week, and most first attempts get the ordering wrong. Token metering that also works for streamed and cancelled requests is a few days, plus the quota checks, plus the usage page. Then there are tests for all of it.

That adds up to weeks of work that no customer will ever thank you for, because when it works it's invisible. At $79 (or about $47 with the code) it's less than one billable hour for most of us.

To be clear about the limits: the kit doesn't include hosting, API credits or a Stripe account. The tests run against the offline model and the billing simulator, so you'll still want to do your own run against your real Stripe test keys and model provider before you go live.

Get it now

I'm genuinely excited about this one. It's the codebase I wish I'd had for every AI idea I started and abandoned at the "now add billing" stage.

Use the code ELITE40 for 40% off: about $47 instead of $79. It's a limited-time offer, so don't wait too long if you want it. And ELITE40 takes 40% off everything in my Elite Solutions store, the kit included, so it's a good moment to look around.

👉 Get the AI SaaS Starter Kit for .NET 10

Full C# source, 101 passing tests, and a commercial license. Rename it and ship something.

Want a new tested .NET + AI project every day, with full source? That's what Tech Skill Builder is for.

Don't Hand Your AI Agent the Keys: Building a Secure Remote MCP Server in ASP.NET Core

MICHAEL-MAURICE — Fri, 09 Oct 2026 18:11:50 +0000

Originally published on Medium. Full source code for this project is in Tech Skill Builder: https://elitesolutions1.gumroad.com/l/TechSkillBuilder

The MCP C# SDK 2.x went stateless with the 2026-07-28 spec. Here's how to wrap it in authentication, role-based tools, auditing and human approval, with a tested .NET 10 project you can run in five minutes.

Most Model Context Protocol demos look the same. You get one Echo tool on stdio, a Claude or Copilot screenshot, and that's it. Then someone asks for the same thing as a shared HTTP service that agents across the company can call, and the hard questions start. Who is calling? Which tools should they see? What happens when the model decides to close a customer's ticket at 3 a.m.?

This article answers those questions with the official MCP C# SDK 2.2 on .NET 10. We'll build a support desk MCP server where:

callers authenticate, and each one only sees the tools their role allows,
tools return typed, schema-described results instead of strings,
every call is audited, including the ones that were denied,
a human approves anything destructive before it runs.

Everything here comes from a complete project with 52 passing tests. It runs without an AI key.

The problem: MCP tools are an API, so treat them like one

An MCP tool is a remote procedure an LLM can call with arguments it made up. That makes it an API endpoint with a very creative client. All the usual API rules apply, plus a few new ones:

The tool list is an attack surface. If a read-only bot can see close_ticket, a prompt injection is one sentence away from using it.
Identity can't come from arguments. If add_comment(author, text) takes the author as a parameter, the model can claim to be anyone.
Errors have two audiences. The model needs readable failures ("ticket not found") so it can recover. Your logs need the details. The model must never see a stack trace.
Some actions need a person. The MCP specification says there SHOULD always be a human in the loop with the ability to deny tool invocations.

The timing matters too. Version 2.0 of the C# SDK (July 2026) aligned with the 2026-07-28 MCP specification. That revision removes the initialize handshake and the Mcp-Session-Id header from the wire format. Clients bootstrap with server/discover, and the SDK now defaults HTTP servers to stateless mode. Stateless servers scale behind any load balancer, which is exactly what you want for a shared service. It also means you can't lean on session state for security.

Architecture

Agent (IChatClient + FunctionInvokingChatClient)
   â”‚  Streamable HTTP, X-Api-Key header, MCP-Protocol-Version: 2026-07-28
   â–¼
ASP.NET Core pipeline
   Host filtering (AllowedHosts) â†’ Authentication (API key â†’ ClaimsPrincipal)
   â†’ Authorization (endpoint requires an authenticated user)
   â†’ Rate limiting (partitioned per caller)
   â–¼
MapMcp("/mcp")   SessionMode = Stateless
   AddAuthorizationFilters()   [Authorize(Roles = ...)] on tool classes
   Call-tool audit filter      caller, tool, outcome, duration
   â–¼
Tools: get_ticket Â· list_my_tickets Â· search_knowledge_base   (any role)
       add_ticket_comment Â· escalate_ticket                  (Agent, Admin)
       close_ticket                                          (Admin, destructive)

The rule is defense in depth. ASP.NET Core decides whether you may talk to the server at all. The MCP layer decides which tools you get. The agent decides whether a human must confirm.

Step 1: A stateless MCP endpoint behind normal ASP.NET Core security

dotnet new web -n SupportDesk.McpServer
dotnet add package ModelContextProtocol.AspNetCore --version 2.2.0

builder.Services.AddMcpServer(o =>
    {
        o.ServerInfo = new Implementation { Name = "support-desk", Version = "1.0.0" };
        o.ServerInstructions = "Look tickets up before changing them...";
    })
    .WithHttpTransport(http => http.SessionMode = HttpServerSessionMode.Stateless)
    .AddAuthorizationFilters()
    .WithTools<TicketReadTools>()
    .WithTools<TicketWriteTools>()
    .WithTools<TicketAdminTools>();

var app = builder.Build();
app.UseAuthentication();
app.UseAuthorization();
app.UseRateLimiter();

app.MapMcp("/mcp")
    .RequireAuthorization()
    .RequireRateLimiting("per-caller");

Stateless is already the default in 2.x. Set it anyway. The SDK docs recommend setting SessionMode explicitly so a future default change can't silently alter your server. If you still have older clients that need sessions, 2.2 added StatefulForInitializeClients. That mode gives initialize-handshake clients a session and serves 2026-07-28 clients statelessly on the same endpoint.

MapMcp returns a normal endpoint convention builder, so RequireAuthorization() and RequireRateLimiting() work as they do on any minimal API.

Step 2: Authenticate callers without storing secrets

For service-to-service agents, an API key per caller is a pragmatic start. Two details make it safe. Store only a SHA-256 hash of each key in configuration, and compare in constant time:

var presented = SHA256.HashData(Encoding.UTF8.GetBytes(headerValue));

ApiKeyClient? match = null;
foreach (var client in Options.Clients)
{
    if (TryDecode(client.KeySha256, out var expected)
        && CryptographicOperations.FixedTimeEquals(presented, expected))
    {
        match ??= client;
    }
}

if (match is null) return Task.FromResult(AuthenticateResult.Fail("Invalid API key."));

var claims = new List<Claim> { new(ClaimTypes.Name, match.Name) };
claims.AddRange(match.Roles.Select(r => new Claim(ClaimTypes.Role, r)));
var identity = new ClaimsIdentity(claims, "ApiKey", ClaimTypes.Name, ClaimTypes.Role);

The handler produces an ordinary ClaimsPrincipal. The SDK copies it from HttpContext.User into every MCP request, so filters and tools can use it.

When the client acts for a person, like an IDE using your server on behalf of a developer, use OAuth instead. The MCP authorization spec builds on OAuth 2.1 and Protected Resource Metadata (RFC 9728). The SDK supports it through AddJwtBearer() plus its AddMcp() authentication scheme. The rest of this design doesn't change, because both paths end in a ClaimsPrincipal.

Step 3: Role-based tools that are invisible to the wrong caller

With AddAuthorizationFilters(), standard [Authorize] attributes work on tool classes and methods:

[McpServerToolType]
[Authorize(Roles = "Agent,Admin")]
public sealed class TicketWriteTools(TicketStore tickets)
{
    [McpServerTool(Name = "escalate_ticket", ReadOnly = false, Destructive = false,
                   Idempotent = true, UseStructuredContent = true)]
    [Description("Escalates a ticket to the platform team and raises its priority to at least High.")]
    public TicketDetails Escalate(
        ClaimsPrincipal user,
        [Description("Ticket id in the form TCK-1234.")] string ticketId,
        [Description("Why the ticket needs escalation.")] string reason)
    {
        var id = ToolGuard.TicketId(ticketId);
        var text = ToolGuard.Text(reason, nameof(reason));
        return ToolGuard.Run(() => TicketDetails.From(tickets.Escalate(id, user.Identity!.Name!, text)));
    }
}

The SDK enforces this in two places. On tools/list, unauthorized tools are removed from the response. On tools/call, an unauthorized call is rejected with an "Access forbidden" error. Our tests check both. The viewer key sees three tools, the agent key sees five, the admin key sees six. A viewer calling escalate_ticket by name gets an exception, not a result.

Hiding tools matters more than it sounds. A model can't be talked into calling a tool it never heard of.

Look at the ClaimsPrincipal user parameter. The SDK resolves it from the current request and leaves it out of the tool's input schema. The model can't see it or set it. Comments and escalations are always attributed to the authenticated caller.

Step 4: Typed results and two kinds of errors

UseStructuredContent = true makes the SDK generate an output JSON Schema from the return type and serialize the value into structuredContent. Clients get a contract instead of prose they have to parse. In 2.x, non-object return values are emitted as-is (structuredContent: 72), with no { "result": ... } wrapper. That's one reason the project returns small records rather than bare arrays.

Errors need more care. The SDK separates them like this:

McpProtocolException becomes a JSON-RPC error. Use it when the request itself is malformed.
McpException becomes a tool result with IsError = true that includes your message. The model can read it and recover.
Any other exception also becomes IsError = true, but with a generic message, so internal details don't leak.

public static string TicketId(string? ticketId)
{
    var id = ticketId?.Trim();
    if (!TicketStore.IsValidId(id))
        throw new McpProtocolException(
            $"'{ticketId}' is not a valid ticket id. Expected the form TCK-1234.",
            McpErrorCode.InvalidParams);
    return id!.ToUpperInvariant();
}

public static T Run<T>(Func<T> action)
{
    try { return action(); }
    catch (TicketNotFoundException ex) { throw new McpException(ex.Message); }
    catch (TicketRuleException ex) { throw new McpException(ex.Message); }
}

When an agent asks about TCK-9999, the model gets a tool error that includes "Ticket TCK-9999 was not found." and can tell the user. When it sends 1001 OR 1=1, the call fails as InvalidParams before any business code runs.

Step 5: Audit everything, including denials

A call-tool filter wraps every tool invocation:

.WithRequestFilters(f => f.AddCallToolFilter(next => async (context, ct) =>
{
    var audit = context.Services!.GetRequiredService<AuditLog>();
    var caller = context.User?.Identity?.Name ?? "anonymous";
    var argumentNames = context.Params?.Arguments?.Keys.Order().ToArray() ?? [];
    var started = Stopwatch.GetTimestamp();
    try
    {
        var result = await next(context, ct);
        audit.Record(new(DateTimeOffset.UtcNow, caller, context.Params!.Name,
            result.IsError == true ? "tool_error" : "ok",
            Stopwatch.GetElapsedTime(started).TotalMilliseconds, argumentNames));
        return result;
    }
    catch (Exception ex) when (ex is not OperationCanceledException)
    {
        // record protocol_error / tool_error, then rethrow
        throw;
    }
}));

Notice it records argument names, never values. Tool arguments are model-generated text that often contains customer data. Your audit trail shouldn't become a second copy of it.

Here's a detail I only found while testing. Denied calls never reach this filter. The SDK's tool authorization runs before the ordinary call-tool filter pipeline, so a forbidden call is rejected first. It does go through ASP.NET Core's IAuthorizationService, with the MCP RequestContext<CallToolRequestParams> as the resource. So the project decorates the default authorization service and records failures for that resource type. Failures for tools/list filtering are skipped, since a hidden tool isn't an incident.

Step 6: Put a human in front of destructive tools

On the client side, MCP tools plug straight into Microsoft.Extensions.AI: McpClientTool is an AIFunction. That lets us use MEAI's approval support. Wrap a tool in ApprovalRequiredAIFunction, and FunctionInvokingChatClient returns a ToolApprovalRequestContent instead of running it.

Which tools need approval? Tool annotations tell us. Under the MCP schema, readOnlyHint defaults to false and destructiveHint defaults to true. So a tool that says nothing about itself should be treated as destructive:

public static bool RequiresApproval(Tool tool)
{
    var a = tool.Annotations;
    if (a?.ReadOnlyHint == true) return false;
    return a?.DestructiveHint != false;
}

var tools = (await mcp.ListToolsAsync())
    .Select(t => RequiresApproval(t.ProtocolTool) ? new ApprovalRequiredAIFunction(t) : (AITool)t)
    .ToList();

The agent loop answers approval requests and calls the model again:

var response = await chatClient.GetResponseAsync(history, new() { Tools = tools });
history.AddMessages(response);

var requests = response.Messages.SelectMany(m => m.Contents)
    .OfType<ToolApprovalRequestContent>().ToList();

foreach (var request in requests)
{
    var approved = await approve((FunctionCallContent)request.ToolCall, ct);
    answers.Add(request.CreateResponse(approved, approved ? null : "Rejected by operator."));
}
history.Add(new ChatMessage(ChatRole.User, answers));

A word of caution: the spec says clients MUST treat annotations as untrusted unless they come from trusted servers. They're fine for a server you operate. For third-party servers, keep your own allow list.

For a real model, the project uses OpenAI through the Responses API (GetResponsesClient().AsIChatClient("gpt-6-luna")). OpenAI's current guidance is to use Responses for tool calling with the GPT-6 family. For tests and demos, a deterministic offline IChatClient drives the same loop with no key.

Real-world use cases

Internal support and ops copilots that read tickets broadly but escalate or close only with the right role and a human click.
Platform APIs exposed to agents. Wrap the deployment or feature-flag API you already have, and make rollbacks destructive tools.
Multi-tenant SaaS integrations. Map each tenant's key or token to claims, and filter data by the injected ClaimsPrincipal.
Regulated environments where an audit trail of who did what through which AI tool is a hard requirement.

Best practices

Set SessionMode explicitly. Choose Stateless unless you truly need server-push or session state.
Put authorization on the tool, not in the prompt. Instructions are suggestions. [Authorize] is enforced.
Get identity from ClaimsPrincipal injection. Never accept "user" as an argument.
Return records with UseStructuredContent = true, and keep the contract stable (strings instead of enums on the wire).
Annotate every tool honestly with ReadOnly, Destructive and Idempotent. Clients use those hints to decide on confirmation.
Use McpException for errors the model should read, and let everything else stay generic.

Common mistakes

Leaving AllowedHosts as *. The SDK docs warn this exposes local servers to DNS rebinding. The project sets loopback hosts for development and has a test that sends a hostile Host header.
Relying on the system prompt for permissions. One prompt injection undoes it.
Logging tool arguments. This is the fastest way to leak PII into your log store.
Assuming an ordinary filter sees every call. Authorization failures happen earlier. Audit them separately.
Stateful by habit. Sessions pin clients to instances and complicate scaling. The 2026-07-28 spec moved away from them for a reason.

Security and performance notes

Rate limiting is partitioned by authenticated caller, so one runaway agent loop gets HTTP 429 without starving everyone else. The limiter is per instance, so keep a gateway limit as well. Text inputs are capped at 2,000 characters, which bounds the cost of anything you forward downstream. On the client, FunctionInvokingChatClient caps tool iterations per request, and IncludeDetailedErrors = false keeps exception text away from the model. Stateless mode means every request carries its own protocol version and identity, so any instance can serve any call. Scaling out is just adding replicas.

Conclusion

MCP makes it easy to give an LLM tools. The 2.x SDK makes it easy to serve them over stateless HTTP. Making that safe is still your job, and it's mostly the ASP.NET Core you already know: authentication, [Authorize], filters, rate limiting and host filtering. MCP adds two habits on top. Hide tools from callers who can't use them, and get a human's yes before destructive actions. Get those right and an MCP server is just another well-run API.

Want to run it yourself? The complete .NET 10 solution from this post (the MCP server, the agent with human approval, and all 52 tests) is in Tech Skill Builder, along with a step-by-step PDF guide. It runs offline, no API key needed. Members get a new tested .NET + AI project every day: https://elitesolutions1.gumroad.com/l/TechSkillBuilder

How are you locking down MCP tools in your own setup? I'd like to hear what's working for you in the comments.

Resize Images in asp.Net

MICHAEL-MAURICE — Fri, 11 Mar 2022 21:57:52 +0000

I was doing a task today, and part of it was that I was uploading images..but there was a problem that would happen if the user uploaded a large image. I want to control the size of the image that I came from the user because my database is arrogant. this ..
The first thing I need to do is check the size of the image before I do it and save it. This is how I compare the length of the image (array of bytes) with the length I need, even if it is larger than it. Do not allow the user to upload this image.
The second thing is that I resize the image that I came to before I save it, and I found two packages that do this
1- SixLabors.ImageSharp, and you can read more about it here: https://www.nuget.org/packages/SixLabors.ImageSharp/2.0.0?_src=template
2- System.Drawing.Common, and you can read more about it here:-
https://www.nuget.org/packages/System.Drawing.Common/6.0.0?_src=template
And they are both, through which you can specify the width and height of your image, and this is how you can let the user upload any image, regardless of its size....

movie Tickets Reservation system

MICHAEL-MAURICE — Thu, 10 Mar 2022 22:55:25 +0000

database diagram:- https://lnkd.in/gM2PiTRt
GitHub repo:- https://lnkd.in/gCZEUg46
Full Video:- https://lnkd.in/gbbB-8pD
in this project, you can buy tickets for any movie
we use asp.net core MVC , SQL server
and also we used injection patterns ,solid principles
this project has a lot of functionalities For Example:
user
1-authentication
2-searching for any (movie, category, actor)
3-showing actors and producers for this movie
4-watch trailer
5- buy ticket buy using stripe payment method
6-add any movie to your cart
and more...
admin
you can (create ,read ,update, delete ,search) for
1-category
2-movie
3-cinema
4-Actor
and more ...

.NET Core vs .NET Framework

MICHAEL-MAURICE — Thu, 03 Mar 2022 11:46:47 +0000

What is .NET Core?

.NET Core is the latest version of Microsoft’s .NET Framewok, which is a free, open-source, general-purpose programming platform. It’s a cross-platform framework .The.NET Core Framework may be used to create a variety of apps, including mobile, desktop, online, cloud, IoT, machine learning, microservices, games, and more. .NET Core is written from scratch to make it a modular, lightweight, fast, and cross-platform Framework.

What is .NET Framework?

Microsoft’s Net Framework is a software development platform for building and running Windows applications.Net framework includes developer tools, programming languages, and libraries that are used to develop desktop and web applications. It is also used to build websites, web services, and games.

The key difference between .NET Core and .NET Framework is a platform for .NET applications on Windows whereas, NET Core is the latest version of the .NET Framework which is a cross-platform and open-source framework optimized for modern app needs and developer workflows.

Cumulative Sum

MICHAEL-MAURICE — Thu, 10 Feb 2022 19:25:43 +0000

in this article, I will talk about Cumulative sum but first, let me talk about one of the most common problem in computer science if we have an array and we wanna calculate the summation
of a specific range in this array, you will think of nested loops that sound good.
but this solution is (o(n)^2) can we get a better solution ??
Yes, we can do that by using (cumulative sum). ok, what is that exactly?

The cumulative sum is a technic we use to get the summation of a specific range in an array in(o(1)).
by generating a new array each element in that array contain the summation of elements before that

element.

ok, How we can write this code?

ZERO BASED

int range(int s,int e,vector<int>&v){
if(s==0)
    return v[e];
    return v[e]-v[s-1];
}
int main()
{

    vector<int>v={1,2,3,4,5,6};
    vector<int>s(v.size(),0);
    for(int i=0;i<v.size();i++){
        s[i]+=(i==0)?v[i]:v[i]+s[i-1];
    }
    cout<<range(2,4,s);
    return 0;
}

ONE BASED

int range(int s,int e,vector<int>&v){
    return v[e]-v[s-1];
}
int main()
{//one based
    vector<int>v={0,1,2,3,4,5,6};
    vector<int>s(v.size(),0);
    for(int i=1;i<v.size();i++){
        s[i]+=v[i]+s[i-1];
    }
    cout<<range(2,4,s);
    return 0;
}