PromptDialog.Confirm loop in .NET Core 2.0 about botbuilder.standard

[CXuesong]

Did you see any exceptions bubbled up in the Output window of your VS debugger/activity log? Seems that Bot Builder resets the conversation if unhandled exceptions occurs.

[CXuesong]

I've created a simple project containing your code, and it works well.

• Project
• Your code

My suggestion is

• try the PromptDialog in a class without LUIS in your project, and see whether it works.
• as I've mentioned, note if there is any exception shown in the Output window when you see abnormal behavior

[mastermaq]

Thank you for putting that together! That helped me figure out the issue. I don't remember why now, but I had the following in my Startup class (probably a copy/paste from one of the official samples):

public Startup(IConfiguration configuration)
{
    Configuration = configuration;

    RegisterBotModules();
}

private void RegisterBotModules()
{
    Conversation.UpdateContainer(builder =>
    {
        builder.RegisterModule(new ReflectionSurrogateModule());
    });
}

That registermodule line with the ReflectionSurrogateModule appears to be the culprit. If I comment out that code, it works just fine.

This is the exception thrown when the abnormal behavior occurs:

Exception on deserializing stored data! Stack has been cleared. Details: System.NullReferenceException: Object reference not set to an instance of an object.
at Microsoft.Bot.Builder.Internals.Fibers.Serialization.StoreInstanceByFieldsSurrogate.System.Runtime.Serialization.ISerializationSurrogate.SetObjectData(Object obj, SerializationInfo info, StreamingContext context, ISurrogateSelector selector)
at Microsoft.Bot.Builder.Internals.Fibers.Serialization.SurrogateLogDecorator.System.Runtime.Serialization.ISerializationSurrogate.SetObjectData(Object obj, SerializationInfo info, StreamingContext context, ISurrogateSelector selector)
at System.Runtime.Serialization.ObjectManager.FixupSpecialObject(ObjectHolder holder)
at System.Runtime.Serialization.ObjectManager.DoFixups()
at System.Runtime.Serialization.Formatters.Binary.ObjectReader.Deserialize(BinaryParser serParser, Boolean fCheck)
at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Deserialize(Stream serializationStream, Boolean check)
at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Deserialize(Stream serializationStream)
at Microsoft.Bot.Builder.Internals.Fibers.FormatterStore1.Microsoft.Bot.Builder.Internals.Fibers.IStore<T>.TryLoad(T& item) at Microsoft.Bot.Builder.Internals.Fibers.ErrorResilientStore1.Microsoft.Bot.Builder.Internals.Fibers.IStore.TryLoad(T& item)

Thanks!

[CXuesong]

Yes, the source of problem is StoreInstanceByFieldsSurrogate registered in ReflectionSurrogateModule , which is used to make non-serializable types "serializable" by persisting and restoring their fields.

The problem is, In .NET Core, RuntimeType is not serializable, and BinaryFormatter will try to use it to deserialize it. But as I have mentioned in dotnet/corefx#23785, BinaryFormatter in .NET Core does not support resolving this Type instace of RuntimeType very well, so I used my TypeSerializationSurrogate implementation to handle this.

When serializing your objects, TypeSerializationSurrogate almost has the lowest negative priority, while StoreInstanceByFieldsSurrogate has the priority of 2, so it will take precedence to my TypeSerializationSurrogate.

BotBuilder.Standard/CSharp/Library/Microsoft.Bot.Builder.Autofac/Fibers/FiberModule.cs

Lines 196 to 199 in f035889

	builder
	.Register(c => new Serialization.StoreInstanceByFieldsSurrogate(priority: 2))
	.Keyed<Serialization.ISurrogateProvider>(FiberModule.Key_SurrogateProvider)
	.SingleInstance();

Thus, my suggestion is that you not take any shortcuts, but make your classes serializable, so that the use of StoreInstanceByFieldsSurrogate can be removed. If, still, you want to use this class, then copy the code above, and reduce the priority to a number greater than 10 - int.MaxValue.

[mastermaq]

Thank you!