Different identity behavior from local development to IIS

App is netcore9, using SS 8.7.1

I have an application that uses the autopopulate attributes to assign auditBase values. Code works great running it locally from Rider. However the same exact code published to IIS using the same exact database gives the following error:

Cannot insert the value NULL into column 'CreatedBy', table 'PickTicketAuditTool.dbo.PickTicketAuditLog'; column does not allow nulls. INSERT fails. The statement has been terminated.

Now if I use dotnet .{MYCUSTOMERAPP}.dll from the same exact folder that IIS is hosting the application, it works exactly like my local environment and works as expected. Any clues to what is going on?

This has now become a major issue, as I can’t deliver an app to a customer because something that just worked in the past now doesn’t work.

I have tried lots of things without success:

  • Downgraded to SS 8.4
  • Publish win-x64 only
  • Publish portable
  • downgraded my application to dotnet8 which included installed the dotnet 8 hosting bundle (this took considerable time because I had to copy all the code to another solution because there are large differences between the dotnet 8 and 9 templates)
    *tried it over ssl and regular ole http

Server is 2019 so not that old.

So I downloaded the Blazor Server template and only selected SQL Server for the options, made no changes to it, created a db for it, ran the migration then deployed the application to IIS and I am unable to create new bookings using the provided UI. This was over SSL as well.

Windows Server 2019, IIS 10, App Pool using ApplicationIdentity,

Not sure why it matters, @mythz but only after installing Web Sockets on IIS did the Auth work properly again.

The missing auth sounds like the previous issue with the In Process gateway which was resolved in v8.7.1:

Please confirm that you’re using the v8.7.1 pre-release packages in the new Blazor template? The version is available from app.serviceStackVersion in the App’s /metadata/app.json.

I’ll look at releasing v8.7.2 with the fix early next week, but I want to confirm that this issue has been resolved in v8.7.1.

Please note we only build for and test with LTS versions, e.g. .NET 8. We’ll have a new .NET 10 builds when it’s released later this year.

I verified that 8.7.1 dll’s were copied to the publish folder.

Please confirm the version returned in /metadata/app.json