Problem with using Stream as input and XmlResolver

Hello, we are glad that the option to use streams as inputs for BindXml was implemented but using it we got to an another problem. When using the BindXml(Stream,Stream) method the XmlResolver used to resolve the xsl;import does not function correctly as it looks in the current assembly execution directory (C:\windows\system32) not in the directoroy of the filestream provided. This was not a problem when using the BindXml(string,string).

What would solve our problem is if you provided a way to send in XmlReaderSettings object or XmlResolver object to be used when calling the BindXml(Stream,Stream) method so the interface would be

BindXml(Stream,Stream, XmlReaderSettings)
creating a XmlReaderSettings and providing a custom XmlResolver

XmlReaderSettings settings = new XmlReaderSettings();
settings.XmlResolver = new CustomXmlResolver();

and then load the compiled transformation with the provided XmlReaderSetting from the stream.

This would also solve the problem with loading external resources in .Net 4.5.2

as written in
https://msdn.microsoft.com/en-us/library/system.xml.xmlreadersettings.xmlresolver(v=vs.110).aspx

XSLT Transformation code

<?xml version="1.0" encoding="utf-16"?>
<xsl:stylesheet version=“1.0” xmlns:xsl=“http://www.w3.org/1999/XSL/Transform” xmlns:msxsl=“urn:schemas-microsoft-com:xslt” exclude-result-prefixes=“msxsl”>
<xsl:import href="…\Templates.xslt"/>
<xsl:import href="…\Enums.xslt"/>
<xsl:output method=“xml” indent=“yes”/>
<xsl:template match="/ClassNametoMatchTheXMLModel">
</xsl:template>
</xsl:stylesheet>

Sample code to create pdf document from XSLT transformation and xml model.

using (var ms = new MemoryStream())
{
Thread.CurrentThread.CurrentCulture = CultureInfo.InvariantCulture;
Aspose.Pdf.Document doc = new Aspose.Pdf.Document();

string templatePath = Path.Combine(“pathtofile”, @“template.xslt”);
using (var ts = new FileStream(templatePath, FileMode.Open, FileAccess.Read, FileShare.Read))
{
<span style=“font-family: “Courier New”;”> doc.BindXml(xms, ts);
<span style=“font-family: “Courier New”;”> doc.Save(ms);
}
return ms.ToArray();
}

Hi Roman,


Thanks for your inquriy. We have logged a ticket PDFNET-42222 in our issue tracking system for further investigation and rectification of the issue. We will keep you updated about the issue resolution progress within this forum thread.

We are sorry for the inconvenience.

Best Regards,

Hello,


do you have any time scope regarding this issue (PDFNET-42222) that we could rely on to be able to plan our development?

Best regards
Roman Taborsky

Hi Roman,


Thanks for your inquriy. I am afraid we can not share any timeline at the moment, as we have recently noticed the issue. As soon as our product team completes the issue investigation, then we will be in a good position to share an ETA/workaround with you. We will notify you as soon as some update is available.

Thanks for your patience and cooperation.

Best Regards,

Hello,

are there any news regarding the issue PDFNET-42222 ?

Best regards

Roman Taborsky

Hi Roman,


Thanks for your inquiry. I am afraid your issue is still not resolved, it is pending for investigation as product team is looking into the other issues in the queue. We will notify you as soon as some update is available.

Thanks for your patience and cooperation.

Best Regards,

Hello Ahmad,


I would like to ask whether there is an update on this issue or at least a timeplan when the issue will be investigated?

Best Regards
Roman Taborsky

Hi Roman,


Thanks for your inquiry. I am glad to let you know that issue has been fixed and it will available in the next release.

We are sorry for this inconvenience.

Best Regards,

Hello,


thank you for the information, but I would like to ask in which release it will be fixed?
We are using assembly Aspose.Pdf 17.4.0.0 and it is not fixed there.

Best regards
Roman Taborsky

Hello Roman,


Thanks for your inquiry.

A fix to your issue will be included in Aspose.Pdf for .NET 17.5.0 which is expected to be released within this week or early next week. We are sorry for the delay and inconvenience.


Best Regards,

The issues you have found earlier (filed as PDFNET-42222) have been fixed in Aspose.Pdf for .NET 17.5.


This message was posted using Notification2Forum from Downloads module by Aspose Notifier.

Hello,


we tested the new functionality - XmlReaderSettings parameter but with no sucess.

First we created custom XmlResolver just as a wrapper to default XmlUrlResolver that is used:
public class RelativePathXmlResolver : XmlUrlResolver
{

public RelativePathXmlResolver(): base()
{

}
//
// Summary:
// Maps a URI to an object that contains the actual resource.
//
// Parameters:
// absoluteUri:
// The URI returned from System.Xml.XmlResolver.ResolveUri(System.Uri,System.String).
//
// role:
// Currently not used.
//
// ofObjectToReturn:
// The type of object to return. The current implementation only returns System.IO.Stream
// objects.
//
// Returns:
// A stream object or null if a type other than stream is specified.
//
// Exceptions:
// T:System.Xml.XmlException:
// ofObjectToReturn is neither null nor a Stream type.
//
// T:System.UriFormatException:
// The specified URI is not an absolute URI.
//
// T:System.ArgumentNullException:
// absoluteUri is null.
//
// T:System.Exception:
// There is a runtime error (for example, an interrupted server connection).
public override object GetEntity(Uri absoluteUri, string role, Type ofObjectToReturn)
{
return base.GetEntity(absoluteUri, role, ofObjectToReturn);
}
//
// Summary:
// Asynchronously maps a URI to an object that contains the actual resource.
//
// Parameters:
// absoluteUri:
// The URI returned from System.Xml.XmlResolver.ResolveUri(System.Uri,System.String).
//
// role:
// Currently not used.
//
// ofObjectToReturn:
// The type of object to return. The current implementation only returns System.IO.Stream
// objects.
//
// Returns:
// A stream object or null if a type other than stream is specified.
public override Task GetEntityAsync(Uri absoluteUri, string role, Type ofObjectToReturn)
{
return base.GetEntityAsync(absoluteUri, role, ofObjectToReturn);
}
//
// Summary:
// Resolves the absolute URI from the base and relative URIs.
//
// Parameters:
// baseUri:
// The base URI used to resolve the relative URI.
//
// relativeUri:
// The URI to resolve. The URI can be absolute or relative. If absolute, this value
// effectively replaces the baseUri value. If relative, it combines with the baseUri
// to make an absolute URI.
//
// Returns:
// The absolute URI, or null if the relative URI cannot be resolved.
//
// Exceptions:
// T:System.ArgumentNullException:
// baseUri is null or relativeUri is null.
public override Uri ResolveUri(Uri baseUri, string relativeUri)
{
return base.ResolveUri(baseUri, relativeUri);
}
}

After this we tried to call the BindXml with the new parameter:
doc1.BindXml(new FileStream(“pdfData.xml”, FileMode.OpenOrCreate), new FileStream(@“transformation.xslt”, FileMode.OpenOrCreate),
new XmlReaderSettings() {
XmlResolver = new RelativePathXmlResolver()
} );

but during debug we once again got the exception {“Could not find a part of the path ‘C:\\PDFTests\PDFTestAspose\bin\Common\Enums.xslt’.”}

and the debugger did not step into our new RelativePathXmlResolver.

When we see the stack trace of inner exception (FileNotFound) we can see that still the default XmlUrlResolver is used.

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, Boolean checkHost)
at System.IO.FileStream…ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize)
at System.Xml.XmlDownloadManager.GetStream(Uri uri, ICredentials credentials, IWebProxy proxy, RequestCachePolicy cachePolicy)
at System.Xml.XmlUrlResolver.GetEntity(Uri absoluteUri, String role, Type ofObjectToReturn)
at System.Xml.Xsl.Xslt.XsltLoader.CreateReader(Uri uri, XmlResolver xmlResolver)
at System.Xml.Xsl.Xslt.XsltLoader.LoadStylesheet(Uri uri, Boolean include)
at System.Xml.Xsl.Xslt.XsltLoader.LoadStylesheet(XmlReader reader, Boolean include)

We were able to simulate this error when loading XmlCompiledTransformation:

var xslStream = new FileStream(@“transformation.xslt”, FileMode.OpenOrCreate);
var resolver = new RelativePathXmlResolver();
var settings = new XmlReaderSettings()
{

XmlResolver = resolver
};
XmlReader stylesheet = XmlReader.Create(xslStream, settings);
var compiledTransform = new XslCompiledTransform();
compiledTransform.Load(stylesheet);

and the fix to this was using the compiledTransform Load function with specified resolver:

compiledTransform.Load(stylesheet,new XsltSettings(),resolver);

this was the only way we were able to load a XslCompiledTransform with a different XmlResolver.

what we are trying to achieve is to allow us for entering a base from which relative uris will be resolved in XmlResolver like this

public Uri RootPathUri { get; set; }
public override Uri ResolveUri(Uri baseUri, string relativeUri)
{
if (baseUri == null)
{
return base.ResolveUri(RootPathUri, relativeUri);
}
return base.ResolveUri(baseUri, relativeUri);
}

Hello Roman,


Thanks for sharing details with us.

I have tested the scenario in our environment using our sample files and noticed that API was generating an issue while reading input as stream. Hence for the sake of investigation, I have generated investigation tickets as PDFNET-42792 and PDFNET-42793 for both input stream and XmlResolver related issues respectively.

We will really appreciate if you please share your sample input files (i.e XML and XSLT), as this will help us in investigating the issue accordingly. As soon as we have some updates regarding above tickets, we will let you know. Please be patient and spare us little time.

We are sorry for the inconvenience.


Best Regards,
The XSLT is posted in the first post in this thread. The import files can be empty XML files, just with the XSLT headers

<?xml version="1.0" encoding="utf-16"?>


The data XML is taken from another model, but again - it does not matter as the problem occurs before applying the transformation but during the load of the XSLT to compiled transformation.

<?xml version="1.0" encoding="utf-16"?>
testId
Kúpna zmluva
</ClassNametoMatchTheXMLModel>


Hello Roman,


Thanks for adding details. We have shared related information with the development team and as soon as we have some feedback from their side, we will inform you. Please be patient and spare us little time. We are sorry for the inconvenience.


Best Regards,