Archaeology – Finding CRM SDK History

When I have just created a new feature in my tools – I get a few error reports. Every time.
Why is that? Mostly because users have an older version of Dataverse (or XRM/CRM).
This is why I add updates, fixing one problem after another. Finding them the hard way.

I tried a few times – no, many times – to look for the information I need:

Dataverse Metadata Properties History

I use the latest and greatest version of the SDK library, so why is that a problem?
The SDK and the database need to be versions in sync.
I want my tools to support every version, from Dynamics CRM 2013; to the newest release that we can find.

The code now needs to handle the database version. When the user is connected to CRM 2015 Update 1.1 – which features should be supported in the tool? And all other versions…

I never found a place with a Feature/Version/Metadata matrix.

Ask to the community

I asked on Twitter. Crickets. 🦗

I asked the Microsoft gurus. Got a response from one of the best gurus. He says there is no easy way to see this. He has a few ideas and tips for my code.

I got one tip about looking for this class: FeatureVersionMinimums – that’s a great idea! But it is not really what I need… It talks about features and versions, but I still have to match the features to the metadata properties. And I don’t see that.
I also know working with virtual entities is “new”, but I don’t see anything about virtuals… I am sure it may be me just missing it, but anyway – this is hard too…
This class is also from the new Dataverse SDK, and we work with classic CRM SDK. It should be somewhere but have not found that either. 😔

Well, in my case, it’s hard to fix this. I want to load all entities with some properties, and then when I look specifically at one entity, then I can load all properties.

Why? Don’t load too much, save the time it takes.

What’s my issue?

Loading one entity with all properties is no problem, these will always be loaded properly, for all versions.

Loading all entities with some properties is the problem. I want to say, “I want properties A, B, and C for all entities“. If property C does not exist in the database, an error is thrown. So I need to know that, to not even try in that version.

Loading all entities with all properties is not possible, what I know. You can use a Retrieve request, but no RetrieveMultiple requests. And if you still can – it will take too long time for the users. Something from 5 seconds till eternally… or at least it will arrive in the fullness of time.

What I need

Ok, so I need to load all entities with some properties, and “some” based on the version they are connected to.

I create those properties I needed. And then I shall remove these properties that will explode the code. See list of properties:

    public static string[] entityProperties = {

See how I remove the method, since some are “new” in the database:

    private static string[] GetEntityDetailsForVersion(string[] entitiesoptions, int orgMajorVer, int orgMinorVer)
        var result = entitiesoptions.ToList();
        if (orgMajorVer < 7 || (orgMajorVer == 7 && orgMinorVer < 1))
        if (orgMajorVer < 8 || (orgMajorVer == 8 && orgMinorVer < 2))
        if (orgMajorVer < 9)
        return result.ToArray();

This works.

But how did I find that Feature/Version/Metadata matrix?

Looking for the matrix

If you look at the definitions of the EntityMetadata class, you see the Order of some properties, and these look like the version where they were added…

Well DataMember(Order = 90) is not used as an introduced version… but show up in which order these have. I guess MS only used this to “remember” when they were added, but not always.

Finding the tool

Then a dev-friend out there finally found my problem – and Betim reached out to me:

Even Joe was in the right direction:

Well, that did not get me all the way.
Actually, not anywhere.
I need more help.

But Betim started to work, and he has an idea…

You may call him Profesor “Betim” Baltazar.
(If you are from the ’70s, you have seen Baltazar – if you’re not, poor you!)

After two days, he came back with A Tool:


This tool is quite simple – but smart 🤓

Run the tool and add the name of NuGet Package ID, the dll file, and the local path.

Example call:
PackageHistoryBuilder.exe -p Microsoft.CrmSdk.CoreAssemblies -a Microsoft.Xrm.Sdk.dll -o C:\Dev\GitHub\SDK-History

The tool will download all versions, oldest first, one at a time.

For each version, the dll is decompiled, then added/updated to the local git repository, and committed.

Then it takes the next version and does it all again…

Finding the matrix

It’s not easy to read the “when introduced in version…” in the files, in the git repository, the commits – but it is a way to see it inside Visual Studio!

I open the project that has been created by the tool.

Just follow the folders with the namespace we know for the metadata class we need.

In this case:

Microsoft.Xrm.Sdk.Metadata and find the EntityMetadata.cs

For instance, I look for the property IsLogicalEntity.

I see this DataMember(Order = 82), but I don’t trust it entirely…

I can also look at the history; it says “5 changes”.

We don’t know when, but we see in which version of the NuGet package… Betim added the NuGet package version to the Commit Descriptions – there is the answer!

The first (oldest) version – is when they were introduced.

If your new feature uses this property, you still have to remove this property if version is <8.2.*.

Use the tool for more

Of course, I had to try this on the FetchXML Builder on NuGet!

Run it with commands values:
-p Cinteros.Xrm.FetchXMLBuilder -a Rappen.XTB.FXB.dll -o C:\Dev\GitHub\FXB-History

I opened the project, can see for example that ApplySettings was created at version 1.2020.12.2, and updated a few times this year.

If you like code – this is really good!

Try it!

We were recently in Rome, Italy

When we are in Rome, we see historical events everywhere. Just look down, and we see the releases they published to us all for 500, 1000, or 2000 years ago.

With the code that we have today, it’s not as easy to find the versions from the ground, and we can’t carbon-14 dating an SDK.

There are no clear docs, there is no matrix, it’s hard to find even in open source.

But there is a new archaeology tool…

Carbon-14 Dating Tool
by Profesor Baltazar.

Colosseum with Jonas Rapp, Cassiopeia, Lukas, and Rasmus.

I really like to build tools that will work forever. Don’t just work today, and maybe tomorrow.
But then I need archaeology to see how they built it before, to know what was right, and what was wrong.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.