Try our conversational search powered by Generative AI!

Does EPiServer 7.1 support framework 4.5?


We have upgraded a projekt to Framework 4.5 because we need to use the async await that is only in 4.5 and not in 4.0.

Most things works but we had to disable the EPiServer Search totaly because it crashed the application pool and with that the whole site.

Anyone who have a site with EPiServer 7 and EPiServer Search working with Framework 4.5?

Mar 25, 2014 8:41

What was the error for the pool to shutdown? I do have site in this combination.

Mar 26, 2014 0:20

Everything is working fine then suddently (have not found out any clues in why it happens, these two error comes and the application pool dies)


An unhandled exception occurred and the process was terminated.


Application ID: DefaultDomain


Process ID: 12240


Exception: System.Runtime.Serialization.SerializationException


Message: Unable to find assembly 'Lucene.Net, Version=, Culture=neutral, PublicKeyToken=85089178b9ac3181'.


StackTrace:    at System.Runtime.Serialization.Formatters.Binary.BinaryAssemblyInfo.GetAssembly()

   at System.Runtime.Serialization.Formatters.Binary.ObjectReader.GetType(BinaryAssemblyInfo assemblyInfo, String name)

   at System.Runtime.Serialization.Formatters.Binary.ObjectMap..ctor(String objectName, String[] memberNames, BinaryTypeEnum[] binaryTypeEnumA, Object[] typeInformationA, Int32[] memberAssemIds, ObjectReader objectReader, Int32 objectId, BinaryAssemblyInfo assemblyInfo, SizedArray assemIdToAssemblyTable)

   at System.Runtime.Serialization.Formatters.Binary.__BinaryParser.ReadObjectWithMapTyped(BinaryObjectWithMapTyped record)

   at System.Runtime.Serialization.Formatters.Binary.__BinaryParser.Run()

  at System.Runtime.Serialization.Formatters.Binary.ObjectReader.Deserialize(HeaderHandler handler, __BinaryParser serParser, Boolean fCheck, Boolean isCrossAppDomain, IMethodCallMessage methodCallMessage)

   at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Deserialize(Stream serializationStream, HeaderHandler handler, Boolean fCheck, Boolean isCrossAppDomain, IMethodCallMessage methodCallMessage)

   at System.AppDomain.Deserialize(Byte[] blob)

   at System.AppDomain.UnmarshalObject(Byte[] blob)



Application: w3wp.exe

Framework Version: v4.0.30319

Description: The process was terminated due to an unhandled exception.

Exception Info: Lucene.Net.Index.MergePolicy+MergeException


   at Lucene.Net.Index.ConcurrentMergeScheduler.HandleMergeException(System.Exception)

   at Lucene.Net.Index.ConcurrentMergeScheduler+MergeThread.Run()

   at System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)

   at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)

   at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)

   at System.Threading.ThreadHelper.ThreadStart()

Mar 26, 2014 8:38

Stupid question, but do you have Lucene in bin/ folder, all dependencies are satisfied, correct assembly redirects (if any required), pool is able to load a library?

Mar 26, 2014 10:00

Not a stupid question :-)
The dll is in the bin-catalog and the strange thing is that everything is working and then all of the sudden it crasch.

There are no dependency in the web.config, do you have that in your working version?

Mar 26, 2014 10:12

I've seen the same error when two sites using different databases are using to the same folder to store the EPiServer Search Index.

The EPiServer Search Index folder can be changed in web.config:

Change Index or even the complete value of the directoryPath attribute to something completely different.

    <namedIndexes defaultIndex="default">
        <add name="default"
             readonly="false" />

Mar 26, 2014 22:21

Alf, we store the index in a path that is replicated with dfs, perhaps it has gone wrong so that both servers are trying to index and the dfs are messing up the index-file?

Mar 28, 2014 20:13

I've not had the opportunity to investigate exactly what's happening, but in our case it seems like that something gets screwed up when EPiServer Search on both sites are trying to work with the same Index file.

It would not surprise me if the actual problem has something to do with more services are trying to work with your file?

Mar 30, 2014 11:39

Did you work out what was causing the app pool to crash? I've just had the same problem and we are using DFS-R replication (including the index).

For now since we don't need search I'll be disabling it.. but I expect we will need it in the future. I'm assuming I will need to remove the Lucene Index from the DFS-R replication.

Jul 20, 2014 7:47

We do not know exactly what it was but we think it was that both servers tried to index and that together with dfs did make lucene go nuts.

in a load balanced environment it is importent to set up so only one server is updating the index files and then to replicate them to all servers.

see more in the sdk how to do this, I do not have the links here.

Good luck!

Jul 20, 2014 9:10

That certainly is what appeared to be occuring. For now I've setup each server with it's own index (not DFS-R shared). It's not an efficient use of resources... but our farms is 10 servers and I don't want to have to keep track as to which is the index server!

Jul 21, 2014 1:20

Very true Bevan. EPiServer Search is not the best solution when in a big enviroment, it is mutch better to use EPiServer Find as a internal search also, but that will cost extra.

I hope EPiServer will offer a hosted service for the EPiServer Search in the future.

Jul 21, 2014 8:14
This thread is locked and should be used for reference only. Please use the Episerver CMS 7 and earlier versions forum to open new discussions.
* You are NOT allowed to include any hyperlinks in the post because your account hasn't associated to your company. User profile should be updated.