Aspose.Words and .Net 4.0

I am converting some older code to .Net 4.0 and it is crashing in the Microsoft font libraries. Specifically, the final/first line in the StackTrace identifies:
MS.Internal.FontCache.FontFaceLayoutInfo.IntMap.TryGetValue(Int32 key, UInt16& value)

Given that we have an older version of Aspose and our subscription has expired I was wondering if anyone has experience the same issue and if so, is there a fix. From the license file it appears the license is for 2.2 Aspose.Words for .Net.

Thank you for any help you can provide.

Larry Whipple
Arcom

Hi Larry,

Thanks for your inquiry.

Well, you’re using a very old version of Aspose.Words; unfortunately, we don’t provide support for older released versions of Aspose.Words. Also, please note that we do not provide any fixes or patches for old versions of Aspose products either. All fixes and new features are always added into new versions of our products. So, you will have to upgrade if you need new features or fixes.

Secondly, could you please attach your input Word document and code, you’re getting this problem with, here for testing? I will investigate the issue using Aspose.Words 13.1.0 on my side and provide you more information.

Moreover, you are welcome to download the latest version of Aspose.Words for evaluation. The evaluation download is the same as the purchased download. The evaluation version simply becomes licensed when you add a few lines of code to apply the license.

The evaluation version of Aspose.Words (without a license specified) provides full product functionality, but it inserts an evaluation watermark at the top of the document on open and save, and limits the maximum document size to several hundred paragraphs.

If you want to test the latest version of Aspose.Words without the evaluation version limitations, you can also request a 30-day Temporary License. Please refer to How to get a Temporary License? Please try setting the license on your side and run your scenario over Aspose.Words 13.1. I hope, this helps.

Best Regards,

Hey Awais,

Thanks for your response. I installed the latest greatest and ran it under the evaluation license. I recompiled the entire solution (40+ projects) as .NET 4 and .NET 4.5 - both got the same error. The salient method is as follows:

protected void GenerateFixedDocumentFromFile(string tempXamlLocation)
{
    Application.Current.Dispatcher.BeginInvoke(new Action(() =>
    {
        using (FileStream inputStream = File.OpenRead(tempXamlLocation))
        {
            string absolutePath = Path.GetFullPath(tempXamlLocation);
            string directoryPath = Path.GetDirectoryName(absolutePath);
            var pc = new ParserContext
            {
                // It is critical to have the trailing backslash here
                // will not work without it!
                BaseUri = new Uri(directoryPath + Path.DirectorySeparatorChar)
            };

            var fixedDocument = (FixedDocument)XamlReader.Load(inputStream, pc);
            var docReference = new DocumentReference();
            docReference.SetDocument(fixedDocument);
            var fixedDocuementSequence = new FixedDocumentSequence();
            fixedDocuementSequence.References.Add(docReference);

            Document = fixedDocuementSequence;
        }
        File.Delete(tempXamlLocation);
        AltarixMessenger.Send(new object(), Notifications.UnblockUIAction);
        AltarixMessenger.Send((PrintableViewModel)this, Notifications.DocumentXamlGenerationComplete);

    }), DispatcherPriority.Send, null);

As you can see, we are generating a FixedDocument in Xaml utilizing the document builder. The resulting code gets saved to the file system and then loaded here for rendering. With version 11.8 of your libraries, compiling under .net 3.5 it works fine. When we moved to .net 4 and VS 2012 it started breaking right on the XamlReader.Load statement. Here is the stack trace:

System.NullReferenceException was unhandled
HResult=-2147467261
Message=Object reference not set to an instance of an object.
Source=PresentationCore
StackTrace:
at MS.Internal.FontCache.FontFaceLayoutInfo.IntMap.TryGetValue(Int32 key, UInt16& value)
at System.Windows.Media.GlyphTypeface.Initialize(Uri typefaceSource, StyleSimulations styleSimulations)
at System.Windows.Documents.Glyphs.ParseGlyphRunProperties()
at System.Windows.Documents.Glyphs.ComputeMeasurementGlyphRunAndOrigin()
at System.Windows.Documents.Glyphs.MeasureOverride(Size constraint)
at System.Windows.FrameworkElement.MeasureCore(Size availableSize)
at System.Windows.UIElement.Measure(Size availableSize)
at System.Windows.Controls.Canvas.MeasureOverride(Size constraint)
at System.Windows.FrameworkElement.MeasureCore(Size availableSize)
at System.Windows.UIElement.Measure(Size availableSize)
at System.Windows.Controls.Canvas.MeasureOverride(Size constraint)
at System.Windows.FrameworkElement.MeasureCore(Size availableSize)
at System.Windows.UIElement.Measure(Size availableSize)
at System.Windows.Controls.Canvas.MeasureOverride(Size constraint)
at System.Windows.FrameworkElement.MeasureCore(Size availableSize)
at System.Windows.UIElement.Measure(Size availableSize)
at System.Windows.Controls.Canvas.MeasureOverride(Size constraint)
at System.Windows.FrameworkElement.MeasureCore(Size availableSize)
at System.Windows.UIElement.Measure(Size availableSize)
at System.Windows.Documents.FixedPage.MeasureOverride(Size constraint)
at System.Windows.FrameworkElement.MeasureCore(Size availableSize)
at System.Windows.UIElement.Measure(Size availableSize)
at System.Windows.Documents.FixedDocument.GetPage(Int32 pageNumber)
at System.Windows.Documents.FixedDocument.OnInitialized(Object sender, EventArgs e)
at MS.Internal.Xaml.Runtime.ClrObjectRuntime.InitializationGuard(XamlType xamlType, Object obj, Boolean begin)
at System.Xaml.XamlObjectWriter.Logic_EndInit(ObjectWriterContext ctx)
at System.Xaml.XamlObjectWriter.WriteEndObject()
at System.Windows.Markup.WpfXamlLoader.TransformNodes(XamlReader xamlReader, XamlObjectWriter xamlWriter, Boolean onlyLoadOneNode, Boolean skipJournaledProperties, Boolean shouldPassLineNumberInfo, IXamlLineInfo xamlLineInfo, IXamlLineInfoConsumer xamlLineInfoConsumer, XamlContextStack`1 stack, IStyleConnector styleConnector)
at System.Windows.Markup.WpfXamlLoader.Load(XamlReader xamlReader, IXamlObjectWriterFactory writerFactory, Boolean skipJournaledProperties, Object rootObject, XamlObjectWriterSettings settings, Uri baseUri)
at System.Windows.Markup.XamlReader.Load(XamlReader xamlReader, ParserContext parserContext)
at System.Windows.Markup.XamlReader.Load(XmlReader reader, ParserContext parserContext, XamlParseMode parseMode)
at System.Windows.Markup.XamlReader.Load(Stream stream, ParserContext parserContext)
at Linx2.Client.ViewModel.ViewModels.ReportViewModels.GeneratedDocumentViewModelBase.<>c__DisplayClass2.b__1() in c:\Dev\Arcom\Altarix\trunk\src\Client\Linx2.Client.ViewModel\ViewModels\ReportViewModels\GeneratedDocumentViewModelBase.cs:line 62
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.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
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.LegacyInvokeImpl(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.Application.RunInternal(Window window)
at System.Windows.Application.Run()
at Linx2.Client.Gui.AltarixStartup.Main(String[] args) in c:\Dev\Arcom\Altarix\trunk\src\Client\Linx2.Client.Gui\AltarixStartup.cs:line 0
at System.AppDomain._nExecuteAssembly(RuntimeAssembly assembly, String[] args)
at Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly()
at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Threading.ThreadHelper.ThreadStart()
InnerException: 

As you can see, ultimately it’s MS.Internal.FontCach.FontFaceLayoutInfo… which fails. Could there be something in the dottl files that Aspose creates that isn’t getting set?

Any help you can provide on this would be greatly appreciated. If we can’t fix this issue we either have to go back to 3.5 (which we would rather not do at this point) or use a different library to build the FixedDocument and render the reports. We’re already on a beta release to a limited audience and they all have the 3.5 version that works properly.

Let me know if there is anything else you need to know, and thank you again for your assistance.

Larry Whipple
Arcom

Hi Larry,

Thanks for the additional information. Please create a simple application (for example a Console Application Project) that helps us reproduce the same exception on our end and attach it here for testing. Unfortunately, it is difficult to say what the problem is without the Document and simplified application. We need this Document and Simple Project to reproduce the problem. As soon as you get these pieces of information to us we’ll start our investigation into your issue.

Many thanks,

I’ve created the “simple” project. It is set up as close to the solution that is crashing as possible. I’ve removed some of the more proprietary code, but please treat the test project I am sending you as confidential.

You’ll notice once you unzip and review the project that it relies on a “dev” folder being placed off the root of the c drive. This is used to house the .xaml file which the code creates. The interface is quite simplistic - just a main xaml page with a button. That will allow you to trace through the project and see the area where it dies (GenerateDocumentViewModelBase.GenerateFlowDocumentFromFile).

Again, this issue only arose when we moved to VS 2012 and .Net 4. It’s throwing the exception in an STA thread that we spawn in the method noted above. It dies when we try to load the xaml file that was created with Aspose’s objects. The stacktrace which I included in an earlier post seems to indicate that it has something to do with the odttf files that get dynamically created.

Please feel free to contact me with any additional questions. You can also reach me on google chat at larry.whipple@gmail.com. I’m on there pretty much the entire business day US Mountain Time (GMT-7).

Thank you again for your invaluable help.

Larry Whipple
Arcom

Hi Larry,

Thanks for the additional information. I have tested the scenario and have managed to reproduce the same exception on my side. For the sake of correction, I have logged this problem as WORDSNET-7803 in our issue tracking system. Our development team will further look into the details of this problem and we will keep you updated on the status of correction. We apologize for your inconvenience.

Best regards,

Hi Larry,
Thank you for reporting this issue to us. I analyzed the problem and it seems this is kind of bug in .NET framework, but not in Aspose.Words. It seems framework does not like some font names. See the discussion here:
http://stackoverflow.com/questions/3075403/wpf-saving-font-to-disk-then-instantiating-glyphtypeface-for-font-throws-exce
However, I can propose you a very good workaround. As you may know Aspose.Words also supports export to XPS format. XPS is fixed XAML package that contains all required resources inside. So I think in your case, you can replace fixed XAML intermediate format with XPS. For instance see the following code:

using (MemoryStream xpsStream = new MemoryStream())
{
    // Generate document.
    Aspose.Words.DocumentBuilder builder = new Aspose.Words.DocumentBuilder();
    builder.Write("This is the test document.");
    // Save output document into stream as XPS.
    builder.Document.Save(xpsStream, Aspose.Words.SaveFormat.Xps);
    const string memoryName = "memorystream://ms.xps";
    Uri memoryUri = new Uri(memoryName);
    try
    {
        PackageStore.RemovePackage(memoryUri);
    }
    catch (Exception)
    {
    }
    Package package = Package.Open(xpsStream);
    PackageStore.AddPackage(memoryUri, package);
    XpsDocument xps = new XpsDocument(package, CompressionOption.SuperFast, memoryName);
    FixedDocumentSequence fixedDocumentSequence = xps.GetFixedDocumentSequence();
    documentViewer1.Document = fixedDocumentSequence;
}

As you can see using XPS format you can even exclude saving file into the temporary folder, you can save XPS file directly into stream.
Please let me know if this solution is acceptable for you and whether the issue can be closed.
Best regards,

Alexey,

Thank you for the memory stream idea. The only thing missing was the fact that we use an STA thread to create and set the FixedDocument since this is for a report. Here’s my final solution that appears to be working fine. Thanks again for the suggestion (the using statement occurs higher up in the chain, but it’s there too). Hopefully your developers will be able to resolve the issue with the .NET Framework.

Thanks again.

protected void GenerateFlowDocumentFromFile(MemoryStream xpsStream)
{
    byte[] ba = xpsStream.ToArray();
    Application.Current.Dispatcher.BeginInvoke(DispatcherPriority.Send, (Action)(() => HandleFixedDocument(ba)));
}

public void HandleFixedDocument(byte[] ba)
{
    var ms = new MemoryStream(ba);
    var tempPackageName = Guid.NewGuid().ToString();
    var memoryName = "memorystream://" + tempPackageName + ".xps";
    var memoryUri = new Uri(memoryName);
    try
    {
        PackageStore.RemovePackage(memoryUri);
    }
    catch (Exception)
    {
    }

    var package = Package.Open(ms);
    PackageStore.AddPackage(memoryUri, package);
    var xps = new XpsDocument(package, CompressionOption.SuperFast, memoryName);
    var fixedDocumentSequence = xps.GetFixedDocumentSequence();
    Document = fixedDocumentSequence;
    try
    {
        PackageStore.RemovePackage(memoryUri);
    }
    catch (Exception)
    {
    }
}

Hi Larry,

It is to update you that the developer has completed the work on your ticket (WORDSNET-7803) and has come to a conclusion that your issue and the behaviour you’re observing is actually not a bug in Aspose.Words. So, we have closed this issue as ‘Not a Bug’. If we can help you with anything else, please feel free to ask.

Best regards,

I’m curious as to how you can decide this is not a bug when you can recreate the exact behavior as you said you could. Frankly I’m disappointed that you are taking this approach as this is clearly an issue and I’m not the only one who has had it, as you also pointed out. This is an issue with .NET 4.0 and I assume 4.5 as well since the issue didn’t resolve itself when I moved the project to 4.5. As you pointed out, it appears that Microsoft has chosen to be more particular about font names. I seriously doubt they’ll be changing their stance, so for the good of your product I would highly recommend that you reopen that bug and get it fixed for a future version. I have a solution for my current problem, but it did take a significant amount of time to identify where the bug was and to put in a work-around. It would seem fairly straight forward to work with Microsoft to find out what the acceptable naming conventions would be and to adjust your code to use them.

Thank you again for helping me to find a work-around.

Yours,

Larry Whipple

Hi Larry,

Thank you for additional information. I created another issue for this problem. We will let you know once it is resolved.

Best regards,

The issues you have found earlier (filed as WORDSNET-7823) have been fixed in this .NET update and this Java update.


This message was posted using Notification2Forum from Downloads module by aspose.notifier.

The issues you have found earlier (filed as WORDSNET-7803) have been fixed in this .NET update and this Java update.


This message was posted using Notification2Forum from Downloads module by aspose.notifier.