Quickly get the right .NET Framework version to work with CoreAssemblies 9.0.2.x

Plugin development is a hassle if you don’t start of with getting the correct assemblies in place before you start writing your plugin code.

Best way is to get all of that from the NuGet Manager in VS. Preferably, we all pick the latest version from the NuGet Manager and pick Microsoft.CmSdk.CoreAssemblies. With 9.0.2.x version for v9 D365 environments, you might need to be careful with the .NET Framework version too. So, here’s a quick post about that.

Let’s say you pick Microsoft.CmSdk.CoreAssemblies

coreAssemblies

While installing, you get the below error
error

This is because your VS Project might not be on or might not have the correct .NET framework installed. If you go to Project properties, you can check that.

What version do you need?

Nuget.org will tell you about the version of .NET Framework required for that assembly.
correctVersion

Getting .NET 4.6.2

You can download among the different versions of Developer Packs available across your VS versions from the link below –

Link: https://dotnet.microsoft.com/download/visual-studio-sdks?utm_source=getdotnetsdk&utm_medium=referral

Once you have the correct version, 4.6.2 in this case, you can simply select that Developer Pack and download.

Alternatively, you can also click on Install other frameworks… to get to the link (note that 4.6.2 is not yet installed for me)
installOtherFrameworks

Once you see the downloaded Setup in your browser as shown below, simply run it –
downloadedPack

It sets up like a typical Windows application. Once done, you can check your project properties and select the .NET Framework version you installed.
4.6.2NowInstalled

Re-install Assembly

And when you now try to re-install the assembly, it should be successful and you’ll get all the references you need in your plugin.
successfullyInstalled

Hope this will help! 🙂

Advertisements

Delete Async Plugin Logs if plugin succeeds, save D365 storage space

Let’s see how we can efficiently manage D365 storage without bloating the storage with data that you might not need.

In my opinion, we don’t really need to know that the background process was successful or not, we typically care for what failed.

So, from an Asynchronous plugin standpoint, the logs in D365 is registered in the System Jobs and they create a ton of System Events if you are Importing data in D365 and your Async process is on the create of such records.

sysjobs

Check your Async plugin step

  1. Now, you can preserve this storage space by choosing to Delete the Async plugin logs.
  2. In the screenshot below, you can see an option to ‘Delete AsyncOperation is StatusCode = Successful
    deletelog

In this case, the System Jobs for the will not be created, thus, saving you valuable storage space if your plugin is run frequently.

Hope this helps.