Dnn.platform: 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!