Gepsio Released

A NuGet package for Gepsio is now available here. Release notes for this version are available here. This release includes support for reference linkbases and automatic support for several new industry standard taxonomies, including schemas from IFRS and US-GAAP.

The last three releases have been published on a monthly basis. Version was released at the beginning of June, version was released at the beginning of July, and this new version at the beginning of August. This cadence brings smaller changes with each release but puts changes in the hands of users more frequently.



Single Assembly Design Reinstated; Stay of Execution for .NET 3.5 Support

The last post discussed a future design whereby Gepsio would ship as two assemblies and that, as a result of this work, would no longer be able to support .NET 3.5.

Never mind.

MissingManifestResourceException Thrown In UWP Calls To PCL Resources

Some work has gone into implementing the design discussed in that last post. The design centered around a Portable Class Library (PCL)¬†which held Gepsio’s string resources as well as a small class that returned strings from the PCL to the caller. In the solution structure, a separate PCL called JeffFerguson.Gepsio.Resources which targeted Windows 10 and .NET 4 was created, and all of the Gepsio assemblies referenced that PCL project. The Gepsio RESX string table was added as a resource in the PCL, and a simple class was added to the PCL:

public class AssemblyResources
    public static string GetName(string Key)
        return Gepsio.ResourceManager.GetString(Key);

    public static string BuildMessage(string Key, params object[] Parameters)
        var Message = new StringBuilder();
        string MessageFormat = GetName(Key);
        Message.AppendFormat(MessageFormat, Parameters);
        return Message.ToString();

From there, the main Gepsio code would call this PCL class when string resources were needed.

For Gepsio’s .NET assemblies, this all worked well. Gepsio called into the PCL, which accessed a string resource and returned it to Gepsio. Perfect!

For Gepsio’s UWP assembly, however, the same code path crashed. Gepsio called into the PCL, but the call to the Resource Manager’s GetString() method threw an exception:

Result StackTrace:
at System.Resources.ResourceManager.GetString(String name, CultureInfo culture)
   at System.Resources.ResourceManager.GetString(String name)
   at JeffFerguson.Gepsio.Resources.AssemblyResources.GetName(String Key)
   at JeffFerguson.Gepsio.XbrlSchema..ctor(XbrlFragment ContainingXbrlFragment, String SchemaFilename, String BaseDirectory)
   at JeffFerguson.Gepsio.XbrlFragment.ReadTaxonomySchemaReference(INode SchemaRefNode)
   at JeffFerguson.Gepsio.XbrlFragment.ReadTaxonomySchemaReferences()
   at JeffFerguson.Gepsio.XbrlFragment..ctor(XbrlDocument ParentDocument, INamespaceManager namespaceManager, INode XbrlRootNode)
   at JeffFerguson.Gepsio.XbrlDocument.Parse(IDocument doc)
   at JeffFerguson.Gepsio.XbrlDocument.Load(String Filename)
   at XbrlConformanceSuiteTests.ConformanceSuiteUnitTests.TestVariation(String testcaseFolderName, String instance, String description, Boolean shouldBeValid)
   at XbrlConformanceSuiteTests.ConformanceSuiteUnitTests.<ExecuteTestcase>d__2.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.GetResult()
   at XbrlConformanceSuiteTests.ConformanceSuiteUnitTests.<XbrlConfCR520120124>d__1.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
Result Message:	Test method XbrlConformanceSuiteTests.ConformanceSuiteUnitTests.XbrlConfCR520120124 threw exception:
System.Resources.MissingManifestResourceException: Unable to load resources for resource file "JeffFerguson.Gepsio.Resources.Gepsio" in package "bc7a23a2-a1ca-4481-8eb3-74680ae1e9c8".

This issue was brought up in a Stack Overflow question, but no answers were offered.

So much for the PCL being portable.

Resource Management Plan Going Forward

The backup plan is to maintain two separate string tables. One string table will be maintained in the Gepsio .NET projects as an RESX file, and a second string table will be maintained in the Gepsio UWP projects as an RESW file. It’s a shame that the string tables will need to be maintained in two places, but, if a single portable location isn’t going to work, then there is not much choice. Hopefully, it won’t be a huge issue.

Retaining Support for .NET 3.5

The last post mentioned that PCLs do not support .NET 3.5 and, as a result of the proposed Gepsio design making use of PCLs, future versions of Gepsio would not be able to support .NET 3.5. Now that the PCL design has proven to be unworkable, Gepsio can and will support .NET 3.5 for the foreseeable future.

Gepsio for Universal Windows Underway

The following email came in to the Gepsio inbox today:


I am very interested in trying out Gepsio on the windows 10 universal app platform.

I saw that a universal windows project has been added to the repo without some vital xml parts.

Will there be a new patch soon with the remaining parts?

As a matter of fact, yes! That work is underway now.

The email is referencing this changeset, which contains the following somewhat-cryptic description:

Universal Windows project added. XML implementation for Universal Windows is not implemented, and there are no unit tests for Universal Windows, so Gepsio for Universal Windows cannot be used at this time. The .NET builds are, as always, fully supported.

That changeset included a new project in the Gepsio solution – a project which would target a Gepsio assembly tuned for the Windows 10 Universal Windows Platform (or UWP, for short). The vision is to allow Gepsio to be used by developers wishing to build XBRL-enabled applications on Windows 10 UWP.

Thanks to the interface-based separation between Gepsio’s XML service layer and its XBRL semantic layer, described here, the work needed to allow Gepsio to support Windows 10 UWP is not a “do over”. The work involved is, basically, to build new XML interface implementations that use Windows 10 UWP instead of .NET. This work is underway now. In fact, Gepsio already has enough UWP code to open up an XML document and search for <xbrl> nodes in Windows 10. This is exciting, as it means that Gepsio can be used for code that runs on any Windows 10 UWP platform, from the phone, to the tablet, to the desktop, to the Xbox One.

The Windows 10 UWP code is not ready, and, although the project skeleton has been checked in, the XML layer for Windows 10 UWP is not ready. That code is in progress. When it’s ready, there will be a blog post announcing the new code. The code is not a straightforward port from the .NET XML code, for the following reasons:

  • The .NET code uses the XML classes in the System.Xml namespace. The Windows 10 UWP code is using XML classes in the Windows.Data.Xml.Dom namespace.
  • The Windows 10 UWP makes use of asynchronous methods; for example, XmlDocument.Load() has become await XmlDocument.LoadFromFileAsync(). Ensuring that Gepsio supports this asynchronous model, while still maintaining the existing needs of the Gepsio XBRL semantic layer, will need some additional work.
  • Unlike .NET’s System.Xml namespace, the Windows 10 UWP’s Windows.Data.Xml.Dom namespace does not have any built in support for XML Schema. XBRL relies on XML Schema documents for its taxonomies. Gepsio’s XML Schema¬†support will have to be written from the ground up since there is no support for XML Schema in UWP.

Gepsio will retain its .NET builds as well. Gepsio will continue to support .NET 3.5, .NET 4, .NET 4.5, .NET 4.5.1, .NET 4.5.2, and .NET 4.6. If you’re not ready to move to Windows 10 UWP just yet, do not worry – all of the .NET builds will continue to be supported and ship for the foreseeable future.