Hi Brian

This is the error I think. I'm not sure how relevant it is. 

Here's the expanded view of the error. I'm sorry, I have now idea what's going on. 

Okay, well, to resolve that error we need to introduce a binding redirect. I thought 2Sxc automatically added these, so maybe the first step is to see if there's a newer version of 2Sxc to upgrade to (preferably one of their LTS releases).

If you still continue to see that error, that's where the binding redirects come into play. If you look at your <code>web.config</code> file (either via the file system or through the Config Manager in the Persona Bar) and search for <code>bindingRedirect</code> you will see a section of the file with entries like this:

<code>      <dependentAssembly xmlns="urn:schemas-microsoft-com:asm.v1">
        <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" />
        <bindingRedirect oldVersion="0.0.0.0-32767.32767.32767.32767" newVersion="12.0.0.0" />
      </dependentAssembly></code>

What this is saying is that the assembly (DLL file, compiled code) with the given identity (name is <code>Newtonsoft.Json</code>, signed with the public key <code>30ad4fe6b2a6aeed</code>) is valid for use when any version is requested (i.e. in the range from version <code>0.0.0.0</code> to version <code>32767.32767.32767.32767</code>) and should use the version <code>12.0.0.0</code>. This <code>newVersion</code> value needs to match the version of the DLL file in the <code>bin</code> folder.

So, in your case, you need to see if there's an existing binding redirect for <code>Microsoft.Extensions.DependencyInjection.Abstractions</code>. If there is, make sure version 1.1.0.0 is included in the <code>oldVersion</code> range. If there isn't, you'll want to add one. The tricky part here is knowing the specific version of the assembly file in the <code>bin</code> to use for the <code>newVersion</code>. There are many different versions associated with the file, so it's not very straightforward to determine what the correct version is. If you use the wrong version, your site won't work at all. You should be able to retrieve the version using Powershell, with the following snippet (using your website's path): <code>&#91;System.Reflection.AssemblyName&#93;::GetAssemblyName('C:\inetpub\wwwroot\mysite.com\bin\Microsoft.Extensions.DependencyInjection.Abstractions.dll').Version.ToString()</code>.

After you've added/updated the binding redirect, you'll want to see if that resolved the issue. It may be that there's another missing binding redirect that you need to add next.

If you get into a scenario where your versions don't match and the site isn't working, I have a Powershell module which has a command to synchronize the binding redirects in the <code>web.config</code> with the files in the <code>bin</code> (though it won't add new binding redirects). To use that, run <code>Install-Module -Name BindingRedirects</code> (see the getting started docs if <code>Install-Module</code> isn't available on your system). Once it's installed, call <code>Sync-BindingRedirect 'C:\inetpub\wwwroot\mysite.com\web.config'</code> to update any incorrect binding redirects.

Hope it helps!

Hi Brian,

Sorry for late reply, and than you for helping us out fix the error. We were able to fix it.

But we still can't delete a portal. Is there a way to do it manually and clean? Thanks.

Ultimately the code you're trying to run is https://github.com/dnnsof...roller.cs#L154-L195. There's a lot going on in there, so any manual deletion is likely to miss a step or two.

This deletes any localized files (e.g. <code>*.Portal-2.resx</code>), the child portal folder(s) (e.g. <code>/my-portal</code> if the URL is <code>mysite.com/my-portal</code>), and the portal folders (e.g. <code>Portals/2</code> and <code>Portals/2-System</code>).

Then it deletes each user in the portal, which is its own long, involved process, ultimately calling the SQL stored procedure <code>EXEC DeleteUserPortal @userId @portalId;</code> for each user, and finally deletes the portal by running the SQL stored procedure <code>EXEC DeletePortalInfo @portalId;</code>

All that said, I would suggest continuing to try to find some details on what's causing the delete request to fail. If you're concerned that the site is still "live" while you're troubleshooting, you can use a temporary site alias URL and remove all of the previous URLs so that no one can find the site anymore.

I would start by looking at the network traffic in your browser tools, and see if the error response to the delete request includes any details. You can also look in the log file if there isn't anything logged to the Admin Logs. You can see the log file via the Servers section of the Persona Bar.