Considerations for Custom Data Generators

You can extend the data generation capabilities of Visual Studio by creating custom data generators. If there is a business rule that the standard data generators cannot satisfy, you can create a custom data generator. For more information, see Generating Test Data for Databases by Using Data Generators.

Before you create a custom data generator, you should consider the following issues.

When you create a custom data generator, you can control the name that appears in the user interface for that custom data generator. You should avoid giving the same name to multiple data generators. You should also avoid giving your generator the same name as any of the built-in data generators.

Naming When You Use a Declarative API

If you do not declare a designer for use with your custom data generator, the class name of the data generator appears as the display name when the DefaultDistributionDesigner is created.

To specify the name for the generator that appears in the user interface for the custom data generator, you can apply the following attribute to your custom data generator class:

[System.ComponentModel.DisplayName("YourGeneratorName")]

Naming When You Use a Base API

If you create a custom designer, the value that is returned by the Name property of that designer appears in the user interface for the custom data generator. If you derive your custom designer from DefaultGeneratorDesigner, the DisplayName attribute is used. If you instead derive your custom designer from IGeneratorDesigner, the DisplayName attribute is ignored.

To specify the DisplayName attribute for your data generator, you must add the following attribute to your data generator class:

[System.ComponentModel.DisplayName("YourGeneratorName")]

You can assign a custom data generator as the default data generator for a SQL data type. For more information, see How to: Change the Default Generator for a Column Type.

When you assign a custom generator as the default for a SQL data type, the following restrictions apply:

  • You can assign a custom data generator to any SQL data type that cannot have a unique constraint. For example, you can assign a custom data generator to the Image data type.

  • You can assign a custom data generator that has no filter attributes to any SQL data type.

  • You can assign a custom data generator that does have filter attributes to a SQL data type that can have a unique constraint only if the custom data generator can produce unique values. To designate this kind of generator, apply the following attribute to the custom data generator class:

    <GeneratorStyles(DesignerStyles:=GeneratorDesignerStyles.CanProduceUniqueValues)> _
    Public Class TestGenerator
        Inherits Generator
    
    End Class
    

    [GeneratorStyles(DesignerStyles = GeneratorDesignerStyles.CanProduceUniqueValues)]
    public class TestGenerator:Generator
    {
    }
    

By default, a custom data generator will use the default designer.

If you want to use a custom designer with your custom data generator, you must specify an additional attribute on the custom data generator class:

[Generator(typeof(CustomDesignerType))]
public class TestGenerator:Generator
{
}

If you mark one or more input properties for your custom data generator with the AutoAssignedInput attribute, you should also make those properties read-only. The property that has an auto-assigned input needs to have a setter but should have the ReadOnly property set to true on its InputDescriptor.

Most properties that you mark as auto-assigned will have their values reset when you open the data generation plan. For example, the Collation, Data Type, MaxLength, Nullable, and RowsToGenerate properties are all reset when they are marked as auto-assigned. By contrast, the Unique, Seed, and PercentageNull properties are not reset when they are marked as auto-assigned.

By making the properties whose values will be reset read-only, you will help avoid confusing the users of your custom data generator.

Community Additions

ADD
Show: