Converting IFC to WexBIM via Azure Function error: Could not load file or assembly 'Xbim.Geometry.Engine.dll' or one of its dependencies. The system cannot find the file specified.

I recently had an Issue with Converting an IFC File to a WexBim File via an Azure Function. The error was that the Xbim.Geometry.Engine64.dll could not be loaded in the state... The fix for that Problem was to change the Azure Function Version from 4.0 to v1.0. If ran the Azure Function on my local Machine everything worked.

But when i try to publish it a Message appeares that i have to Update the Remoteversion of the Azure Functions-Runtime. When i update the Remoteversion and then try to run the Function from the Cloud following Error occures.

Assemblies and versions affected:

.Net Framework: 4.8 Azure Version: 3.1 (After the forced Update it is 1) Xbim.Geometry: 5.1.437 Xbim.IFC: 5.1.341 Xbim.ModelGeometry.Scene: 5.1.437

Steps (or code) to reproduce the issue:

Create an Azure Function with following Version:

Create a C# Azure Function Project and publish following Code to the Function.

using Microsoft.Azure.WebJobs;
using Microsoft.Azure.WebJobs.Extensions.Http;
using Microsoft.Azure.WebJobs.Host;
using System;
using System.IO;
using System.Net;
using System.Net.Http;
using System.Threading.Tasks;
using Xbim.Common.Step21;
using Xbim.Ifc;
using Xbim.IO;
using Xbim.ModelGeometry.Scene;

namespace FunctionApp1
{
    public static class Function1
    {
        [FunctionName("ConvertIFCToWexBIM")]
        public static async Task<HttpResponseMessage> Run([HttpTrigger(AuthorizationLevel.Function, "post", Route = null)] HttpRequestMessage req, TraceWriter log)
        {

            var content = req.Content;
            byte[] bodyBytes = content.ReadAsByteArrayAsync().Result;

            return req.CreateResponse(HttpStatusCode.OK, ConvertFileToWexbim(new MemoryStream(bodyBytes), log).ToArray());
        }

        public static MemoryStream ConvertFileToWexbim(MemoryStream ifcFileContent, TraceWriter log)
        {
            MemoryStream retStream = new MemoryStream();
            try
            {
                using (var model = IfcStore.Open(ifcFileContent, StorageType.Ifc, XbimSchemaVersion.Ifc4, XbimModelType.MemoryModel))
                {
                    Xbim3DModelContext context = new Xbim3DModelContext(model);
                    context.CreateContext();

                    var wexBimBinaryWriter = new BinaryWriter(retStream);
                    model.SaveAsWexBim(wexBimBinaryWriter);
                }
            }catch(Exception ex)
            {
                log.Error(ex.Message);
                throw ex;
            }

            return retStream;
        }
    }
}

Minimal file to reproduce the issue:

SampleHouse.zip

Expected behavior:

The Function should convert the IFC File to a WexBim File and send it as a Base64 String back to the Client.

Actual behavior or exception details:

Doesn't the runtime stack need to be .NET Framework? I'm not familiar with the VS Publish Function dialog, but it's possible you're targeting .netcore3.1 which won't work for xbim Geometry.

What Platform is the function targeting? 64 bit or 32? Does this match the solution Platform? Make sure the correct Xbim.Geometry.Engine[32|64].dll is deployed. (You can use the Azure kudu interface to make sure that all files have published correctly). Make sure both 32 and 64 bit versions are not deployed which could be the case with Any CPU.

The good news is I can tell you this should work - for small models. We use Azure Functions 1.0 to run Geometry operations in xbim Flex so can confirm this should be fine if you get the platform config right.

Side note Once you get over this issue, where you likely will hit issues is with 'real world' models - you're doing all the operations monolithically in memory and I think you'll quickly find with anything much larger than a 2MB SampleHouse.ifc is the service will get shut down by the Azure host when exceeding the various Functions quotas (Memory, IO, CPU time, or a myriad of other transient reasons determined by the Azure Functions Host...). We've invested 3+ years in getting Azure Functions process models reliably/performantly in xbim Flex services - it's non-trivial! Get in touch if you're interested in seeing what we can do to simplify this.

xBimTeam / XbimGeometry