Unhandled exception with two instances of the WPF viewer

[MarkD]

Hi

We got the following exception when running two instances of an application that was using the WPF viewer control (2012.3.1402.0). It looks like the exception happened because both instances were trying to save settings at the same time. Is there a way to stop the exception occurring? We don't actually need the settings to be saved so having an option to prevent the settings from being saved would be fine. I tried setting StiOptions.Engine.DontSaveSettings to true but this didn't seem to help.

Thanks

------------------------------------------------
System.IO.IOException: The process cannot access the file 'C:\Users\bens\AppData\Local\Stimulsoft\Stimulsoft.Report.settings' because it is being used by another process.
------------------------------------------------
at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy, Boolean useLongPath)
at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share)
at Stimulsoft.Report.StiSettings.Save(String file)
at Stimulsoft.Report.Viewer.StiWpfViewerControl.SaveConfig()
at Stimulsoft.Report.Viewer.StiWpfViewerControl.<>c__DisplayClass1f.<scrollViewer_SizeChanged>b__1e(Object param0, EventArgs param1)
at System.Windows.Threading.DispatcherTimer.FireTick(Object unused)
at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs)
at MS.Internal.Threading.ExceptionFilterHelper.TryCatchWhen(Object source, Delegate method, Object args, Int32 numArgs, Delegate catchHandler)
at System.Windows.Threading.DispatcherOperation.InvokeImpl()
at System.Windows.Threading.DispatcherOperation.InvokeInSecurityContext(Object state)
at System.Threading.ExecutionContext.runTryCode(Object userData)
at System.Runtime.CompilerServices.RuntimeHelpers.ExecuteCodeWithGuaranteedCleanup(TryCode code, CleanupCode backoutCode, Object userData)
at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean ignoreSyncCtx)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Windows.Threading.DispatcherOperation.Invoke()
at System.Windows.Threading.Dispatcher.ProcessQueue()
at System.Windows.Threading.Dispatcher.WndProcHook(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
at MS.Win32.HwndWrapper.WndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
at MS.Win32.HwndSubclass.DispatcherCallbackOperation(Object o)
at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs)
at MS.Internal.Threading.ExceptionFilterHelper.TryCatchWhen(Object source, Delegate method, Object args, Int32 numArgs, Delegate catchHandler)
at System.Windows.Threading.Dispatcher.InvokeImpl(DispatcherPriority priority, TimeSpan timeout, Delegate method, Object args, Int32 numArgs)
at MS.Win32.HwndSubclass.SubclassWndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam)
at MS.Win32.UnsafeNativeMethods.DispatchMessage(MSG& msg)
at System.Windows.Threading.Dispatcher.PushFrameImpl(DispatcherFrame frame)
at System.Windows.Threading.Dispatcher.PushFrame(DispatcherFrame frame)
at System.Windows.Application.RunDispatcher(Object ignore)
at System.Windows.Application.RunInternal(Window window)
at System.Windows.Application.Run(Window window)

[HighAley]

Hello.

Could you send us a sample project which reproduces the issue for analysis.

Thank you.

[MarkD]

The problem is equally likely with any project but it requires precise timing to reproduce. You can reliably reproduce the underlying problem with the Stimulsoft demo application (Demo.Wpf.exe) as follows:

1. Open the settings file (usually C:\Users\<user name>\AppData\Local\Stimulsoft\Stimulsoft.Report.settings) in Microsoft Word to lock it.
2. Start the Demo application

=> Demo application crashes on startup

[HighAley]

Hello.

We now that the Word locks the file but the WFP Demo not. You could run several WPF application without any restriction.
Could you send us a project which reproduces the issue.

Thank you.

[MarkD]

The WPF viewer doesn't keep the settings file locked but the file is locked briefly while the viewer is reading/writing the settings. If two instances of an application try to save the viewer settings at the same time you get the crash.

I've attached a C# application which resizes the viewer repeatedly (resizing seems to cause the settings to be saved). If you run more than one instance of the application one of them should crash after a couple of seconds.

NB. Our corporate firewall seems to be blocking the upload of the attachment. I've uploaded a Base64 encoded zip for now. I'll try to upload a normal zip file tomorrow.

[Alex K.]

Hello,

We run your sent project. And it is working without the any errors.

Thank you.

[MarkD]

You are running two copies of the program? For me it crashes almost immediately with an IOException when I start a second copy of the program.

[Alex K.]

Hello,

The issue is fixed. The solution will be available in the next release which will be available in first part of December.

Thank you.

[MarkD]

Thanks very much. I expect this is a very rare issue in practice but we did see it once in testing so it is good to have it fixed.

[Andrew]

Hello,

Have a great week!

Thank you.