Subscribe to this thread
Home - General / All posts - Troubleshooting list for scripts
345 post(s)
#04-Aug-19 20:08

I have composed a list of errors that might occur while writing Manifold scripts/add-ins/apps. There is also a .cs file in the attachment.

Developing scripts/add-ins/apps with cutting edge Manifold 9 builds is very easy - no separate SDK to install, one source file is often enough, etc.

But it can sometimes also be tricky, if there is an error message and you do not know what caused it.

Problems with add-in .dll or .cs file.

1. Addin is not visible in Tools -> Add-ins -> ...

* Missing *.dll.addin file

* Add empty MyAddin.dll.addin

* The dll does not have class Script

* rename the main class to Script

* Class Script is not public

* add public to class Script

* Class Script is not in default namespace

* remove explicit namespace

* Script does not have method Main

* rename method to Main

* Main method is not static

* add static to Main

* Main method is not public

* add public to Main

2. Can't run script, no entry point (Script.Main).

* Script.Main cannot take arguments

* remove any arguments

3. Object reference not set to an instance of an object.

* Class Script has field of type Manifold.Context but not named Manifold

* rename the field to Manifold

4. An object reference is required for the non-static field, method, or property 'Script.Manifold'

* Script.Manifold is not static field

* add static to the field Script.Manifold

Problems with standalone applications without Manifold GUI.

1. Error CS0246 The type or namespace name 'Manifold' could not be found (are you missing a using directive or an assembly reference?)

* Missing or outdated reference

* Add reference to current EXTNET.DLL

2. Runtime 'System.BadImageFormatException' occurs

* Build target is 'x86' or 'AnyCPU' with 'Prefer 32bit' checked.

* Uncheck 'Prefer 32bit' or change target to 'x64'

3. Runtime 'Invalid API operation' occurs

* Manifold.Root does not have correct path to EXT.DLL

* Call Manifold.Root("ext.dll") with correct path to EXT.DLL (not EXTNET.DLL)

* Missing [STAThread] attribute

* Add [STAThread] attribute to Main

4. Object reference not set to an instance of an object.

* CreateDatabaseForFile returns null

* Manifold not activated, activate

Problems calling functions defined in external script (dll or cs) from Manifold SQL

1. Invalid entry point.

* The name in ENTRY declaration must be 'ClassName.MethodName' or 'Namespace.ClassName.MethodName'

2. Can't run script, no entry point type.

* Namespace name or class name is wrong in ENTRY declaration

3. Can't run script, no entry point (ClassName.WrongMethodName).

* Method name in ENTRY declaration is wrong

4. Can't run script, no entry point (Script.NonStaticExample).

* SQL9 cannot call non-static methods

* make method static

5. Can't run script, wrong number of parameters

* wrong number of parameters

6. Can't run script, type mismatch

* type mismatch

7. Object reference not set to an instance of an object.

* calling app.GetDatabaseRoot() with no project open

* check (db != null)



6,356 post(s)
#05-Aug-19 12:42

For Scripts in an internal Manifold9 component beware to change the name of the script or manually clean up the mfd_meta table of left overs. They'll mess up with the next attempt to create a script with this (default) name.


8,775 post(s)
#07-Aug-19 12:44

What sequence of steps leaves stray data in MFD_META? We'd fix that.


6,356 post(s)
#07-Aug-19 15:34

I have to check how to reproduce this. I didn't noticed when it happend but only when problems arose.


8,775 post(s)
#07-Aug-19 12:43

Great list!

We'll add something like this to the docs.

I guess what would also help is having reference examples of (a) a script that does something simple, (b) a query that calls a script function that does something simple, (c) a script add-in that does something simple, (d) a console application that uses the object model to do something simple, and (e) a normal Windows application that uses the object model to do something simple. Plus - we remember - a reference example of (f) an ADO.NET provider that, well, also does something simple.

We'll try to get it done. We are slowly working on the API doc for the query engine, so perhaps after that.

345 post(s)
#08-Aug-19 11:29

Like this? For (a) and (b).


using System;

class Script


    public static Manifold.Context Manifold;

    public static void Main()




    public static string MapFilePath()


        Manifold.Application app = Manifold.Application;

        using (Manifold.Database db = app.GetDatabaseRoot())


            if (db == null


                return "No project open";




                return MapFilePath(app, db);





    public static string MapFilePath(Manifold.Application app, Manifold.Database db)


        Manifold.PropertySet dbConnProps = app.CreatePropertySetParse(db.Connection);

        string path = dbConnProps.GetProperty("Source");

        return (path == "") ? "(New Project)" : path;




// Copy this file (Sample.cs) under Manifold ~\Shared\ folder 

// or paste the contents into script component named [Sample] in mapfile

// Copy the code in /* block comments */ into Manifold SQL command window and run with F5


-- using method MapFilePath from class Script in file Sample.cs

FUNCTION MapFilePath() VARCHAR AS SCRIPT FILE 'Sample.cs' ENTRY 'Script.MapFilePath';

SELECT MapFilePath() FROM  (VALUES (1));



-- using method MapFilePath from class Script in component [Sample]

FUNCTION MapFilePath() VARCHAR AS SCRIPT [Sample] ENTRY 'Script.MapFilePath';

SELECT MapFilePath() FROM  (VALUES (1));




8,775 post(s)
#08-Aug-19 11:38

Yes, exactly. This is great. :-)


8,958 post(s)
#08-Aug-19 12:15

As someone not 100% comfortable with C#, I disagree.

A member that calls its own overload? This is simple?


8,775 post(s)
#08-Aug-19 12:30

I meant the general idea. The implementation can always be tuned, sure. You mentioned the overload - agree that it would be best not to have it, so that whoever is reading the script has one less thing to worry about. Another thing is that Main should perhaps have an empty body and a comment saying that it is NOT called by the query, and the function that does get called should perhaps have a comment indicating that it does get called (eg, it can have this comment above it: // FUNCTION MapFilePath() VARCHAR). There will no doubt be further small improvements, etc.

Manifold User Community Use Agreement Copyright (C) 2007-2019 Manifold Software Limited. All rights reserved.