Archive

Archive for June, 2014

Dissecting the ASP.NET Identity Producer – Part 3

June 24, 2014 Leave a comment

If you’ve read our two previous posts (Part 1 and Part 2), you should know how to create a CodeFluent Entities custom producer. Now you may ask yourself how to integrate it into Microsoft Visual Studio and how to debug it.

Visual Studio Integration

Fist, to declare the producer, we have to create or edit the xml file located in “%APPDATA%\CodeFluent.Modeler.Design”.

<codeFluent.Modeler> 
    <producerDescriptors> 
      <producerDescriptor name="AspNetIdentity" displayName="Asp.Net Identity" category="Security" typeName="SoftFluent.AspNetIdentity.AspNetIdentityProducer, SoftFluent.AspNetIdentity" /> 
    </producerDescriptors> 
</codeFluent.Modeler>

Then, open Visual Studio and try to add a new producer:

AspNet Identity Producer Configuration

The property grid displays properties exposed by the producer:

public class AspNetIdentityProducer : BaseProducer
{
    [DefaultValue(false)]
    [Category("Source Production")]
    [DisplayName("Must Implement IQueryableUserStore")]
    [Description("Determines if the IQueryableUserStore interface must be implemented. WARNING: this is not a real IQueryable data source. This can be used to load all users.")]
    [ModelLevel(ModelLevel.Normal)]
    public bool MustImplementQueryableUserStore
    {
        get
        {
            return XmlUtilities.GetAttribute(Element, "implementQueryableUserStore", false);
        }
        set
        {
            XmlUtilities.SetAttribute(Element, "implementQueryableUserStore", value.ToString().ToLowerInvariant());
        }
    }
}

As you can see, parameter values are stored in the XML file. Do not create automatic properties, it won’t work!

We show that we can create custom attributes, but it can be very useful to display them in the property grid:

Custom Producer Property Grid

The BaseProducer implements the IDescribable interface, so we have to override the BuildDescriptors method.

protected override void BuildDescriptors(IList<Descriptor> descriptors)
{
    if (descriptors == null)
        return;

    descriptors.Add(BuildDescriptor(
        name: "entityType",
        typeName: typeof(EntityType).AssemblyQualifiedName,
        defaultValue: "None",
        displayName: "Entity Type",
        description: "ASP.NET Identity Entity Type.",
        targets: NodeType.Entity));

    descriptors.Add(BuildDescriptor(
        name: "propertyType",
        typeName: typeof(PropertyType).AssemblyQualifiedName,
        defaultValue: "None",
        displayName: "Property Type",
        description: "ASP.NET Identity Property Type.",
        targets: NodeType.Property));

    descriptors.Add(BuildDescriptor(
        name: "methodType",
        typeName: typeof(MethodType).AssemblyQualifiedName,
        defaultValue: "None",
        displayName: "Method Type",
        description: "ASP.NET Identity Method Type.",
        targets: NodeType.Method));

    base.BuildDescriptors(descriptors);
}

Thanks to the target, descriptors are shown only when needed. This allow to not pollute the property grid with meaningless descriptors. Note that the same descriptor can have multiple targets. Combine them with OR (“|” in C#). For example :

 NodeType.Property | NodeType.Method.

Because creating identity entities is boring, we add a form to create them automatically:

AspNet Identity Form

The two issues are:

  • How to open this form?
  • How to edit the model?

To answer the first one, CodeFluent Entities uses another interface: IDesignProducer. It allows to add menu items at the producer level.

Create Identity Entities

Once again, the BaseProducer already implements this interface so we have to override two methods: EnumerateMenus and ExecuteMenu.

protected override void BuildMenus(IList<IDesignProducerMenu> menus)
{
    base.BuildMenus(menus);

    if (menus == null)
        return;

    menus.Add(new BaseDesignMenu("Create Identity Entities", true));
}

protected override bool ExecuteMenu(IServiceProvider serviceProvider, IDictionary<string, object> context, int index)
{
    Project project = context["Project"] as Project;
    if (project == null)
        return false;

    switch (index)
    {
        case 0:
            var form = new ConfigurationForm(project);
            form.ShowDialog();
            return true;
    }

    return base.ExecuteMenu(serviceProvider, context, index);
}

Now we open the form, we need to create entities. You can see that we have access to the Project object, so just use it. Here’s the code to create a new entity:

Entity entity = new Entity();
entity.Name = entityName;
entity.Namespace = @namespace;
entity.SetAttributeValue("", "entityType", Constants.NamespaceUri, entityType);
project.Entities.Add(entity);

When you edit the model, CodeFluent Entities automatically update surfaces.

How to debug your custom producer?

One way is to start Visual Studio as administrator, so you can use the post build event to copy the generated DLL to the CodeFluent Entities directory.

xcopy “$(TargetPath)” “C:\Program Files (x86)\SoftFluent\CodeFluent\Modeler” /Y

Then you can configure the debugger to start an external program:

Program: C:\Program Files (x86)\SoftFluent\CodeFluent\Modeler\CodeFluent.Build4.exe
Command line arguments:

Producer Debugger Configuration
Another solution is to add System.Diagnostics.Debugger.Launch and System.Diagnostics.Debugger.Break in your code. This can be useful in templates.

Now you can start the debug (F5) and set breakpoints into your producer.

To conclude, this producer is quite simple, but it shows:

  • How to extends the modeler,
  • How to edit the model at design time,
  • How to generate code with Templates and CodeDom.

This is a great start when you want to write a producer. If you need more information, feel free to ask your question on the forums.

The full source code is available on our GitHub repository.

Happy producing!

The R&D Team.

Dissecting the ASP.NET Identity Producer – Part 2

June 23, 2014 Leave a comment

In our last post, we talked about some generalities regarding writing a custom producer.
Today we’ll see how does the ASP.NET Identity Producer generate C# code. Let’s remind that the full source code is available on our GitHub repository.

First and before producing code, we have to find the Role and the User entities in the model.

Do you remember the NamespaceUri? It allows you to add custom attributes in the xml file which represents the model.

<cf:entity name="User" d2p1:entityType="User" xmlns:d2p1=
"http://www.softfluent.com/codefluent/producers.aspNetIdentityProducer/2014/1"> 

</cf:entity> 

We add the entityType attribute to the entity. Xml Namespace are useful to avoid naming conflict between producers.

To find the User entity we can do the following, create an enumeration named “EntityType”:

public enum EntityType 
{ 
    None, 
    User, 
    Role, 
    UserRole, 
    Claim, 
    Login 
} 

Then, read the attribute value in the following way:

foreach (var entity in project.Entities) 
{ 
    if (entity.GetAttributeValue("entityType", 
               Constants.NamespaceUri, EntityType.None) == EntityType.User) 
    { 
        return entity; 
    } 
} 

The Produce method is a blank method so you can do what you want. When the output file is simple (with no complex logic), the easiest way is to use a template. When the logic is more complex you may want to use other mechanism such as CodeDom.

In the ASP.NET Identity producer we decided to use two templates: one for UserRole and the other one for RoleStore. CodeFluent Runtime already provides everything you need to use template. We’ll use here the SimpleTemplateProducer abstract class to simplify templates mechanisms (loading, parsing, processing). This producer takes directly the template from the resources of the producer, so you’ll have only one DLL to release. Of course the template has access to the producer instance, and so to its properties and methods.

AspNet Identity Producer

Tips: Keep the maximum of the logic in the producer, your templates will be much simpler to read

Here’s an extract from the template:

public System.Threading.Tasks.Task CreateAsync([%=TemplateProducer.IdentityRole.Entity.ClrFullTypeName%] role)
{
	if(role == null)
		throw new System.ArgumentNullException("role");

    return System.Threading.Tasks.Task.FromResult(role.Save());
}

And the code to run the template

public class RoleStoreProducer : SimpleTemplateProducer
{
    public IdentityRole IdentityRole { get; set; }
    
    protected override string DefaultNamespace
    {
        get { return Producer.Project.DefaultNamespace + Producer.WebNamespaceSuffix + ".Security"; }
    }

    protected override string DefaultTypeName
    {
        get { return "RoleStore"; }
    }

    protected override Template CreateTemplate()
    {
        var template = base.CreateTemplate();

        template.AddReferenceDirective(typeof(CodeDomBaseProducer));
        template.AddReferenceDirective(typeof(UserStoreProducer));

        return template;
    }

    public override string TargetPath
    {
        get
        {
            string path = ConvertUtilities.Nullify(XmlUtilities.GetAttribute(Producer.Element, ConvertUtilities.Camel(this.TargetName) + "TargetPath", (string)null), true);
            if (path == null)
                return BaseType.GetFilePath(Producer.TargetBaseNamespace, TypeName, Namespace, Producer.FullTargetDirectory, null);

            return Producer.GetFullRelativeDirectoryPath(path);
        }
    }
}

Note: We omit some code to make this implementation simpler

The template file is found based on the DefaultTypeName, so we don’t need to specify anything else. Instantiating the RoleStoreProducer and calling its Produce method will load the template from resources, and run it.

To implement the IUser and IRole interfaces, we need to edit the code generated by the CodeDom Producer. To do so, the way to go is to write a CodeDomSubProducer. But you can also get the instance of the BOM producer and register to the CodeDomProduction event:

var producer = project.Producers.GetProducerInstance<CodeDomProducer>();
if (producer == null)
    return;
producer.CodeDomProduction += CodeDomProducer_CodeDomProduction;

We can now handle the event and add the interface implementation:

private void CodeDomProducer_CodeDomProduction(object sender, CodeDomProductionEventArgs e)
{
    if (e.EventType == CodeDomProductionEventType.EntityCommitting)
    {
        CodeCompileUnit unit = e.Argument as CodeCompileUnit;
        if (unit == null)
            return;

        foreach (CodeNamespace ns in unit.Namespaces)
        {
            foreach (CodeTypeDeclaration typeDeclaration in ns.Types)
            {
                BaseType type = UserData.GetBaseType(typeDeclaration);
                if (type.GetAttributeValue("entityType", NamespaceUri, EntityType.None) == EntityType.User)
                {
                    // Implements IUser<TKey> & IUser
                    if (_identityUser.MustImplementGenericInterface)
                    {
                        ImplementIUser(typeDeclaration, true);
                    }

                    ImplementIUser(typeDeclaration, false);
                }
            }
        }
    }
}

private void ImplementIUser(CodeTypeDeclaration typeDeclaration, bool generic)
{
    string keyTypeName = generic ? _identityUser.KeyTypeName : typeof(string).FullName;
    var iuserCodeTypeReference = new CodeTypeReference("Microsoft.AspNet.Identity.IUser");
    var iuserGenericCodeTypeReference = new CodeTypeReference("Microsoft.AspNet.Identity.IUser");
    iuserGenericCodeTypeReference.TypeArguments.Add(keyTypeName);
    if (generic)
    {
        iuserCodeTypeReference.TypeArguments.Add(keyTypeName);
    }

    typeDeclaration.BaseTypes.Add(iuserCodeTypeReference);

    CodeMemberProperty idProperty = new CodeMemberProperty();
    idProperty.PrivateImplementationType = iuserGenericCodeTypeReference;
    idProperty.Type = new CodeTypeReference(keyTypeName);
    idProperty.Name = "Id";
    idProperty.HasSet = false;
    idProperty.GetStatements.Add(new CodeMethodReturnStatement(new CodePropertyReferenceExpression(new CodeThisReferenceExpression(), generic ? _identityUser.KeyPropertyName : "EntityKey")));
    typeDeclaration.Members.Add(idProperty);
}

The CodeDom can be traversed to find class declarations. The CodeDom producer annotates CodeDom elements, so we can get model concept from the CodeDom element by using UserData class. In this case we know if a class corresponds to the User entity by using UserData.GetBaseEntity.

In the last part, we’ll explain how to integrate this producer in Visual Studio and how to debug it.

The R&D Team.

Dissecting the ASP.NET Identity Producer – Part 1

June 19, 2014 Leave a comment

A few weeks ago we release a new producer: ASP.NET Identity Producer. Let’s see how we wrote it.

The main idea of the article is not to explain every line of code, but to explain the main concepts of the producer.

As a reminder the full source code of the producer is available on our GitHub repository.

What is a producer?

The main goal of a producer is to translate the model into code of any kind: C#, VB.NET, SQL, plain text. But a producer can generate what it want, or maybe don’t generate anything. It can also interact with database or file system.  You can do what you want with a producer.

First you have to implement the interface IProducer.

public interface IProducer 
{ 
    event Producer.OnProductionEventHandler Production; 
    void Initialize(Project project, Producer producer); 
    void Produce(); 
    void Terminate(); 
}

The build process uses producer this way:

Build Process

In the Initialize method you should make required initializations. Often this method simply copy the Project parameter to a field, so it can be used in the Produce method. The project object contains all information about the model (Entities, Views, Tables, etc.).

In the Produce method, you have to generate the output. This can be a complex output as the BOM or a much simpler as a summary of the project or maybe no output.
The Terminate method allows to clean resources.

This is the theory. In practice producers often inherit from a base class which already implement the IProducer interface:

  • BaseProducer
  • UIProducer
  • CodeDomBaseProducer
  • TemplateProducer
  • any existing producer

The basic code of the ASP.NET Identity producer is:

public class AspNetIdentityProducer : BaseProducer
{
    protected override string NamespaceUri
    {
        get { return Constants.NamespaceUri; }
    }

    public Version TargetFrameworkVersion
    {
        get
        {
            return new Version(4, 5);
        }
    }

    public override void Initialize(Project project, Producer producer)
    {
        base.Initialize(project, producer);
    }

    public override void Produce()
    {
    }
}

public class Constants
{
    public const string NamespaceUri = "http://www.softfluent.com/codefluent/producers.aspNetIdentityProducer/2014/1";
}

We introduce two additional notions: TargetFrameworkVersion and NamespaceUri.

The first one is the Framework version needed by the generated code. The second one is the NamespaceUri used to store custom xml attributes. You should create a unique name.

How to deploy and use the producer?

A producer is composed of one DLL that contains a class which implements IProducer. To deploy the producer, you must copy the DLL to the CodeFluent Entities directory (by default: C:\Program Files (x86)\SoftFluent\CodeFluent\Modeler). To use it, you have to declare it in the model file:

  <cf:producer name="Asp.Net Identity" typeName="CodeFluent.Producers.AspNetIdentity.AspNetIdentityProducer, CodeFluent.Producers.AspNetIdentity">
    <cf:configuration targetDirectory="..\Samples" implementQueryableUserStore="true" implementQueryableRoleStore="true" cfx:targetProjectLayout="Update" />
  </cf:producer>

The next post will cover how does the producer generate the code. In the meantime you can download the full code on our GitHub repository.

Let us know what you think!

The R&D Team.

Template Engine and Extensibility

June 11, 2014 Leave a comment

A few time ago, we presented the CodeFluent Runtime’s Template Engine. Today we’ll see how to extend it to change a little bit its syntax and to add custom keywords.

Here is a simple template:

<% var now = new Date(); %>
Hello <%= Name %>!
It's <%= now.toDateString() %>
Cheers,
<%= CurrentUser %>

To use the standard Template Engine, we use this following code:

Template template = new Template();

template.LoadText(templateText, "Name", "CurrentUser");
string templateResult = template.Run(new Dictionary<string, object>
{
     { "Name", "Jone Doe" }, 
     { "CurrentUser", Environment.UserName }
}); 

Console.WriteLine(templateResult);

This will output:

Hello Jone Doe!
It’s Thu Mar 6 2014
Cheers,
The R&D Team

After some customization, the template will be more readable:

Hello {{Name}}!
It's {{Now:yyyy/MM/dd}}
Cheers,
{{CurrentUser}}

Before extending the template engine we have to understand how it works. The engine is composed of 4 classes:

  • Template: contains the configuration such as delimitation tokens and methods to load and run the template
  • ParsedTemplate: contains parameters and code or text blocks extracted while parsing the template
  • ParsedBlock / CodeBlock: contains block text and a method to transform it into JavaScript code
  • Output: contains methods to write into the output file

Let’s use the first sample to understand. First, it will parse the template and extract the following blocks:

  • CodeBlock: var now = new Date();
  • TextBlock: Hello
  • CodeBlock: = Name
  • TextBlock: It’s
  • CodeBlock: = now.toDateString()

Then it will transform blocks into JavaScript instructions. These Text blocks are transformed into “Output.Write(block content)”. When code block starts with “=” it will generate “Output.Write(parameterName)”, otherwise the JavaScript is written as is.

The generated JavaScript is:

ActiveXObject=null;
function __run(Output, Name, CurrentUser) {
 var now = new Date(); 
Output.WriteBlock(1);
Output.Write( Name );
Output.WriteBlock(3);
Output.Write( now.toDateString() );
Output.WriteBlock(5);
Output.Write( CurrentUser );
}

Now we understand the template engine, let’s extend it.
We would like to change to {{ and }}. To do so, we extend the Template class.

public class CustomTemplate : Template
{
    public CustomTemplate()
    {
        StartToken = "{{";
        EndToken = "}}";
    }
}

We also need to create a new CodeBlock to parse the content and write the appropriate JavaScript code:

public class CustomCodeBlock : CodeBlock
{
    public string Format { get; private set; }
    public string ArgumentName { get; private set; }

    public CustomCodeBlock(string code, int creationIndex)
        : base(code, creationIndex)
    {
        Parse(code);
    }

    private void Parse(string text)
    {
        if (text == null || text.StartsWith("="))
            return;

        string argumentName = text;
        string format = null;
        int formatIndex = text.IndexOf(":");
        if (formatIndex > 0)
        {
            argumentName = text.Substring(0, formatIndex);
            format = text.Substring(formatIndex + 1);
        }

        ArgumentName = argumentName;
        Format = format;
    }

    public override void BuildSourceCode(StringBuilder source, ParsedTemplate parsed)
    {
        if(!string.IsNullOrEmpty(ArgumentName))
        {
            source.Append(parsed.Template.OutputItemName);
            if (string.IsNullOrEmpty(Format))
            {
                source.Append(".Write(");
                source.Append(ArgumentName);
                source.Append(");");
            }
            else
            {
                source.Append(".WriteFormatted(");
                source.Append(ArgumentName);
                source.Append(", \"");
                source.Append(Format);
                source.Append("\");");
            }

            return;
        }

        base.BuildSourceCode(source, parsed);
    }
}

Now we have to create the WriteFormatted function in the Output class:

[ComVisible(true)] // Needed to be used by JavaScript code
public class CustomOutput : Output
{
    public CustomOutput(ParsedTemplate template, TextWriter writer)
        : base(template, writer)
    {

    }

    public void WriteFormatted(object value, string format)
    {
        if (string.IsNullOrWhiteSpace(format))
        {
            Write(string.Format("{0}", value));
        }
        else
        {
            string formattedValue = string.Format("{0:" + format + "}", value);
            Write(formattedValue);
        }
    }
}

Finally let’s say to the Template to use our custom classes instead of the default ones.

public class CustomTemplate : Template
    {
        public override CodeBlock CreateNewCodeBlock(string code, int creationIndex)
        {
            return new CustomCodeBlock(code, creationIndex);
        }

        public override Output CreateNewOutput(ParsedTemplate parsedTemplate, TextWriter writer)
        {
            return new CustomOutput(parsedTemplate, writer);
        }
    }

That’s it! The full sample is available on our GitHub.

Happy Templating

The R&D Team.

Thinktecture IdentityServer and CodeFluent Entities


Thinktecture IdentityServer v3 is a .NET-based open source implementation of an OpenID Connect provider and OAuth2 authorization server. Today, we are going to explain how to use this light-weight security token service with CodeFluent Entities.

To save time, we provide on our GitHub repository a sample of IdentityServer with CodeFluent Entities but… how to install and use it ? First, you need to get and install the ASP.NET Identity Producer. There’s nothing to it. Download the server source code from our GitHub and compile it. In a few words, this producer will assist you in creating ASP.NET Identity entities (User, Role, Claim, Login).

Now, open the solution and set “SoftFluent.Samples.Thinktecture.IdentityServer.Host” as Startup Project. Don’t forget to set “Don’t open a page option. Wait for a request from an external application” in Host project and start it:

 

Configuration

Then, download the client source code from Thinktecture’s GitHub and compile it. Set “JavaScript Implicit Client” as Startup Project  and start it.

You should obtain this page:

Thinktecture Sample 1Then, click on “Login With Profile” :

Thinktecture Sample 2We choose to show you external login with Google so click the “Google” butto. Enter your credentials and allow the permissions you wish to grant. At this point IdentityServer will be save our new user in database through ASP.NET Identity.

If we take a look at the User’s table, we should find a new entry:

Thinktecture Sample 3

Finally, you receive Token and information about your account :

Thinktecture Sample 4

IdentityServer is provided without UI and administration tool but recently Thinktecture offers a new project called IdentityManager for developers and administrators to manage the identity information for users of their applications.

Happy Authenticating,

The R&D Team

 

 

What’s new with CodeFluent Entities 770?


CodeFluent Entities provides several producers allowing you to generate your persistence layer on several database engines. The previous build includes numerous new features such as the support of Microsoft SQL Server 2014.

MariaDB

Once again, the CodeFluent Entities 2014 – Build 770 introduces the support of a new relational database management system: MariaDB. It is a community-developed fork of MySQL created in 2009 which includes some new improvements that (some claim) make it better than MySQL.

Our latest build improves the MySQL producer and now supports MariaDB. The producer supports MariaDB 5.1 and above and relies on the MySQL Connector for .NET version 6.5.4.0. The producer will try to load dynamically the MySql.Data assembly so you might need to copy the MySql.Data.dll in your CodeFluent Entities installation directory if you don’t want to register the MySQL Connector in the GAC.

MariaDB Producer

Below, you can see a generated MariaDB according to the ContactManager CodeFluent Entities Sample Model:

MariaDB Generated

Note that you might need to reference the CodeFluent Runtime.dll and CodeFluent.Runtime.MySQL.dll if you generate the C# Business Object Layer (CodeDom Producer).

CodeFluent Entities 2014 – Build 770 also includes numerous bug fixes and new features. The full list is available here. Yesterday, we published a post that talk about a new feature: How to compress or extract CAB archives. Feel free to read it!

If you have any questions or comments, please share them below.

Happy downloading!

The R&D Team

How to compress or extract CAB archives?

June 2, 2014 1 comment

Today, on the series “Exploring the CodeFluent Runtime” we’re going to explore how to compress or extract CAB archives.

Cabinet (or CAB) is an archive file format for Windows that supports lossless data compression and embedded digital certificates used for maintaining archive integrity. Cabinet files have .cab file name extensions.

First, we have to add a reference to “CodeFluent.Runtime.dll”. The namespace we’ll use is “CodeFluent.Runtime.Compression”, the same as for compressing or extracting ZIP file.

One of the biggest advantage compare to ZIP file, is that it can work in memory or by using the file system as it uses Stream. The second point is you don’t have to add a native DLL: it’s all managed. While it’s less efficient than a native implementation, it’s easier to deploy.

Here’s an example to compress one file and a directory:

using (MemoryStream stream = new MemoryStream())
{
    using (CabFile file = new CodeFluent.Runtime.Compression.CabFile(stream, CabFileMode.Compress))
    {
        file.CompressionLevel = CabCompressionLevel.Maximum;
        file.AddEntry("File.txt");
        file.AddDirectory("Sample");
    }
}

Extracting files is as simple as compressing.

using (CabFile file = new CodeFluent.Runtime.Compression.CabFile(stream, CabFileMode.Decompress))
{
    file.EntryExtracted += (sender, e) =>
    {
        //e.Entry.Name
        //e.Entry.OutputStream
        //e.Entry.Bytes
        //e.Entry.Size
        //e.Entry.LastWriteTime
        //e.Entry.Tag
    };
    file.ExtractEntries();
}

And there’s more…

We add a method to determine the compression method (CAB or ZIP) of a file. This method can use the file extension if available or the first four bytes of the file (i.e. magic number):

CompressionUtilities.SniffFileFormat("test.cab", useExtensionAsHint: true) == CompressionFileFormat.Cab

And that’s not all, in the previous article, we wrote about how to sign a file by using the runtime. CAB file can also be signed, so let sign it:

X509Certificate2 certificate = Authenticode.FindSuitableCertificate(); 
Authenticode.SignFile(certificate, "test.cab", null, "SoftFluent");

Cab properties

Happy compressing and signing,

The R&D Team