GoncaloOliveira-3558 avatar image
0 Votes"
GoncaloOliveira-3558 asked ajkuma-MSFT answered

Unable to load System.ServiceModel.Primitives on Azure Web App slot

I'm having issues with one of the slots of an Web App (Linux). The slot is configured to build and deploy from a git repository. The project itself is an ASPNET with .NET 5. This project references a library (also .NET 5) that communicates with a WCF service, and therefore, it references the following packages

<PackageReference Include="System.ServiceModel.Duplex" Version="4.8.1" />
<PackageReference Include="System.ServiceModel.Http" Version="4.8.1" />
<PackageReference Include="System.ServiceModel.NetTcp" Version="4.8.1" />
<PackageReference Include="System.ServiceModel.Primitives" Version="4.8.1" />
<PackageReference Include="System.ServiceModel.Security" Version="4.8.1" />

All of the sudden, I am getting errors after deploying the application, when requesting an endpoint

Could not load file or assembly 'System.ServiceModel.Primitives, Version=, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. The system cannot find the file specified.

After inspection with SSH, the file is there, along with the others.

The thing is... if I create a new slot, pointing to the same repo, same branch... it builds, deploys and it works... but this slot, for some reason, is stuck and there's something wrong with it!

I could, of course, delete this slot and create a new one, but there are settings, custom domains and certificates... so I'd rather not have to redo all of that!

Any suggestions?

5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

1 Answer

ajkuma-MSFT avatar image
0 Votes"
ajkuma-MSFT answered


Thanks for reporting and sharing a detailed description of this issue. I understand you have isolated the issue and a new slot works as expected.

Just to highlight, some configuration elements follow the content across a swap (not slot specific), whereas other configuration elements stay in the same slot after a swap (slot specific). -Example - Always On settings is Slot specific.

--App settings (can be configured to stick to a slot) - make it not sticky/clone and check.

With Deployment slots on App Service, they are live apps with their own hostnames. You have different versions of your web app to different URLs. You can test a certain version and then swap content and configuration between slots.
-- Based on your scenario - You may review the matching configuration/clone the settings as well/restart the WebApp and test.

Kindly see the doc section ‘Settings that aren't swapped’.

Note: With clone configuration from any existing slot. Settings that can be cloned include app settings, connection strings, language framework versions, web sockets, HTTP version, and platform bitness.

Kindly let us know how it goes, I’ll follow-up with you further and would need some more details about your WebApp and subscription (for which I’ll reach out you privately).

· 2
5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.


Thank you for your reply, but the problem is not related with configuration. The new slot that I created, I cloned the settings from the "problematic" one. I am also aware that there are slot settings and "swappable" settings. All settings in the slots are slot settings.

I've managed to sort out the issue, by entering the instance with SSH and deleting a series of files from the home directory. Then, disconnected the source control, connected again which triggered a new build and deployment. This seems to have solved the issue.

I think the problem was somewhere in the container environment, something was being cached for some reason. Don't know what exactly. I can say that this was probably caused by a migration from .net core 3 to .net 5, that left some remains in it. Restarting the app wouldn't solve this either.

So it's resolved now... although I am not happy with the solution.

0 Votes 0 ·
ajkuma-MSFT avatar image ajkuma-MSFT GoncaloOliveira-3558 ·

@GoncaloOliveira-3558, Thanks for the follow-up and sharing an update.

Glad to know that the issue is sorted out. Apologies for any frustrating experiencing with this.

To investigate the cause further, I'm reaching out to privately to seek subscription and WebApps info.
To benefit the community I'll post back the outcome once identified from our discussions.

Thanks again, appreciate your co-operation on this!

0 Votes 0 ·