 |
VOOZH | about |
|
VOOZH | about |
dotnet add package Pixata.AspNetCore --version 1.6.0
NuGet\Install-Package Pixata.AspNetCore -Version 1.6.0
<PackageReference Include="Pixata.AspNetCore" Version="1.6.0" />
<PackageVersion Include="Pixata.AspNetCore" Version="1.6.0" />Directory.Packages.props
<PackageReference Include="Pixata.AspNetCore" />Project file
paket add Pixata.AspNetCore --version 1.6.0
#r "nuget: Pixata.AspNetCore, 1.6.0"
#:package Pixata.AspNetCore@1.6.0
#addin nuget:?package=Pixata.AspNetCore&version=1.6.0Install as a Cake Addin
#tool nuget:?package=Pixata.AspNetCore&version=1.6.0Install as a Cake Tool
As the validation extension in this package is only designed to be used in server-side projects, you should reference this package in a server-side project. If you have a WASM project, adding a reference to this package will cause errors.
The code in this package requires certain dependencies to be registered in the DI container. In order to make this easier, there is an extension method to add them all. In Program.cs add this line...
builder.Services.AddPixataAspNetCore<ContactModel>();
...where ContactModel is any type in your project. If you are using the validation filter (see below), then it is used here to point the framework to the assembly containing your models.
If you want to use the route dump feature (see below) then you'll also need to the following...
app.MapPixataAspNetCoreApiEndpoints();
When investigating bug reports from customers, I often find that the issue is nothing to do with my code, it's that they have changed something in the database, and I need to find out what they changed, and when.
Adding auditing manually can be done, but means you end up writing the same intrusive code in every app. To combat this, I have added some auditing functionality to this repo. This consist of two parts...
DbContextSee the for more information.
When writing API endpoints, it can be hard to keep track of all the routes you have defined, and what they are. To help with this, I have added a feature that will dump all the routes in your app to the console when the app starts.
All you need to do is call MapPixataAspNetCoreApiEndpoints() as shown above, and then navigate to /dump-routes.
By default, it ignores routes that start with any of "/_blazor", "/_framework" or "/_content", as these are not usually of interest. You can override this by passing an array of routes to ignore...
app.MapPixataAspNetCoreApiEndpoints(["/_blazor", "/_framework", "/_content", "/hello"]);
Note that you need to include the default ones if you want to ignore them. If you pass in an empty array, then all routes will be dumped.
Also note that any routes that start with any of the specified routes will be ignored. So if you specify "/hello", then "/hello-world" will also be ignored.
I often find myuself generating documents, either for conversion to PDF, or for emailing. This has always been a painful process, so I decided that a helper was needed. This class contains two methods, one for generating HTML from a Blazor component, and another for generating a PDF from a Blazor component.
If you didn't register the services as explained above, then you need to register a Microsoft dependency and the Pixata template helper in Program.cs...
builder.Services.AddScoped<HtmlRenderer>();
builder.Services.AddScoped<DocumentTemplateHelper>();
If you haven't already got it, then you will also need to add the following line...
builder.Services.AddHttpContextAccessor();
Note that you need this even if you use the AddPixataAspNetCore method.
Then, you create a Blazor component that will be the template for the document you wish to generate. It needs to accept two parameters as follows...
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8" />
<title></title>
</head>
<body>
<div>
<h2><img src="@BaseUrl/images/logo.png" width="70" height="70" /> Thank you for contacting us</h2>
<div>Your message has been received, and we'll get back to you as soon as possible.</div>
<div>
<h3>Your message</h3>
<HtmlRaw Html="@(Model.Message.Replace("\n", "<br/>"))" />
</div>
<h3>The Fab Ferret Emporium team</h3>
</div>
</body>
</html>
@code {
[Parameter]
public string BaseUrl { get; set; } = "";
[Parameter]
public ContactModel Model { get; set; } = null!;
}
The BaseUrl parameter is populated by the template helper, and allows you to pull in images from your web site, as you can see above. The Model parameter is the model that you want to use to populate the template, and can be any class.
With that in place, you can inject a DocumentTemplateHelper into your code, and use it as follows...
// Generate HTML for use as an email body...
ContactModel model = new ContactModel { Name = "Billy Shears", Email = "billy@shears.co.uk" };
string html = await documentTemplateHelper
.CreateHtmlFromTemplate<EmailFromContactPageTemplate>((nameof(EmailFromContactPageTemplate.Model), model));
// Generate PDF for attaching to an email...
InvoiceModel model = new InvoiceModel { /* set properties */ };
byte[] bytes = await documentTemplateHelper
.CreatePdfFromTemplate<InvoiceTemplate>((nameof(InvoiceTemplate.Model), model));
When writing API endpoints, it can be hard to debug 400 errors, which are often caused by incorrect or mismatched paths, or invalid data in the request. You often don't get much clue as to what actually happened.
To help with this, I have added a piece of middleware that will log every incoming request to the app (subject to configuration choices, see below). This will log the path, the query string, and the body of the request. This can be very helpful for debugging, as it allows you to see exactly what was sent to the server.
You need to register the middleware in your Program.cs file, as follows...
builder.Services.AddRequestLogging();
This will use the default configuration, which is to include the request body in the logging, and ignore any requests whose path starts with any of...
You can override either of these options as follows...
builder.Services.AddRequestLogging(o => {
o.IgnoredPaths = ["_framework", "health"]; // Or whatever you want to ignore
o.LogBody = false;
});
To log all requests, set o.IgnoredPaths to an empty array [].
You then need to register the middleware...
app.UseRequestLogging();
This should be after any authentication/authorisation middleware, but before any endpoint mapping.
When using fluent validation in Blazor server-side, the chances of anyone bypassing your validation are small enough that they can be ignored for most cases. However, when running in client-side (WASM), validation is handled in the WASM, and the data is then sent to the server via API endpoints. This means that anyone can modify the request, or write a script to mimic it, and bypass your validation.
The obvious (and correct) solution to this is to validate your incoming models on the server before doing anything with the data. Generally, this is a bit of a pain, as it involves duplicating validation code.
To avoid this, you can add the ValidationEndpointFilter to your API endpoints. This will run the same validation as in the client, but on the server, so if anyone tries to bypass the client-side validation, they will be stopped by the server-side validation. This allows you to protect your endpoints without adding much extra code.
As explained above, the validation extension requires services to be registered in the DI container. To make this easier, you can use the AddPixataAspNetCore extension method in your Program.cs file:
builder.Services.AddPixataAspNetCore<ContactModel>();
...where ContactModel is any model, it is used here to point the framework to the assembly containing your models.
Basic usage is very simple. Once you've registered the dependencies (see above), you just add the AddEndpointFilter extension method to any API endpoints that need validation.
You change...
app.MapPost("/contact-api", async (GeneralServiceInterface service, ContactModel model) =>
await service.Contact(model));
...to...
app.MapPost("/contact-api", async (GeneralServiceInterface service, ContactModel model) =>
await service.Contact(model))
.AddValidationEndpointFilter();
When the endpoint is hit, the appropriate validator will be found and applied to the incoming model.
If there were any validation errors, then the filter will return an ApiResponse with a State of ApiResponseStates.Failure and a Message containing a formatted string of the validation errors. By default, the errors are formatted as a comma-delimited string of the form $"{e.PropertyName}: {e.ErrorMessage}", which would produce something like... "Validation errors - Name: Required, Email: Invalid". This can be overriden as explained below.
The filter has two optional parameters.
You can pass in a Func<ValidationFailure, string> to format the validation errors. For example, if you wanted to include the error code in the message, you could do something like this...
app.MapPost(RoutesHelper.ApiContact, async (GeneralServiceInterface service, ContactModel model) =>
await service.Contact(model))
.AddEndpointFilter(new ValidationEndpointFilter(err => $"({err.ErrorCode}) {err.ErrorMessage} for {err.PropertyName}"));
This would produce a message of the form "Validation errors - (NotEmptyValidator) Required for Name, (EmailValidator) Invalid for Email".
By default, the filter will pick up any a validator for any class in the assembly you specified when registering (with the AddValidatorsFromAssemblyContaining method, see above). You may wish to restrict this further, and specify that only classes within a certain namepsace should be validated. You can do this as follows...
app.MapPost("/contact-api", async (GeneralServiceInterface service, ContactModel model) =>
await service.Contact(model)).AddEndpointFilter(new ValidationEndpointFilter(nameSpace: typeof(ContactModel).Namespace);
This is not a common scenario, but is included for those odd cases.
This package includes a comprehensive entity auditing system that automatically captures all entity changes via an EF Core SaveChangesInterceptor. It stores full snapshots and property-level diffs for every create, update, and delete operation.
1. Register auditing services in Program.cs:
builder.Services.AddAuditing<MyDbContext>();
2. Add the interceptor to your DbContext registration:
builder.Services.AddDbContext<MyDbContext>((serviceProvider, options) =>
options.UseSqlServer(connectionString)
.AddAuditingInterceptor(serviceProvider));
3. Add the Audit DbSet to your DbContext:
using Pixata.AspNetCore.Auditing.Models;
public class MyDbContext : DbContext {
public DbSet<Audit> Audits { get; set; }
// ... other DbSets
}
4. Create and run an EF Core migration:
dotnet ef migrations add AddAuditing
dotnet ef database update
Each audit entry stores:
{ "PropertyName": [oldValue, newValue] }Entities can opt out of auditing by applying the [NoAudit] attribute:
using Pixata.AspNetCore.Auditing.Attributes;
[NoAudit]
public class SensitiveEntity {
// This entity will not be audited
}
By default, the auditing system identifies users via HttpContext.User.Identity.Name, falling back to "System" if no user is available. You can override this by injecting AuditUserContextInterface and setting the UserIdentifier property:
public class SprocketController(AuditUserContextInterface auditContext) : ControllerBase {
[AllowAnonymous]
public async Task<IActionResult> NotifyFromSprocket() {
auditContext.UserIdentifier = "SprocketNotificationEndpoint";
// Any changes saved in this request will use this identifier
}
}
The Pixata.Blazor package includes an AuditViewer component that provides a UI for browsing audit history. To use it, add this to a Blazor page:
@page "/audit-viewer"
<AuditViewer TContext="MyDbContext" />
The viewer provides:
DbSet<T> properties via reflection)By default, audit entries are retained forever. You can configure automatic cleanup by specifying a retention period:
builder.Services.AddAuditing<MyDbContext>(options => {
options.RetentionPeriod = TimeSpan.FromDays(90); // Delete entries older than 90 days
options.CleanupInterval = TimeSpan.FromHours(6); // Check every 6 hours (default: daily)
});
When a retention period is set, a background service runs periodically and deletes audit entries older than the configured period.
| Product | Versions Compatible and additional computed target framework versions. |
|---|---|
| .NET | net8.0 net8.0 is compatible. net8.0-android net8.0-android was computed. net8.0-browser net8.0-browser was computed. net8.0-ios net8.0-ios was computed. net8.0-maccatalyst net8.0-maccatalyst was computed. net8.0-macos net8.0-macos was computed. net8.0-tvos net8.0-tvos was computed. net8.0-windows net8.0-windows was computed. net9.0 net9.0 was computed. net9.0-android net9.0-android was computed. net9.0-browser net9.0-browser was computed. net9.0-ios net9.0-ios was computed. net9.0-maccatalyst net9.0-maccatalyst was computed. net9.0-macos net9.0-macos was computed. net9.0-tvos net9.0-tvos was computed. net9.0-windows net9.0-windows was computed. net10.0 net10.0 was computed. net10.0-android net10.0-android was computed. net10.0-browser net10.0-browser was computed. net10.0-ios net10.0-ios was computed. net10.0-maccatalyst net10.0-maccatalyst was computed. net10.0-macos net10.0-macos was computed. net10.0-tvos net10.0-tvos was computed. net10.0-windows net10.0-windows was computed. |
This package is not used by any NuGet packages.
This package is not used by any popular GitHub repositories.
| Version | Downloads | Last Updated |
|---|---|---|
| 1.6.0 | 92 | 6/9/2026 |
| 1.5.2 | 101 | 6/1/2026 |
| 1.5.1 | 105 | 5/31/2026 |
| 1.5.0 | 115 | 5/28/2026 |
| 1.4.0 | 124 | 5/27/2026 |
| 1.3.2 | 119 | 4/21/2026 |
| 1.3.1 | 105 | 4/21/2026 |
| 1.3.0 | 104 | 4/21/2026 |
| 1.2.0 | 145 | 3/8/2026 |
| 1.1.0 | 111 | 3/5/2026 |
| 1.0.3 | 111 | 2/23/2026 |
| 1.0.2 | 108 | 2/23/2026 |
| 1.0.1 | 106 | 2/23/2026 |
| 1.0.0 | 116 | 2/19/2026 |