It looks like it does not like something with the blob provider.

Are you using any custom or the built in file blob provider?

Hi, do you have anything in <episerver.framework><blob> element inside either "web.config" or most probably inside "episerverframework.config" file?

Hi, 

We use the built-in blob-provider, and there is no <episerver.framework><blob> element present in neither of our *.config-files.

Here's our episerverframework.config content:

<episerver.framework>  
  <appData basePath="\\NCSV0173-SQL\shared\vpp_virksomhedsportalen_dev" />
  <scanAssembly forceBinFolderScan="true" />
  <virtualRoles addClaims="true">
    <providers>
      <add name="Administrators" type="EPiServer.Security.WindowsAdministratorsRole, EPiServer.Framework" />
      <add name="Everyone" type="EPiServer.Security.EveryoneRole, EPiServer.Framework" />
      <add name="Authenticated" type="EPiServer.Security.AuthenticatedRole, EPiServer.Framework" />
      <add name="Anonymous" type="EPiServer.Security.AnonymousRole, EPiServer.Framework" />
      <add name="CmsAdmins" type="EPiServer.Security.MappedRole, EPiServer.Framework" roles="WebAdmins, Administrators" mode="Any" />
      <add name="CmsEditors" type="EPiServer.Security.MappedRole, EPiServer.Framework" roles="WebEditors" mode="Any" />
      <add name="Creator" type="EPiServer.Security.CreatorRole, EPiServer" />
      <add name="PackagingAdmins" type="EPiServer.Security.MappedRole, EPiServer.Framework" roles="WebAdmins, Administrators" mode="Any" />
    </providers>
  </virtualRoles>
  <virtualPathProviders>
    <clear />
    <add name="ProtectedModules" virtualPath="~/EPiServer/" physicalPath="Modules\_Protected" type="EPiServer.Web.Hosting.VirtualPathNonUnifiedProvider, EPiServer.Framework" />
  </virtualPathProviders>
  <geolocation defaultProvider="maxmind">
    <providers>
      <add name="maxmind" type="EPiServer.Personalization.Providers.MaxMind.GeolocationProvider, EPiServer.ApplicationModules" databaseFileName="App_Data\GeoLiteCity.dat" />
    </providers>
  </geolocation>
</episerver.framework>

<p>About the versions once more, you are upgrading to 8.0 or 8.x? From exception there is 8.8.2 version? Is it related *only* to 8.0.0.0 version and other versions are working correctly?</p>

Hi Valdis, 

Yes, the error is taken from the EPi CMS 8.8.2 version, since I continued the upgrade steps to see if anything changed. You can replace version "8.8.2" with "8.0.0", to have an accurate picture of the problem. I admit that pasting the above version in the exception, is a bit confusing.

When debugging, I did the upgrade in small steps, and here I was able to conclude that the error appeared when upgrading from 7.19.2 (last 7.x version) to 8.0.0. Continuing the upgrade to version 8.8.2 does not affect the exception.

What happens if you enable logging for the EPiServer? Do you see any errors regarding Blob initialization? Sounds like default FileBlobProvider may fail without noticing initialization module.

What do you see if you dump IoC container?

ServiceLocator.Current.Container.WhatDoIHave();

Hi Valdis, 

When inspecting the log, I get:
http://pastebin.com/GJbrihkp

When emptying the IoC container with the code below, I get:
http://pastebin.com/RbQ0rhLa

As far as I see, the log does not tell much more than the error. I'm a little more unsure what to conclude on the container content dump.

<Code to provoke error and log the structuremap container content>

    public class Global : SiteBase // temp. changed from "EPiServer.Global" for debugging upgrade error
    {
        public Global() : base()
        {
            try
            {
                var letsProvokeError = new EPiServer.Global();
            }
            catch (Exception)
            {
                var container = GetPrivateField<IContainer>(ServiceLocator.Current, "container");
                Log.DebugFormat("UpgDbg:: Container content: {0}", container.WhatDoIHave());                
                throw;
            }
        }
        (. . .)
    }
}

Hi,

Did you try to upgrade with the app-data on local hard drive instead of on network share? I know there were some upgrading problems with app data on network shares in earlier versions of EPiServer. Moving the app data to local drive before upgrade and moving it back to network share after upgrade was the work around.

Just read there is no data migration required when going to 8.0 so I guess it's not a problem with app-data, but again, you'll never know. :)

Dear Mattias, 

Thank you for intput on the discussion. I tried changing the:

<appData basePath="\\NCSV0173-SQL\shared\vpp_virksomhedsportalen_dev" />

to:

<appData basePath="App_data" />

but it dit not change the error. In the App_data-folder, I tried to put 3 emtpy folders: "Documents","Global", "PageFiles", and I also tried copying in a blob-folder (with blob-content) from a working EPi 8 solution. Do you think it can fail like that if the content of the VPP-folder is not as expected?

<p>BlobFactory should be registered in FrameworkInitialization module - So I guess there are errors that make the registration fail, possible from the creation of FileBlobProvider instance or BlobFactory instance. What does this code give you?</p> <p>var fileBlobProvider = (FileBlobProvider)ProvidersHelper.InstantiateProvider(new ProviderSettings(Blob.DefaultProvider, typeof(FileBlobProvider).AssemblyQualifiedName), typeof(FileBlobProvider));</p> <p>providers.Add(fileBlobProvider);<br />var blobFactory = new BlobFactory(Blob.DefaultProvider, new BlobProvider[] { fileBlobProvider });</p> <p>Regards.</p> <p>/Q</p>

Dear Quan,

Seems like a good experiment. The code does however execute without errors, both before and after the structuremap exception is thrown.

I use the following snippet to test:

        public Global() : base()
        {
            try
            {
                var fileBlobProvider = (FileBlobProvider)ProvidersHelper.InstantiateProvider(new ProviderSettings(Blob.DefaultProvider, typeof(FileBlobProvider).AssemblyQualifiedName), typeof(FileBlobProvider));
                var blobFactory = new BlobFactory(Blob.DefaultProvider, new BlobProvider[] { fileBlobProvider });

                var letsProvokeError = new EPiServer.Global();
            }
            catch (Exception)
            {               

                var fileBlobProvider = (FileBlobProvider)ProvidersHelper.InstantiateProvider(new ProviderSettings(Blob.DefaultProvider, typeof(FileBlobProvider).AssemblyQualifiedName), typeof(FileBlobProvider)); 
                var blobFactory = new BlobFactory(Blob.DefaultProvider, new BlobProvider[] { fileBlobProvider });

                // here the error remains and both provider and factory are defined
                throw;
            }
        }

So I guess there is a problem that prevents FrameworkInitialization from running properly - if at all. 

Can you make sure this is present in your web.config/system.webServer/modules:

      <add name="InitializationModule" type="EPiServer.Framework.Initialization.InitializationModule, EPiServer.Framework" preCondition="managedHandler" />

Regards.

/Q

Dear Quan, 

The entry is already present. Here is the full node (web.config/system.webServer/modules):

<system.webServer>
    (. . .)
    <modules runAllManagedModulesForAllRequests="true">
      <add name="InitializationModule" type="EPiServer.Framework.Initialization.InitializationModule, EPiServer.Framework" preCondition="managedHandler" />
      <add name="UrlRewriteModule" type="EPiServer.Web.RoutingUrlRewriteModule, EPiServer" preCondition="managedHandler" />
      <add name="ShellRoutingModule" type="EPiServer.Shell.Web.Routing.ShellRoutingModule, EPiServer.Shell" />
      <remove name="WebDAVModule" />
      <remove name="FormsAuthentication" />
      <add name="WSFederationAuthenticationModule" type="System.IdentityModel.Services.WSFederationAuthenticationModule, System.IdentityModel.Services, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" preCondition="managedHandler" />
      <add name="SessionAuthenticationModule" type="System.IdentityModel.Services.SessionAuthenticationModule, System.IdentityModel.Services, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" preCondition="managedHandler" />
      <add name="Glimpse" type="Glimpse.AspNet.HttpModule, Glimpse.AspNet" preCondition="integratedMode" />
    </modules>
    ( . . .)
</system.webServer>

Hi,

Can you make sure that the problem is BlobFactory only? If yes, you can simply register the instance as Singleton in one of your InitializationModule. But it looks like your entire registration for Framework and CMS core is missing, only Shell UI is present. 

What I would suggest is to have your own implementation of InitializationModule, replace it in web.config and have a debugger/logger to see what is going on there.

Regards.

/Q

Hi, just to verify once again before digging deeper.. This is just a speculation, but are you sure that you are not mutating IoC container later on somewhere, or maybe even swapping it out with something else? Why I'm asking is because of this line in log files for example:

2015-06-22 09:41:20.913 INFO            EPiServer.Framework.Initialization.InitializationEngine Initialize action successful for Initialize on class EPiServer.Events.EventsInitialization, EPiServer.Events, Version=8.8.2.0, Culture=neutral, PublicKeyToken=8fe83dea738b45b7

This module registers some interfaces (like, EventProviderService or IEventRegistry) in IoC container - even before FrameworkInitialization module (place where BlobFactory and other guys get registered) kicks in.

Interesting is that these interfaces can't be found in your container dump.

Another question, is log file dump everything EPiServer wrote? To look inside I guess we would need to have a file with "All" error level set for the logger. I can found only INFO entries. There should be more.

Hi

I just scanned through the posts so i dont really know if u discussed the nuget version of structuremap.

When you upgrade from 7.5 you need to change the nuget package manually.

Look att this blogpost http://davidvujic.blogspot.se/2013/12/upgrading-to-episerver-75-without.html

Hope that helps.

Jonas,

Did you ever get this resolved?  I am running into something very similiar and I am not sure what could be causing it.

Thanks,

Steve

Sorry - never got around to wrap this up. It seemed that the custom modules that was made didn't have explicit dependencies defined. Somehow the initialization order was changed during the upgrade til version 8.0, and suddenly the dependencies were important. Defining the dependency explicitly corrected the error according to: http://world.episerver.com/documentation/Class-library/?documentId=cms/9/6816AD61