Xrm Tools v1.4.3 – Small Release, Big Quality of Life

When I released Xrm Tools v1.4, it came with major new capabilities: smarter code generation, better one-click plugin registrations, and even compile-time dependency injection.

Version 1.4.3 is not a big “headline” release—but it’s an important one. It brings refinements, fixes, and analyzers that make everyday plugin development smoother, safer, and just a bit more enjoyable. There are also small new features for those of you who need more advanced features in your plugins. Think of it as a polish release: less flashy, but a big win in quality of life.

Cleaner Code Generation, Less Maintenance

In this version, the code generation engine and almost all the templates went through several improvements to become not just faster, but also easier to use. Previously when first time a plugin or entity code was being generated, all the templates were also included in your project without you asking for it. You could find them under "CodeGenTemplates" in your project.

One of the down sides of this behavior was that if you updated Xrm Tools to a newer version and the default templates were updated, you had to delete the templates folder or files under it to regenerate the template and benefit from the new version, even if you have not customized any templates.

In the new version templates are not stored under your project by default. This will keep your project structure cleaner and more focus and every time you install a new version of Xrm Tools, you will benefit from the latest code generation templates the next time you save a file.

If you still want to customize any of the templates, you can still do it. You can do it at the entire solution level or just a single project or even a single plugin. You can read more about customizing code generation templates.

New Capabilities for Advanced Scenarios

A new release won't be as exciting without any features, right?

Entities can inherit any base class

Generated typed entities can now inherit from any base class you choose and not just the SDK's Entity class. This is very useful when you want to have base classes that abstract functionality that all your plugins can benefit from. Here is an example where the Account entity is inheriting from BaseEntity<T>

[assembly: Entity("account", BaseType = typeof(BaseEntity<Account>))]

Named Dependencies in DI

You can now differentiate between multiple providers of the same type with a simple name parameter—no more workarounds.

public class PluginBase<TPlugin> : IPlugin where TPlugin : PluginBase<TPlugin>
{
    [DependencyProvider]
    public IOrganizationService OrganizationServiceProvider 
    {
        get
        {
            if (DependencyScope<ContactCreatePlugin>.Current.TryGet<IOrganizationService>(out var service))
            {
                return service;
            }
            service = DependencyScope<ContactCreatePlugin>.Current.Require<IServiceProvider>().Get<IOrganizationServiceFactory>()
                .CreateOrganizationService(null);
            DependencyScope<ContactCreatePlugin>.Current.Set(service);
            return service;
        }
    }

    [DependencyProvider("User")]
    public IOrganizationService OrganizationUserServiceProvider
    {
        get
        {
            if (DependencyScope<ContactCreatePlugin>.Current.TryGet<IOrganizationService>(out var service))
            {
                return service;
            }
            service = DependencyScope<ContactCreatePlugin>.Current.Require<IServiceProvider>().Get<IOrganizationServiceFactory>()
                .CreateOrganizationService(null);
            DependencyScope<ContactCreatePlugin>.Current.Set(service);
            return service;
        }
    }

    // Rest of the code removed for brevity.
}

In your plugin class you can choose any of the services you need.

[Plugin]
[Step("Create", "contact", "firstname,lastname", Stages.PreOperation, ExecutionMode.Synchronous)]
public partial class ContactCreatePlugin : PluginBase<ContactCreatePlugin>, IPlugin
{
    // Requiring a named dependency sirectly in the plugin:
    [Dependency]
    public IOrganizationService UserOrganizationService
    {
        get => DependencyScope<ContactCreatePlugin>.Current.Require<SomeService>("User");
    }

    
    [Dependency]
    public ISomeService MyService
    {
        get => DependencyScope<ContactCreatePlugin>.Current.Require<SomeService>();
    }

    // Rest of the code removed for brevity
}

public class SomeService: ISomeService
{
    // Requiring a named dependency in any other type:
    [Dependency("User")]
    IOrganizationService UserOrganizationService { get; set; }

    // Requiring a dependency with just the type.
    public SomeService(IOrganizationService organizationService)
    {
    ...
    }
}

You don't need to wait until run time to observe the behavior. Just look at the code behind of your plugin class to see the result.

Sharper IntelliSense and Colorization

One small but interesting feature of Xrm Tools is its attribute name colorization when you type filtering attributes in [Step("message", "entity", "attribute1,attribute2,.."] and [Image]. Each attribute name is displayed in blue and the comma between them is red. You now have the same colorization in the named arguments and in [Entity] attribute too.

Code-completion when you type registration attributes and code generation has become faster than before due to several small improvements. Error messages give you more information about what's wrong and what you need to do to solve it. Confirmations are clearer and give you more clarity about what will happen next.

I also fixed some subtle but frustrating bugs—for example, extra spaces in [Step] or [Image] attributes no longer break registration.

You can download Xrm Tools v1.4.3 today from the Visual Studio Marketplace or directly from your Visual Studio's Extensions Tab. Check out the full details in the release notes.