Get client feedback on your ASP.NET Core application

Q: What does dotnet publish do?

Microsoft documents dotnet publish as compiling the app and copying the files required to run it into a publish folder. Deploy that output before client review.

Q: What is the difference between framework-dependent and self-contained?

A self-contained publish includes the .NET runtime in the output. A framework-dependent publish relies on a compatible .NET runtime installed on the server and is the default model documented by Microsoft.

Q: Does every deployment need a reverse proxy?

No. Microsoft supports hosting with or without a reverse proxy, although IIS or Nginx can receive Internet requests and forward them to Kestrel. Review through the configuration intended for release.

Q: Which environment should reviewers use?

Use a safely configured Staging or Production-style deployment. ASP.NET Core provides Development, Staging and Production environment names, and Production is intended to maximize security, performance and reliability.

Q: Should the Developer Exception Page be visible?

No outside Development. Microsoft warns that detailed exception information should not be shared publicly in production. Review the application's friendly production error handling instead.

Q: Can reviewers test authenticated endpoints?

Use the Feedback Widget inside the deployed application for authenticated endpoints. Reviewers still need a permitted account and the required authorization; BugSmash bypasses neither control.

Q: Can I review static assets as well as dynamic pages?

Yes. ASP.NET Core serves static files from its configured web root, typically wwwroot, and can protect static files through authorization-aware configuration. Review the browser behavior actually deployed.

Paste a browser-accessible ASP.NET Core deployment, send one review link, and collect comments on the pages and application states people will actually use. Every note keeps its route, browser, device and screenshot context.

See how it works

Loved by1,250+Agenciesand companies in 100+ countries

ASP.NET Core publishes and hosts the application; review belongs on the deployed browser experience.

dotnet publish creates the files required to run an ASP.NET Core app. Deployments can be framework-dependent or self-contained, and a hosted app may use a process manager and a reverse proxy. Runtime behavior also varies across Development, Staging and Production.

Four boundaries keep review representative and safe:

dotnet run is not the published release.
Use dotnet publish and deploy its output to the intended host. The publish folder contains assemblies, dependencies and, depending on the model, the .NET runtime.
Hosting configuration affects what users receive.
ASP.NET Core deployments may require a process manager and can sit behind a reverse proxy such as IIS or Nginx. Review through the same public entry point planned for release.
Development diagnostics must stay private.
Microsoft warns not to enable or publicly share the Developer Exception Page outside Development because it can expose detailed request and exception information.
Authentication and authorization remain in charge.
Pasting a URL does not bypass an authentication scheme, authorization policy, or hosting access. Supply permitted test access for protected endpoints.

BugSmash adds the review layer around the published application:

review browser-visible routes and assets, keep feedback attached to the rendered interface, and preserve decisions separately from ASP.NET Core and its host.

How it works

Three steps to a reviewed ASP.NET Core application

Publish and host the release

Run dotnet publish, deploy the framework-dependent or self-contained output, and configure the required process manager, proxy and environment.

Send one review link

Paste the accessible application URL into BugSmash and share the generated link. Reviewers comment on the rendered interface without source or server access.

Resolve feedback route by route

Each comment keeps the page URL, selected element, screenshot, browser and device so the team can reproduce the state.

Review the published ASP.NET Core application in the browser

Comment on rendered endpoints

Attach feedback to the browser-visible output instead of translating it into server-code language.

Review responsive layouts

Check desktop, tablet and mobile views and retain the viewport with every report.

Capture browser context

The page URL, browser, device and screenshot arrive with each comment.

Use the Widget for authenticated states

Install the Feedback Widget in the application so permitted reviewers can comment on protected roles, forms and workflows from inside their browser session.

Review static and dynamic output

Check user-facing routes together with public web-root assets and production error handling.

Keep release sign-off

Preserve decisions independently of later .NET, view, asset, environment or hosting changes.

Will it work on my ASP.NET Core application?

BugSmash reviews a browser-accessible ASP.NET Core frontend. The published output, runtime environment, middleware and hosting access determine what reviewers can open.

Your URL	Review by URL	What to do
Public ASP.NET Core production deployment	Works	Paste the deployed URL and review the browser-visible application.
Accessible ASP.NET Core staging deployment	Works	Use the staging URL after confirming its environment and configuration represent the release.
Framework-dependent or self-contained deployment	Works	Review the hosted URL after the selected publish model is running correctly.
Preview protected by supported Basic Auth	Works	Provide the permitted Basic Auth credentials through the supported review flow.
localhost from dotnet run or a launch profile	Not directly	Deploy the published app or expose the local server through a secure HTTPS tunnel.
Endpoints behind login, roles or SSO	Use the Widget	Install the Feedback Widget in the application so reviewers can comment while remaining inside the authenticated browser session.

Using the BugSmash Feedback Widget in an ASP.NET Core application

Add the BugSmash script to the browser-facing ASP.NET Core UI when reviewers must remain inside authenticated or stateful flows. Install it in the rendered layout or client application used by the routes under review.