Getting the wrong NewFamilyInstance override

[john.fechtelRZ8SW]

Hi all,

I've done some searching here without luck on the specific issue I'm running into, so I thought I'd turn here for help.

I'm trying to instance a structural column via API. I used a variation of the NewFamilyInstance() method in Autodesk.Revit.Creation.Document (NewFamilyInstance Method (XYZ, FamilySymbol, Level, StructuralType)). Everything worked great when I built the add-in locally, and all the columns came in correctly. I targeted Revit 2024. However, when packaging the add-in and getting it to one of our users in Revit 2023, they received a "Method not found" error. It was somewhat truncated by the error task dialog, but it claimed it could not find a method with the same signature as above (XYZ, FamilySymbol, Level, StructuralType).

I was confused at first, but then noticed that the namespace of the function it could not find was in Autodesk.Revit.Creation.ItemFactoryBase, not in Autodesk.Revit.Creation.Document. My read of the API docs is that this is correct -- but Document apparently inherits from ItemFactoryBase and then adds its own overrides. But for some reason, my user's instance of the add-in is just not able to find it.

// "doc" here is of type Autodesk.Revit.DB.Document
FamilyInstance column = doc.Create.NewFamilyInstance(location, familySymbol, baseLevel, StructuralType.Column);

To make matters more confusing, my IDE (Visual Studio Professional 2022, with ReSharper) seems to think this override of NewFamilyInstance is actually a member of ItemFactoryBase:

I've tried a variety of methods to force the correct override here but without much success. Has anyone come up against this before, and is there a solution?

[jeremy_tammik]

What is the exact data type declaration for your variables location, familySymbol and baseLevel?

Is this the opverload you are after?

• https://www.revitapidocs.com/2022/9cdda5d9-85f7-4445-1e84-5fda77d41f74.htm
• Autodesk.Revit.Creation.Document.NewFamilyInstance (XYZ, FamilySymbol, Level, StructuralType)

In that case, it may help clarify things to ensure that your argument types really are XYZ, FamilySymbol and Level, respectively.

As opposed to `var`, for instance.

[john.fechtelRZ8SW]

Hi Jeremy,

I should have included more context. Here is a portion of the function:

 public bool MakeColumn(Document doc, Family inFamily, MMStructuralElement element)
        {
            var familySymbol = doc.GetElement(inFamily.GetFamilySymbolIds().First()) as FamilySymbol;

            Autodesk.Revit.DB.Level baseLevel;
            GetLevelByName(doc, element.BaseLevel.LevelName, out baseLevel);

            Autodesk.Revit.DB.Level topLevel;
            GetLevelByName(doc, element.TopLevel.LevelName, out topLevel);

            if (baseLevel == null || topLevel == null || familySymbol == null)
            {
                Console.WriteLine("Error in MakeColumn on element " + element.ProductId);
                return false;
            }

            if (!familySymbol.IsActive)
            {
                familySymbol.Activate();
            }

            XYZ location = Util.Point3dToXYZ(element.Coordinates[0], 2, true);

            FamilyInstance column = doc.Create.NewFamilyInstance(location, familySymbol, baseLevel, StructuralType.Column);
    }

- location is an Autodesk.Revit.DB.XYZ

- familySymbol is being declared as a var ... as an Autodesk.Revit.DB.FamilySymbol

- baseLevel is declared as an Autodesk.Revit.DB.Level

You are correct, that is the overload I'm after. 

[Kennan.Chen · Accepted solution]

In Revit 2024, the method you are using is defined in the Autodesk.Revit.Creation.ItemFactoryBase class, the Autodesk.Revit.Creation.Document class just inherits the method from Autodesk.Revit.Creation.ItemFactoryBase class, which means  Autodesk.Revit.Creation.ItemFactoryBase.NewFamilyInstance() is invoked underneath (the C# compiler generated code).

While in older versions of Revit, the "same" method is defined directly in Autodesk.Revit.Creation.Document class.

The use of the method looks the same but they result in different compiled code when linked with different RevitAPI.dll, which means the dll compiled against Revit 2024 cannot be used in Revit 2023 if you use this method.

It is an API compatibility issue, so the common solution is to build different dlls targeting to different versions of Revit.

[Kennan.Chen]

To show the problem in a clear way, I created a simple plugin to use this method and compiled against different versions of Revit and analyzed the IL code C# compiler generated. 

C# source code:

IL code compiled against Revit 2024:

IL code compiled against Revit 2023:

[Kennan.Chen]

BTW, similar API changes is rarely seen but indeed happened before.

I have this weird code in my project:

[Kennan.Chen]

Another hacky solution might be using Reflection to force invoke the method from Autodesk.Revit.Creation.Document class.

I modified the demo source code:

Note that the above code was written by hand and I had not done a single test.

[Kennan.Chen]

If Reflection is acceptable, you can also use "dynamic" to call this method in a more simple way.

By using "dynamic", you choose not to make the C# compiler aware of which method you are calling at compile time, which can also make the generated IL code to call this method from Autodesk.Revit.Creation.Document class.

Same as above, test it yourself!

[john.fechtelRZ8SW]

Thanks, Kennan! I hadn't found the 2024 changelog but this puts the pieces together for me. Much appreciated.

[jeremy_tammik]

Many thanks to Kennan for the very thorough explanation!

I added a link to it in the blog for wider distribution and greater visibility:

https://thebuildingcoder.typepad.com/blog/2023/05/dark-icons-newfamilyinstance-and-ai-news.html#3

Cheers, 

Jeremy