如何从ASP.NET MVC网站中生成可下载的c＃类？

Question

I'm sure this is a very weird requirement, but here goes.

We have some customer configuration code that is represented by C# classes that we compile into a class library. Creating these configuration classes is currently monkey work that I'd like to assign to someone other than a developer. We're therefore building a "Configurator" website that a business analyst can use to generate valid C# classes by filling in a form with the relevant options selected.

What is the best way to generate a C# class from a template in an MVC website? Note that I'm not talking here about dynamically generating and executing a class at runtime: we're essentially generating a text file that just happens to contain C# code that will be included in a totally different project.

This is proving to be a very difficult topic to google properly! Options that have come up so far...

• just use a tokenized text file and replace values using String.Format
• somehow use Razor as a templating engine (but not sure how, and it's not html we're generating)
• somehow use T4 templates (at least I know it's used to generate C#, but not sure how to execute at runtime)

Any ideas on how best to approach this?

As requested, here's an example of the output class/file. Values in here override values set in a base class with customer-specific labels, validation, etc. This is how we customise our product for customers.

public class AreaRiskTemplate: AreaRiskTemplateBase
{
    public override string EntityName { get { return "risk"; } }
    public override string EntityNamePlural { get { return "risks"; } }
    public override string EntityNameArticle { get { return "a"; } }
    public override string CGovItemRefPrefix { get { return "R"; } }
    public override void SetFieldDefinitions()
    {

        FieldDefinitions.Level1.IsImplemented = true;
        FieldDefinitions.Level1.Label = "Category";
        FieldDefinitions.Level1.IsVisibleInGrid = true;

        FieldDefinitions.Level2.IsImplemented = true;
        FieldDefinitions.Level2.Label = "Team";
        FieldDefinitions.Level2.IsVisibleInGrid = true;

        FieldDefinitions.Description.IsImplemented = true;
        FieldDefinitions.Description.Label = "Description";
        FieldDefinitions.Description.IsVisibleInGrid = true;

    }
    public override ModelStateDictionary Validate()
    {
        var msd = new ModelStateDictionary();
        // add template-specific validation here
        msd.Merge(base.Validate());
        return msd;
    }
    public override List<string> Level1Options
    {
        get
        {
            return new List<string>
                {
                    "Organisational",
                    "Financial",
                    "Operational",
                    "External",
            "IT"
                };
        }
    }
}

Update: currently investigating T4 templates at http://msdn.microsoft.com/en-us/library/ee844259(v=vs.100).aspx (thanks to comments below). Looks promising.

Answer 1

I suggest avoiding the website, and instead simply going with CodeSmith. You can design CodeSmith scripts so that it will ask for information and then generate the required code. Seems like a lot less work, although you do have to buy CodeSmith.

Answer 2

The method for doing this with the least overhead would be to use Microsoft's built in CodeDOM API . It allows you to build and manipulate CLR code documents with cross-language compatible Document Object Model.

The only downside to this approach is that it is not immediately obvious how to implement some language specific features. An example is C# readonly fields, because they are not available in every CLR language, but only in C#. The solution for this particular intricacy is to use a CodeSnippet and insert the manual code as a string. Other more complex mismatch issues can be mitigated by integrating the CodeDOM with a templating engine. Oleg Sych wrote a useful article on integrating CodeDOM with the T4 templating engine . I prefer this kind of approach to a pure text-generation approach, because a strongly typed document object model is less error prone than pure text.

In addition, if you ever do make the move to wanting the output code to be compiled, this is also supported by the CodeDOM API.

If this is a practice that you think you may use a lot, you may want to wrap some common DOM manipulation functionality into fluent method calls by using the builder pattern . I've built a personal library that uses this approach and it has been very successful in increasing my productivity via code generation.