Azure DLL files seem to be missing in 9.2.2 upgrade

[sawest]

Description of bug

When upgrading from DNN 8.0.4 to DNN 9.2.2 the upgrade hangs at 64%. Windows even logs show that the Microsoft.Azure.Storage assembly registration in the web.config is different the actual dll in root/bin (see error log). I have checked the site prior to upgrade and no Azure items are in the web.config file. Curing the upgrade new Azure 8.3.0 items are added to the web.config file, but no matching dll is placed in the bin folder. My 8.0.4 site has a 2.3.0 version of Azure dll in it so when the new Azure item is placed in web.config for version 8.3.0 it seems to crash and hang the upgrade.

Steps to reproduce

List the steps to reproduce the behavior:

1. Start with a site prior to DNN 9.2.2 with an earlier version of Microsoft.Azure.Storage.dll than 8.3.0
2. Use normal steps to upgrade to DNN 9.2.2
3. System hangs at 64% (installing CKEditorProvider)
4. Nothing in DNN logs but Windows Event Log shows error below.

Current result

Upgrade hangs and will not complete

Expected result

Upgrade to complete successfully

Screenshots

Error log

Exception information: Exception type: ConfigurationErrorsException Exception message: Could not load file or assembly 'Microsoft.WindowsAzure.Storage, Version=8.3.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040) at System.Web.Configuration.CompilationSection.LoadAssemblyHelper(String assemblyName, Boolean starDirective) at System.Web.Configuration.CompilationSection.LoadAllAssembliesFromAppDomainBinDirectory() at System.Web.Configuration.CompilationSection.LoadAssembly(AssemblyInfo ai) at System.Web.Compilation.BuildManager.GetReferencedAssemblies(CompilationSection compConfig) at System.Web.Compilation.BuildManager.GetPreStartInitMethodsFromReferencedAssemblies() at System.Web.Compilation.BuildManager.CallPreStartInitMethods(String preStartInitListPath, Boolean& isRefAssemblyLoaded) at System.Web.Compilation.BuildManager.ExecutePreAppStart() at System.Web.Hosting.HostingEnvironment.Initialize(ApplicationManager appManager, IApplicationHost appHost, IConfigMapPathFactory configMapPathFactory, HostingEnvironmentParameters hostingParameters, PolicyLevel policyLevel, Exception appDomainCreationException)

Could not load file or assembly 'Microsoft.WindowsAzure.Storage, Version=8.3.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040) at System.Reflection.RuntimeAssembly._nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, RuntimeAssembly locationHint, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks) at System.Reflection.RuntimeAssembly.nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, RuntimeAssembly locationHint, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks) at System.Reflection.RuntimeAssembly.InternalLoadAssemblyName(AssemblyName assemblyRef, Evidence assemblySecurity, RuntimeAssembly reqAssembly, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks) at System.Reflection.RuntimeAssembly.InternalLoad(String assemblyString, Evidence assemblySecurity, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean forIntrospection) at System.Reflection.RuntimeAssembly.InternalLoad(String assemblyString, Evidence assemblySecurity, StackCrawlMark& stackMark, Boolean forIntrospection) at System.Reflection.Assembly.Load(String assemblyString) at System.Web.Configuration.CompilationSection.LoadAssemblyHelper(String assemblyName, Boolean starDirective)

Could not load file or assembly 'Microsoft.WindowsAzure.Storage' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

Additional context

None

Affected version

[x] 9.2.2

Affected browser

Any

[sawest]

Upon further investigation I found the DNNCE_FolderProviders_09.02.02_install.zip module that is included in the the 9.2.2 upgrade install. This module is what adds the web.config assembly items. However, the included Microsoft.WindowsAzure.Storage.dll file is not copying over the existing .dll during the upgrade. This creates a mismatch assembly problem.

I will try to remove the dll from my site prior to upgrade and see what happens.

[sawest]

Removing the existing Microsoft.WindowsAzure.Storage.dll file allowed the upgrade to complete successfully. The new dll is placed in bin/Providers. If an existing dll is in the bin folder, upgrade will hang.

[aaronsglz]

I found the same issue during an update. In my opinion, I think that during the installation both assemblies (Microsoft.WindowsAzure.Storage.dll, DotNetNuke.Providers.FolderProviders.dll) are being copied into the bin/providers folder instead of the bin folder. I have edited the path of the assemblies in the manifest of the DNNCE_FolderProviders module and the installation has finished without errors.

<component type="Assembly">
    <assemblies>
        <assembly>
            <path>bin</path>
            <name>DotNetNuke.Providers.FolderProviders.dll</name>
        </assembly>
        <assembly>
            <path>bin</path>
            <name>Microsoft.WindowsAzure.Storage.dll</name>
            <version>8.3.0</version>
        </assembly>
    </assemblies>
</component>

I have also moved the installation package assemblies to the bin folder.

[ohine]

We could add a cleanup file into v9.3.0 which deletes Microsoft.WindowsAzure.Storage.dll assembly from the bin directory before the updated version gets copied it into the bin\Providers folder.

Thoughts @dnnsoftware/tag?

[valadas]

As discussed in the approvers meeting, the fix here would be to move everything into the bin directory and get rid of the /Providers folder. But since this could be a breaking change, we are pushing this to Dnn 10

[stale[bot]]

We have detected this issue has not had any activity during the last 90 days. That could mean this issue is no longer relevant and/or nobody has found the necessary time to address the issue. We are trying to keep the list of open issues limited to those issues that are relevant to the majority and to close the ones that have become 'stale' (inactive). If no further activity is detected within the next 14 days, the issue will be closed automatically. If new comments are are posted and/or a solution (pull request) is submitted for review that references this issue, the issue will not be closed. Closed issues can be reopened at any time in the future. Please remember those participating in this open source project are volunteers trying to help others and creating a better DNN Platform for all. Thank you for your continued involvement and contributions!

[SwanGit]

We have been using the Microsoft.WindowsAzure.Storage.dll version 9.3.2 as a newer and also a tested version for several of our custom modules.

During upgrade from DNN 09.09.00 to DNN 09.13.01 for our sites, the upgrade process chrashes seemingly due to the DNN upgrade process "automagically" downgrade the bindingRedirect reference in web.config for the Microsoft.WindowsAzure.Storage from: newVersion="9.3.2.0" to: newVersion="8.3.0.0"

The chrash is as expected: ConfigurationErrorsException: Could not load file or assembly 'Microsoft.WindowsAzure.Storage, version 8.3.0.0

The resolution is to:

• restore DB and website backup for the site back to DNN 9.9.0
• manually copy the old Microsoft.WindowsAzure.Storage version 8.3.0.0 from the DNN 09.13.1 upgrade pack to the bin folder
• manually updating the binding redirect for Microsoft.WindowsAzure.Storage to be version 8.3.0.0 in web config

Then run a regular DNN upgrade to DNN 09.13.01

The Microsoft.WindowsAzure.Storage.dll version 9.3.2 is however a newer and is also the tested version for several of our custom modules, so it is the better choice for us to restore back to Microsoft.WindowsAzure.Storage.dll version 9.3.2 after DNN upgrade

Should the version 9.3.2 of the Microsoft.WindowsAzure.Storage.dll then be saved in 2 locations of the website, in both folders: \bin \bin\Providers ?

[jeremy-farrance]

I've run in to this multiple times over the years on various modules. I believe there is a better approach to fixing this. In the near term,

1 - Binding Redirect(s) to Support different versions of the same DLL

instead of restoring and redoing, do the upgrade, make careful notes of the DLLs, versions, and paths - then add 1 or 2 binding redirects so that each "thing" can find the DLL+version it is looking for. There are a lot of details covered in this article, Assembly Reference Errors and Binding Redirect Notes. See the section, "Understand BindingRedirect," and note how its handling multiple versions of the same DLL.

In your case it looks like you'll need one complex one - or two binding redirects, one for each needed version including a non-standard path to your version. Not sure.

2 - Enhanced Modules

The long term solution is to enhance your module so it either uses the version DNN has onboard, or enhance your module so it uses the techniques necessary to use a DLL version that does not match DNN's. I believe modules like 2sxc, ActionForm, and others do this (though they learned the hard way).

Also note, I think it is likely there are other solutions here. Hopefully smarter people will chime in. I was mostly responding to your "restore..." thing and trying to point you at options that less time consuming with a small (manageable?) amount of learning.