Automated personal assistants are everywhere these days. Siri and Google Now keep us talking to our phones. Amazon Echo and Google Homes are in our houses. They are all playing our music, ordering our Ubers, and answering our questions about entertainment, hard news, random facts, etc. The problem? DMC didn't have one too.

StevieBot the Personal Assistant

Instead of being jealous, we engineered away our problem and DMC now has StevieBot!

StevieBot can do a lot of things like report the weather, search Wikipedia, and define words for us.

He can even tell us jokes.

Based on the MargieBot architecture, DMC's StevieBot has a simple framework for .NET with a great library. You can find all the resources you need at MargieBot to begin creating your own custom Slackbots.

SlackBot Framework Functionality 

The framework operates by creating a bot configuration (i.e. giving your bot a personality). Like the fish who came before him, StevieBot needed that special "something" that makes him part of the DMC family. 

To achieve this "personality", the program loads various custom responders that you create.

The program then establishes a connection with Slack (as well as any other webs services) using a unique API key.

Slack to Bot Implementation

1. In Slack, implement StevieBot as a Bot User.
2. Create a custom Slackbot by going to your team’s settings page.
3. Select create a new bot user.

Take note: To establish communication between the framework and Slack, you need the auto-generated API Token.

Bot Considerations – Bot Parameters

Once initialized, the framework waits for Slack to send a notification that it has received a message. The framework then parses the message and determines if the bot should respond.

The framework considers:

• Who sent the message?
• Was the bot mentioned in the message?
• Was it a direct message?

Take note: These parameters are all configurable and can to determine how the bot will respond.

The framework checks the message for regular expressions using .NET’s included RegEx engine. The results of the checks determine the appropriate responder.

Finally, StevieBot creates a message and posts it back to Slack!

The Future – SlackBots and Particle Cloud Communication 

StevieBot also communicates with the Particle Cloud. This paves the way for potential IoT fish tank functionality in the future. We’ve already purchased some components including pH, temperature, and turbidity sensors.

For now, we can ask Stevie to poll the various Particle boards around the office and check their status.

Conclusion

Built on an expandable framework, plans exist to implement in StevieBot aspects of the neural network architecture for machine learning so StevieBot can be more proactive with messages. The future options are endless, but an assistant who can recommend lunches based on individual tastes sounds like a perfect start.

Fun projects aren't the only thing we do! Explore more of DMC's C# and .Net Development Services.

If you're sorry you missed another FedEx Day with us, check out our Career page!

The post Creating a Slackbot Personal Assistant with .NET and an Office Fish appeared first on DMC, Inc..

I recently started a personal project to monitor the real estate market in Houston to gain insight into trends in pricing, neighborhood composition, construction, etc. One vital piece of the puzzle was reliably and efficiently gathering detailed information on specific properties to monitor over time. Using Zillow.com’s Developer APIs and the HTML Agility Pack, I was able to spin up a prototype over coffee one Sunday morning, and I wanted to share my experience using this powerful C# library.

The Zillow API

The majority of modern websites use JSON as the data exchange format, as it is easily consumed by the widely-used JavaScript language, but there are a significant number of sites (including Zillow.com) that use XML as the exchange format. There are advantages and disadvantages to each, but both formats are straightforward to parse and are human-readable. 

Zillow provides several useful APIs, and I chose GetDeepSearchResults because it encapsulates most of the data I want to track in my application. The documentation is refreshingly complete and useful: you can see details about each field, the XML schema, error codes, and an example usage. After obtaining my developer API key, I scratched out a few lines of code to load the results.

 private void LoadResults(string property)
 {
     // Argument "property" is a URL-encoded string containing a single property address, city, and state
     string addr = "http://www.zillow.com/webservice/GetDeepSearchResults.htm";
     string key = "?[My_API_Key]&";
     string results = String.Empty;

     // Create a new HTTP client to communicate with the Zillow server
     HttpClient client = new HttpClient();
     client.BaseAddress = new Uri(addr);

     // Load the results of the querty
     HttpResponseMessage response = client.GetAsync(key + property).Result;
     if (response.IsSuccessStatusCode)
     {
         results = response.Content.ReadAsStringAsync();
     }
     else
     {
         Debug.WriteLine("Web call failed with code " + response.StatusCode);
     }
     return results;
 }

 private void LoadResults(string property)
 {
     // Argument "property" is a URL-encoded string containing a single property address, city, and state
     string addr = "http://www.zillow.com/webservice/GetDeepSearchResults.htm";
     string key = "?[My_API_Key]&";
     string results = String.Empty;

     // Create a new HTTP client to communicate with the Zillow server
     HttpClient client = new HttpClient();
     client.BaseAddress = new Uri(addr);

     // Load the results of the querty
     HttpResponseMessage response = client.GetAsync(key + property).Result;
     if (response.IsSuccessStatusCode)
     {
         results = response.Content.ReadAsStringAsync();
     }
     else
     {
         Debug.WriteLine("Web call failed with code " + response.StatusCode);
     }
     return results;
 }

The LoadResults function takes in a well-formed URL-encoded property listing string that meets the requirements listed in the API documentation, and returns either an empty string (if the API call failed) or an XML-encoded string containing the property details.

Parsing with Agility

I could have spent some time brewing up a RegEx-powered parser for the XML results – after all, this is a well-documented API, and I know what to expect from each call. But why re-invent the wheel? It’s also worth pointing out that not all APIs (or web pages, which you can also easily scrape with the HTML Agility Pack) are as consistent and well-formed, so your homebrewed parser might work for a while until it tries to handle a malformed response. 

Using the Agility Pack and the Zillow documentation, I can easily parse out the XML tags I care about without writing a single regex.

 private PropertyData ParseResults(string results)
 {
     // Create an instance of the PropertyData to store the results
     PropertyData data = new PropertyData();

     // Load the API result string
     HtmlDocument doc = new HtmlDocument();
     doc.LoadHtml(results);

     // Find the parameters that will be tracked
     var zpid = doc.DocumentNode.Descendants("zpid").FirstOrDefault().InnerText;
     var finSize = doc.DocumentNode.Descendants("finishedSqFt").FirstOrDefault().InnerText;
     var zestValue = doc.DocumentNode.Descendants("amount").FirstOrDefault().InnerText;
     var baths = doc.DocumentNode.Descendants("bathrooms").FirstOrDefault().InnerText;
     var beds = doc.DocumentNode.Descendants("bedrooms").FirstOrDefault().InnerText;

     // Parse these value strings into their expected data types
     data.Zpid = int.Parse(zpid);
     data.FinishedSize = int.Parse(finSize);
     data.ZestValue = double.Parse(zestValue);
     data.Bathrooms = double.Parse(baths);
     data.Bedrooms = double.Parse(beds);

     return data;
 }

 private PropertyData ParseResults(string results)
 {
     // Create an instance of the PropertyData to store the results
     PropertyData data = new PropertyData();

     // Load the API result string
     HtmlDocument doc = new HtmlDocument();
     doc.LoadHtml(results);

     // Find the parameters that will be tracked
     var zpid = doc.DocumentNode.Descendants("zpid").FirstOrDefault().InnerText;
     var finSize = doc.DocumentNode.Descendants("finishedSqFt").FirstOrDefault().InnerText;
     var zestValue = doc.DocumentNode.Descendants("amount").FirstOrDefault().InnerText;
     var baths = doc.DocumentNode.Descendants("bathrooms").FirstOrDefault().InnerText;
     var beds = doc.DocumentNode.Descendants("bedrooms").FirstOrDefault().InnerText;

     // Parse these value strings into their expected data types
     data.Zpid = int.Parse(zpid);
     data.FinishedSize = int.Parse(finSize);
     data.ZestValue = double.Parse(zestValue);
     data.Bathrooms = double.Parse(baths);
     data.Bedrooms = double.Parse(beds);

     return data;
 }

That’s all there is to it! No bulky regular expressions or clunky homebrewed parsing code. For clarity, I stripped out a lot of input sanitation and error handling code, so don’t forget to check for exception conditions!

Other Applications

You may have an inkling that a parsing tool like the HTML Agility Pack can work for more than just parsing XML responses. You would be correct. Another key area where this library can come into play is data scraping (or web data extraction). If an API is not available or doesn’t give you all of the information you need, you can load the web page and parse the whole thing for the data you need. 

It’s very important to note that web scraping may violate the Terms of Use for a site, and if your scraping tool misbehaves and loads the webpage at a high rate, you run the risk of compromising the site’s resources and awaking the angry IT department kraken! Please be considerate, review the legality of your application, and scrape responsibly!

If you’ve used the HTML Agility Pack in an application or have questions about how I used it in mine, leave a comment below! Happy coding.

Learn more about DMC’s web application development.

The post Easy XML Parsing in C#/.NET With the HTML Agility Pack appeared first on DMC, Inc..

However, if you are working in the engineering world of CAD files, Eyeshot is by far the best tool available for C#. There is a lot of great functionality out of the box and it is pretty extensible. Without further ado, I’ll share a few of the fun things we’ve done!

File Compatibility

We’ve used Eyeshot to pull in DXF, DWG, STL (including Mesh entities), and STEP files. It also supports reading and saving OBJ, IGES, and several other formats. Conversion between formats can sometimes take some work depending on the details, but is generally doable.

Demonstration of real-time movement behind objects and automatic transparency to keep it visible 
Model source: Modern Building by S. Prasanth
 

Our custom object creation, editing, and collision detection algorithms on display
Model source: 6mm Bolt Head Knob for Unscrewing by Aidan McMaster

Point and Object Creation

You can use Eyeshot to build your own full-fledged CAD generator or editor. However, the applications we’ve been developing so far are not aimed at CAD jockeys. We’ve made some simple point, line, bar, and curve creation and editing tools. While Eyeshot has support for 3D mice, we are aiming at simple mouse or touch screen (and yes, multi-touch!) interfaces. Eyeshot has some nice multi-touch functionality out of the box, although we’ve found we had to build onto it with quite a bit of customization.

Real-Time Updates and Animation

We’ve set up our application to show objects moving in real time by feeding in live, real world coordinates. This also can be used to show pre-recorded animations. Update rates of 60 frames per second are easily achievable.

Collision Detection

We’ve had several uses for collision detection algorithms, which can always be a tricky subject. Generally game engines are better for collision detection as Eyeshot lacks this functionality out of the box, but we have implemented some of our own routines for multiple different purposes.

One is to verify that created objects live in a valid space and don’t collide with other objects in a non-dynamic situation. The other is to verify whether or not there are collisions with moving objects. In both cases you always have to use an approximation method, such as hit boxes, and some innovative 3D geometry and math.

Skinning

Eyeshot allows you to apply images (materials) to objects to add a little more life to the model. You also can adjust the transparency of different entities and layers. One cool feature we added was dynamic transparency to hide objects that are in the way of viewing a moving object.

Overall, we look forward to continuing to use Eyeshot in future projects, especially as DevDept continues to improve the program and add new features requested by users.

Learn more about DMC’s C# programming expertise and services.

The post CAD Models in C#: Developing with Eyeshot appeared first on DMC, Inc..

While there are some guides available that give you similar information, I found it a bit difficult to get started developing MVC modules in DNN. For reference, the articles I used are at the bottom of this blog.

Here’s an overview of the steps we’ll take to get started.

1. Prerequisites
2. Templates
3. Setup
4. Build
5. Installation
6. Next Steps
7. References

1. Prerequisites

For this quick start, you’ll need a few things before we can dive in.

First, you’ll need to have Visual Studio 2015 installed. The express editions have been reported to be incompatible with the templates we’ll be using later, but this may not be true by the time you’re reading this.

Next, you’ll need to have IIS (Internet Information Services) setup with a local installation of DNN (version 8 or higher). There are many tutorials on how to do this around the web. You’ll need to install IIS and Microsoft SQL Server, then you can install DNN by downloading the latest _install.zip from DNN’s GitHub releases.

Once those are all set up, you’re ready to go.

2. Templates

You could create a module from scratch. But why would you do that when a DNN expert created templates for you to use? Download the templates from the Visual Studio Gallery and run through the installation procedure.

3. Setup

Now that everything is set up, we can actually dive into creating the module. 

In Visual Studio, select File -> New -> Project

In the New Project window, select Templates -> Visual C# -> DotNetNuke and you’ll see a listing of the types of projects the templates have provided.

To create an MVC module, we’ll select DotNetNuke 8 C# DAL2 MVC Module. There are three other fields we must configure: Name, Location, and Solution name.

Name: Enter a name for your project (it’s best not to use any spaces or special characters for this)

Location: This is important to point this to the correct folder in DNN: /DesktopModules/MVC/. Depending on your installation directory, the folder should be something like C:\Dev\Projects\DMC_Website\Alpha\DesktopModules\MVC\ where “Alpha” is the root of your DNN installation.

Solution name: We’re not actually going to be using this field. Uncheck the box on the right that says “Create directory for solution” and the solution name textbox will be greyed out.

Confirm your settings look similar to mine and then click OK.

A Project Setup Wizard dialog box will appear asking for some project information. Many of these are self explanatory, so I will only address the two that are a bit tricky.

Namespace: Whatever namespace you want your module to live in. The templates will automatically include your project name in the namespace, so no need to enter it here. Make sure you include the last period. E.g. DMC.

Local Dev URL: By default this is set up to point to dnndev.me, which is actually set up to point back to 127.0.0.1 (your localhost). What you enter here depends on what settings you’ve set your DNN install up with. For my installation, I access my local DNN install through http://localhost./ Therefore, I am going to enter localhost as my Local Dev URL.

Initial values

Updated values (note: the owner website field includes https:// but the textbox isn’t large enough to display it. Be sure to include it in your URL.)

Once all fields have been complete, click OK.

4. Build

Now that the initial project setup is complete, you’ll be presented with a web page in Visual Studio that says * Important *. These are steps that you should read carefully and follow to ensure your project will work correctly. I’ll provide a quick overview of these steps in case the original wording is confusing for anyone.

First, check IIS to see if any of your folders were converted to virtual directories or applications. To do this, open IIS, expand your site’s dropdown and check what icon is displayed next to your DesktopModules folder or the MVC folder inside of the DesktopModules folder. If it’s anything other than a yellow folder, right click it and click remove.

Next, in Visual Studio, right click and delete the web.config files that are in the solution.

You can now build the module! change the solution configuration dropdown from Debug to Release and then select Build -> Build

You’ll get an install .zip file in your module’s install/ directory.

5. Installation

Now, in DNN, go to Hosts -> Extensions and click Install Extension, selecting your install .zip file that you previously built.

If everything goes well, then the module is now installed and can be placed on any page.

6. Next Steps

Once you’ve dragged the module into a page, you’ll see a demo application that includes multiple views, database interaction, and more. Simply build the project in debug mode to automatically copy the new DLL to the /bin folder.

7. References

• Chris Hammond’s DNN posts
• DNN Community Blogs
• DNN MVC Module Development

While you’re here, check out DMC’s Web Application Development and ASP.NET & ASP.NET MVC Development services so we can get started on your next DNN MVC module!

The post 6 Easy Steps to Get Started with MVC Module Development in DNN 8 appeared first on DMC, Inc..

Modules

To quote the Prism documentation itself:

A module is a logical collection of functionality and resources that is packaged in a way that can be separately developed, tested, deployed, and integrated into an application.

All modules contain a central class responsible for initialization of the module and integration of it into the application. This class implements the IModule interface, which consists of one method: Initialize(). Typically, this method and a constructor are the only methods needed for this class, but I’ll share more on that in a bit.

Before we start making our modules, we should probably decide how we want Prism to know where to find them. This is where the Module Catalog comes in.

The Module Catalog

In a composite application, modules must be discovered and loaded at run time by the host application (the Shell in Prism). Prism accomplishes this through a module catalog which specifies the modules to load, when to load them and in what order. There are several choices for filling the module catalog:

• Registering modules in code
• Registering modules in XAML
• Registering modules in a configuration file
• Discovering modules in a local directory on disk
• Derive from ModuleCatalog class to create your own custom module catalog behavior

Which mechanism you use depends on the needs of your application (there’s also nothing stopping you from using more than one mechanism if you are so inclined). Each module catalog class implements the IModuleCatalog interface. For this application we will use directory discovery (via the DirectoryModuleCatalog class), but a brief description of the other methods follows.

Registering Modules in Code

The ModuleCatalog class is the most basic IModuleCatalog implementation. It is used to programmatically register modules by specifying each module class type. You can also specify properties on each module such as the name, initialization mode, other module dependencies and the loading state.

To register a module, call the AddModule() method of the ModuleCatalog class. This is typically done in an override of the Bootstrapper method ConfigureModuleCatalog(). With this approach, you can use conditional logic to determine which modules should be included in your application. The modules added in code are referenced by the application rather than being loaded at runtime like other methods. However, unless you want to provide a direct reference in your application to each module’s assembly, thereby giving the Shell project knowledge of what modules exist (ideally the Shell shouldn’t know anything about what modules are out there), you will have to use reflection in your Bootstrapper method to provide the fully qualified type name and location of the assembly that contains the module.

Here’s an example of how you might register a module in code (note that it assumes your Shell project has a static reference to the module project):

protected override void ConfigureModuleCatalog()
{
    var myModuleType = typeof(MyModule);
    Prism.Bootstrapper.ModuleCatalog.AddModule(
      new ModuleInfo()
      {
          ModuleName = myModuleType.Name,
          ModuleType = myModuleType.AssemblyQualifiedName,
          DependsOn = new Collection<string>(new List<string>()
          {
              "MyOtherModule",
              "MyServiceModule"
          })
      });
}

protected override void ConfigureModuleCatalog()
{
    var myModuleType = typeof(MyModule);
    Prism.Bootstrapper.ModuleCatalog.AddModule(
      new ModuleInfo()
      {
          ModuleName = myModuleType.Name,
          ModuleType = myModuleType.AssemblyQualifiedName,
          DependsOn = new Collection<string>(new List<string>()
          {
              "MyOtherModule",
              "MyServiceModule"
          })
      });
}

In the above code, the DependsOn property can also be set in the attributes of the module class instead of here. The attributes are also where you set the name of the module referenced by myModuleType.Name.

Registering Modules in a XAML File

Another option to declaratively define a module catalog is via a XAML file. Typically, you add the file as a resource to the Shell project. You then override the CreateModuleCatalog() method of your Bootstrapper and within that method call the CreateFromXaml() method of class Prism.Modularity.ModuleCatalog.

The XAML might look something like this:

<!-- ModulesCatalog.xaml -->
<Modularity:ModuleCatalog xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
                          xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
                          xmlns:sys="clr-namespace:System;assembly=mscorlib"
                          xmlns:Modularity="clr-namespace:Microsoft.Practices.Prism.Modularity;assembly=Microsoft.Practices.Prism">
    <Modularity:ModuleInfoGroup InitializationMode="OnDemand">
        <Modularity:ModuleInfo Ref="file://ModularityWithUnity.Desktop.MyOtherModule.dll" ModuleName="MyOtherModule" ModuleType="ModularityWithUnity.Desktop.MyOtherModule, ModularityWithUnity.Desktop.MyOtherModule, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null">
        <Modularity:ModuleInfo Ref="file://ModularityWithUnity.Desktop.MyServiceModule.dll" ModuleName="MyServiceModule" ModuleType="ModularityWithUnity.Desktop.MyServiceModule, ModularityWithUnity.Desktop.MyServiceModule, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null">
        <Modularity:ModuleInfo Ref="file://ModularityWithUnity.Desktop.MyModule.dll" ModuleName="MyModule" ModuleType="ModularityWithUnity.Desktop.MyModule, ModularityWithUnity.Desktop.MyModule, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
            <Modularity:ModuleInfo.DependsOn>
                <sys:String>MyOtherModule</sys:String>
                <sys:String>MyServiceModule</sys:String>
            </Modularity:ModuleInfo.DependsOn>
        </Modularity:ModuleInfo>
    </Modularity:ModuleInfoGroup>
</Modularity:ModuleCatalog>

<!-- ModulesCatalog.xaml -->
<Modularity:ModuleCatalog xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
                          xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
                          xmlns:sys="clr-namespace:System;assembly=mscorlib"
                          xmlns:Modularity="clr-namespace:Microsoft.Practices.Prism.Modularity;assembly=Microsoft.Practices.Prism">
    <Modularity:ModuleInfoGroup InitializationMode="OnDemand">
        <Modularity:ModuleInfo Ref="file://ModularityWithUnity.Desktop.MyOtherModule.dll" ModuleName="MyOtherModule" ModuleType="ModularityWithUnity.Desktop.MyOtherModule, ModularityWithUnity.Desktop.MyOtherModule, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null">
        <Modularity:ModuleInfo Ref="file://ModularityWithUnity.Desktop.MyServiceModule.dll" ModuleName="MyServiceModule" ModuleType="ModularityWithUnity.Desktop.MyServiceModule, ModularityWithUnity.Desktop.MyServiceModule, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null">
        <Modularity:ModuleInfo Ref="file://ModularityWithUnity.Desktop.MyModule.dll" ModuleName="MyModule" ModuleType="ModularityWithUnity.Desktop.MyModule, ModularityWithUnity.Desktop.MyModule, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
            <Modularity:ModuleInfo.DependsOn>
                <sys:String>MyOtherModule</sys:String>
                <sys:String>MyServiceModule</sys:String>
            </Modularity:ModuleInfo.DependsOn>
        </Modularity:ModuleInfo>
    </Modularity:ModuleInfoGroup>
</Modularity:ModuleCatalog>

Modules don’t have to be in a ModuleInfoGroup, but it allows for setting common properties for modules and is the only way to set module dependencies. In the Bootstrapper, you’d then have the following for ConfigureModuleCatalog():

protected override IModuleCatalog CreateModuleCatalog()
{
    return Prism.Modularity.ModuleCatalog.CreateFromXaml(new Uri("/PrismSample;component/ModulesCatalog.xaml", UriKind.Relative));
}

protected override IModuleCatalog CreateModuleCatalog()
{
    return Prism.Modularity.ModuleCatalog.CreateFromXaml(new Uri("/PrismSample;component/ModulesCatalog.xaml", UriKind.Relative));
}

Registering Modules in a Configuration File

Similar in idea to registering in a XAML file, this method has the added benefit of not requiring the application to be recompiled if you want to add and remove modules at runtime since the file is not compiled into the application. Setting attribute startupLoaded=”true” on a module will automatically load the module.

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <configSections>
    <section name="modules" type="Microsoft.Practices.Prism.Modularity.ModulesConfigurationSection, Microsoft.Practices.Prism"/>
  </configSections>
  <modules>
    <module assemblyFile="ModularityWithUnity.Desktop.MyOtherModule.dll" moduleType="ModularityWithUnity.Desktop.MyOtherModule, ModularityWithUnity.Desktop.MyOtherModule, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" moduleName="MyOtherModule" startupLoaded="false" />
    <module assemblyFile="ModularityWithUnity.Desktop.MyServiceModule.dll" moduleType="ModularityWithUnity.Desktop.MyServiceModule, ModularityWithUnity.Desktop.MyServiceModule, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" moduleName="MyServiceModule" startupLoaded="false" />
    <module assemblyFile="ModularityWithUnity.Desktop.MyModule.dll" moduleType="ModularityWithUnity.Desktop.MyModule, ModularityWithUnity.Desktop.MyModule, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" moduleName="MyModule" startupLoaded="false">
      <dependencies>
        <dependency moduleName="MyOtherModule"/>
        <dependency moduleName="MyServiceModule"/>
      </dependencies>
    </module>
    <module assemblyFile="ModularityWithUnity.Desktop.MyAutoLoadModule.dll" moduleType="ModularityWithUnity.Desktop.MyAutoLoadModule, ModularityWithUnity.Desktop.MyAutoLoadModule, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" moduleName="MyAutoLoadModule" startupLoaded="true" />
  </modules>
</configuration>

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <configSections>
    <section name="modules" type="Microsoft.Practices.Prism.Modularity.ModulesConfigurationSection, Microsoft.Practices.Prism"/>
  </configSections>
  <modules>
    <module assemblyFile="ModularityWithUnity.Desktop.MyOtherModule.dll" moduleType="ModularityWithUnity.Desktop.MyOtherModule, ModularityWithUnity.Desktop.MyOtherModule, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" moduleName="MyOtherModule" startupLoaded="false" />
    <module assemblyFile="ModularityWithUnity.Desktop.MyServiceModule.dll" moduleType="ModularityWithUnity.Desktop.MyServiceModule, ModularityWithUnity.Desktop.MyServiceModule, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" moduleName="MyServiceModule" startupLoaded="false" />
    <module assemblyFile="ModularityWithUnity.Desktop.MyModule.dll" moduleType="ModularityWithUnity.Desktop.MyModule, ModularityWithUnity.Desktop.MyModule, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" moduleName="MyModule" startupLoaded="false">
      <dependencies>
        <dependency moduleName="MyOtherModule"/>
        <dependency moduleName="MyServiceModule"/>
      </dependencies>
    </module>
    <module assemblyFile="ModularityWithUnity.Desktop.MyAutoLoadModule.dll" moduleType="ModularityWithUnity.Desktop.MyAutoLoadModule, ModularityWithUnity.Desktop.MyAutoLoadModule, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" moduleName="MyAutoLoadModule" startupLoaded="true" />
  </modules>
</configuration>

To specify that the configuration file is the source of your module catalog, you would add the following code to the Bootstrapper:

protected override IModuleCatalog CreateModuleCatalog()
{
    return new ConfigurationModuleCatalog();
}

protected override IModuleCatalog CreateModuleCatalog()
{
    return new ConfigurationModuleCatalog();
}

Discovering Modules in a Local Directory on Disk

This is the method we will be using for this blog series. The module catalog scans the specified directory searching for assemblies defining each module in the application. This method requires the use of declarative attributes in the module classes to define the module names and any dependencies. (This is different from the other approaches where these attributes are defined as part of the catalog itself.) Aside from a mechanism to copy the module libraries to the catalog directory (typically accomplished by adding a post-build copy event to the module project), the only other thing needed is the following override in the Bootstrapper:

protected override IModuleCatalog CreateModuleCatalog()
{
    // Use local directory as module catalog
    return new DirectoryModuleCatalog { ModulePath = "Modules" };
}

protected override IModuleCatalog CreateModuleCatalog()
{
    // Use local directory as module catalog
    return new DirectoryModuleCatalog { ModulePath = "Modules" };
}

If we were using MEF instead of Unity, we wouldn’t override CreateModuleCatalog(). Instead we’d create a new instance of the DirectoryCatalog class and add that to the MEF AggregateCatalog as follows:

/// <summary>
/// Imperatively add type registrations to MEF's Aggregate Catalog
/// </summary>
protected override void ConfigureAggregateCatalog()
{
    base.ConfigureAggregateCatalog();

    // Add Shell assembly
    this.AggregateCatalog.Catalogs.Add(new AssemblyCatalog(typeof(Bootstrapper).Assembly));

    // Add module catalog
    var moduleCatalog = new DirectoryCatalog("Modules");
    this.AggregateCatalog.Catalogs.Add(moduleCatalog);
}

/// <summary>
/// Imperatively add type registrations to MEF's Aggregate Catalog
/// </summary>
protected override void ConfigureAggregateCatalog()
{
    base.ConfigureAggregateCatalog();

    // Add Shell assembly
    this.AggregateCatalog.Catalogs.Add(new AssemblyCatalog(typeof(Bootstrapper).Assembly));

    // Add module catalog
    var moduleCatalog = new DirectoryCatalog("Modules");
    this.AggregateCatalog.Catalogs.Add(moduleCatalog);
}

Create the Modules

We’ve defined our module catalog, so it’s time to create the modules. We start by adding a folder to our solution tree called Modules. (This step isn’t strictly necessary, but I find it nice for organization of the assemblies. Your mileage may vary.) Right-click on the Modules folder and select Add→New Project…. Name the class library NavigationMenu and click OK.

Delete the Class1.cs file that is created. Next we add the Prism and Unity libraries to our module. This process is identical to what we did with the Shell project. Right click on the NavigationMenu project and select Manage NuGet Packages…. Click on the Browse tab and type prism.unity in the search box. Select the Prism.Unity package and install it.

Now is as good of a time as any to also add a reference to our Infrastructure assembly. We will define all our module names as constants in a static class as part of Infrastructure. After adding a reference to the Infrastructure project in our module, right click on the Constants folder in the project and select Add→New From Template→Class. In the popup box type ModuleNames and click OK. Add a constant for the Navigation Menu module name to this class as follows:

namespace Infrastructure.Constants
{
    public static class ModuleNames
    {
        public const string NAVIGATION_MENU = "NavigationMenu";
    }
}

namespace Infrastructure.Constants
{
    public static class ModuleNames
    {
        public const string NAVIGATION_MENU = "NavigationMenu";
    }
}

The next step to is to create the module initialization file, which defines the module attributes and registers the interfaces and classes the module implements. Right click on the NavigationMenuModule project and select Add→New From Template→Class. In the popup box type NavigationMenuModule and click OK. This new class needs to implement the IModule interface, which consists of one method called Initialize(). The class also needs a declarative ModuleAttribute applied that defines at least the ModuleName property. In this case we set the property to the constant we defined above as follows:

using Infrastructure.Constants;
using Prism.Modularity;

namespace NavigationMenu
{
    /// <summary>
    /// Register components of module with Unity/Prism
    /// </summary>
    [Module(ModuleName = ModuleNames.NAVIGATION_MENU)]
    public class NavigationMenuModule : IModule
    {
        public void Initialize()
        {
        }
    }
}

using Infrastructure.Constants;
using Prism.Modularity;

namespace NavigationMenu
{
    /// <summary>
    /// Register components of module with Unity/Prism
    /// </summary>
    [Module(ModuleName = ModuleNames.NAVIGATION_MENU)]
    public class NavigationMenuModule : IModule
    {
        public void Initialize()
        {
        }
    }
}

We still have to copy the module library to our catalog folder. To this we open the properties of our NavigationMenu project and add the following post-build event:

robocopy "$(TargetDir)\" "$(SolutionDir)PrismSample\$(OutDir)Modules" NavigationMenu.dll
if %errorlevel% geq 8 exit 1
exit 0

robocopy "$(TargetDir)\" "$(SolutionDir)PrismSample\$(OutDir)Modules" NavigationMenu.dll
if %errorlevel% geq 8 exit 1
exit 0

(Note:  Instead of robocopy (i.e. Robust Copy) some people might use xcopy here. The problem with xcopy is that Microsoft officially deprecated it a while ago. Additionally, robocopy has nicer error handling. I have found, however, that sometimes robocopy seems to hang for a while when building the application in Visual Studio, particularly when many modules are built. I’ve yet to figure out why, but it might be that robocopy is slow to release the directory after it finishes copying, so when the next module tries to copy to the directory it can’t get access. Occasionally, robocopy will even time out and the build will fail. Building again usually cleans up the issue.)

The final step to getting our module to load is to ensure the solution builds this module before it builds the shell. Right-click on the PrismSample solution in Solution Explorer and select Project Dependencies…. Select the PrismSample project under the Projects: drop-down and you should see that Infrastructure is already checked. Check NavigationMenu as well. If you look at the Build Order tab you should see Infrastructure listed first in the order and Prism Sample listed last.

Following a similar process to above that we used with NavigationMenu, we can add the TopRegion, MiddleRegion, and BottomRegion modules as well. (As mentioned in the previous part of this series in regards to the shell regions, a real application would have more descriptive names for what the other three modules actually do.) Our application will run, but since we haven’t implemented any actual functionality in our modules, it does nothing other than display a logo at this point. For the final section of this part of the series, I’ll create a simple menu view and show how to register it with a region for display.

View Composition (Discovery)

View composition is the construction of a view. There are two ways to create and display a view in a region:

• Automatically through discovery
• Programmatically through injection

Discovery sets up a relationship in the RegionViewRegistry between a region’s name and a type of view. When a region is created, all view types associated with the region are automatically instantiated and their corresponding views loaded. With this method there is no explicit control over when views are loaded and displayed.

Injection involves obtaining a reference to a region and then programmatically injecting views into it. This gives you full control over when views are loaded, removed, and displayed. However, you cannot add a view to a region that has not been created yet.

For this part of the blog series, we concern ourselves only with discovery. We’ll come back to injection in a later part of this series when we introduce the View Navigation API.

We start by creating the view for our menu by adding a new WPF User Control to our NavigationMenu project:

(Note: After creating the user control, we’ll likely need to add a reference to System.Xaml to our project.)

At this point it makes sense to create a Resource Dictionary to hold the control styles common to the various views in our application. We’ll add a SharedResources folder to the Infrastructure project and to that folder we add a new resource dictionary. Since our Infrastructure project is a Class Library, however, we can’t add the file through the convenience of the Add New Item dialog, so we’ll have to do it manually. (Or if you use Resharper like I do, you can select the “More…” menu from the Add New From Template menu and it will give you the option to add one there.) We’ll name the resource dictionary ResourceDictionary.xaml, and once we add it, we’ll also add a reference to the .NET PresentationFramework library to our Infrastructure project so that the resource dictionary is supported. For now our resource dictionary is pretty straightforward and looks like this:

<ResourceDictionary xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
                    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
                    xmlns:system="clr-namespace:System;assembly=mscorlib">

    <!--Fonts-->
    <system:Double x:Key="NormalFontSize">26</system:Double>
    <FontFamily x:Key="NormalFont">Century Gothic</FontFamily>

    <!--Colors-->
    <Color x:Key="NormalFontColor">#FF5F5F5F</Color>

    <!--Brushes-->
    <SolidColorBrush x:Key="NormalForegroundBrush" Color="{StaticResource NormalFontColor}" />

    <!--TextBlocks-->
    <Style x:Key="NormalTextBlockStyle" TargetType="TextBlock">
        <Setter Property="FontFamily" Value="{StaticResource NormalFont}" />
        <Setter Property="Foreground" Value="{StaticResource NormalForegroundBrush}" />
        <Setter Property="FontSize" Value="{StaticResource NormalFontSize}" />
    </Style>

    <!--Controls-->
    <Style x:Key="BaseControlStyle" TargetType="Control">
        <Setter Property="FontFamily" Value="{StaticResource NormalFont}" />
        <Setter Property="Foreground" Value="{StaticResource NormalForegroundBrush}" />
        <Setter Property="FontSize" Value="{StaticResource NormalFontSize}" />
    </Style>
    
</ResourceDictionary>

<ResourceDictionary xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
                    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
                    xmlns:system="clr-namespace:System;assembly=mscorlib">

    <!--Fonts-->
    <system:Double x:Key="NormalFontSize">26</system:Double>
    <FontFamily x:Key="NormalFont">Century Gothic</FontFamily>

    <!--Colors-->
    <Color x:Key="NormalFontColor">#FF5F5F5F</Color>

    <!--Brushes-->
    <SolidColorBrush x:Key="NormalForegroundBrush" Color="{StaticResource NormalFontColor}" />

    <!--TextBlocks-->
    <Style x:Key="NormalTextBlockStyle" TargetType="TextBlock">
        <Setter Property="FontFamily" Value="{StaticResource NormalFont}" />
        <Setter Property="Foreground" Value="{StaticResource NormalForegroundBrush}" />
        <Setter Property="FontSize" Value="{StaticResource NormalFontSize}" />
    </Style>

    <!--Controls-->
    <Style x:Key="BaseControlStyle" TargetType="Control">
        <Setter Property="FontFamily" Value="{StaticResource NormalFont}" />
        <Setter Property="Foreground" Value="{StaticResource NormalForegroundBrush}" />
        <Setter Property="FontSize" Value="{StaticResource NormalFontSize}" />
    </Style>
    
</ResourceDictionary>

In order for this to build, we’ll need to add references to the PresentationCore, WindowsBase and System.Xaml libraries to our Infrastructure project.

And while we’re add it, this would be a good point to add localizable strings to that project as well (though, this application will never need to worry about it). We’ll add a new folder called Strings as a subfolder to our SharedResources folder and to that new folder add a new Resources File with a Public access modifier we’ll call Text.resx.

Going back to our NavigationMenu.xaml file, we will implement a fairly simple menu as follows:

<UserControl x:Class="NavigationMenu.NavigationMenu"
             xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
             xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
             xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
             xmlns:str="clr-namespace:Infrastructure.SharedResources.Strings;assembly=Infrastructure"
             xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
             mc:Ignorable="d"
             d:DesignHeight="800" d:DesignWidth="300">

    <UserControl.Resources>
        <ResourceDictionary>
            <ResourceDictionary.MergedDictionaries>
                <ResourceDictionary Source="/Infrastructure;component/SharedResources/ResourceDictionary.xaml" />
            </ResourceDictionary.MergedDictionaries>
        </ResourceDictionary>
    </UserControl.Resources>

    <Grid>
        <StackPanel Background="White">

            <StackPanel.Resources>
                <Style TargetType="Button" BasedOn="{StaticResource BaseControlStyle}">
                    <Setter Property="Background" Value="Transparent" />
                    <Setter Property="Template">
                        <Setter.Value>
                            <ControlTemplate TargetType="Button">
                                <Border Padding="10" Background="{TemplateBinding Background}">
                                    <ContentPresenter VerticalAlignment="Center" />
                                </Border>
                            </ControlTemplate>
                        </Setter.Value>
                    </Setter>
                    <Style.Triggers>
                        <Trigger Property="IsMouseOver" Value="True">
                            <Setter Property="Foreground" Value="#2D82B9" />
                        </Trigger>
                        <Trigger Property="IsPressed" Value="True">
                            <Setter Property="Foreground" Value="{StaticResource NormalForegroundBrush}" />
                            <Setter Property="Background" Value="LightGray" />
                        </Trigger>
                    </Style.Triggers>
                </Style>
            </StackPanel.Resources>

            <Button Content="{x:Static str:Text.About}" />
            <Button Content="{x:Static str:Text.CreateError}" />
            <Button Content="{x:Static str:Text.Exit}" />
        </StackPanel>
    </Grid>
</UserControl>

<UserControl x:Class="NavigationMenu.NavigationMenu"
             xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
             xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
             xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
             xmlns:str="clr-namespace:Infrastructure.SharedResources.Strings;assembly=Infrastructure"
             xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
             mc:Ignorable="d"
             d:DesignHeight="800" d:DesignWidth="300">

    <UserControl.Resources>
        <ResourceDictionary>
            <ResourceDictionary.MergedDictionaries>
                <ResourceDictionary Source="/Infrastructure;component/SharedResources/ResourceDictionary.xaml" />
            </ResourceDictionary.MergedDictionaries>
        </ResourceDictionary>
    </UserControl.Resources>

    <Grid>
        <StackPanel Background="White">

            <StackPanel.Resources>
                <Style TargetType="Button" BasedOn="{StaticResource BaseControlStyle}">
                    <Setter Property="Background" Value="Transparent" />
                    <Setter Property="Template">
                        <Setter.Value>
                            <ControlTemplate TargetType="Button">
                                <Border Padding="10" Background="{TemplateBinding Background}">
                                    <ContentPresenter VerticalAlignment="Center" />
                                </Border>
                            </ControlTemplate>
                        </Setter.Value>
                    </Setter>
                    <Style.Triggers>
                        <Trigger Property="IsMouseOver" Value="True">
                            <Setter Property="Foreground" Value="#2D82B9" />
                        </Trigger>
                        <Trigger Property="IsPressed" Value="True">
                            <Setter Property="Foreground" Value="{StaticResource NormalForegroundBrush}" />
                            <Setter Property="Background" Value="LightGray" />
                        </Trigger>
                    </Style.Triggers>
                </Style>
            </StackPanel.Resources>

            <Button Content="{x:Static str:Text.About}" />
            <Button Content="{x:Static str:Text.CreateError}" />
            <Button Content="{x:Static str:Text.Exit}" />
        </StackPanel>
    </Grid>
</UserControl>

Finally, in NavigationMenuModule.cs we will register our module via the Module declarative attribute and then in the Initialize() method of the IModule interface we register this view with the region we’ve defined for it:

using Infrastructure.Constants;
using Prism.Modularity;
using Prism.Regions;

namespace NavigationMenu
{
    /// <summary>
    /// Register components of module with Unity/Prism
    /// </summary>
    [Module(ModuleName = ModuleNames.NAVIGATION_MENU)]
    public class NavigationMenuModule : IModule
    {
        private readonly IRegionManager _regionManager;

        public NavigationMenuModule(IRegionManager regionManager)
        {
            this._regionManager = regionManager;
        }

        public void Initialize()
        {
            this._regionManager.RegisterViewWithRegion(RegionNames.MENU_REGION, typeof(NavigationMenu));
        }
    }
}

using Infrastructure.Constants;
using Prism.Modularity;
using Prism.Regions;

namespace NavigationMenu
{
    /// <summary>
    /// Register components of module with Unity/Prism
    /// </summary>
    [Module(ModuleName = ModuleNames.NAVIGATION_MENU)]
    public class NavigationMenuModule : IModule
    {
        private readonly IRegionManager _regionManager;

        public NavigationMenuModule(IRegionManager regionManager)
        {
            this._regionManager = regionManager;
        }

        public void Initialize()
        {
            this._regionManager.RegisterViewWithRegion(RegionNames.MENU_REGION, typeof(NavigationMenu));
        }
    }
}

For MEF, registration is a bit different. We first need to add the [Export] attribute to our NavigationMenu.xaml.cs file as follows:

using System.ComponentModel.Composition;
using System.Windows.Controls;

namespace NavigationMenu
{
    /// <summary>
    /// Interaction logic for NavigationMenu.xaml
    /// </summary>
    [Export]
    public partial class NavigationMenu : UserControl
    {
        public NavigationMenu()
        {
            this.InitializeComponent();
        }
    }
}

using System.ComponentModel.Composition;
using System.Windows.Controls;

namespace NavigationMenu
{
    /// <summary>
    /// Interaction logic for NavigationMenu.xaml
    /// </summary>
    [Export]
    public partial class NavigationMenu : UserControl
    {
        public NavigationMenu()
        {
            this.InitializeComponent();
        }
    }
}

And then in our module file we register the module using the Module attribute as we did in Unity, but we also have to add a ModuleExport attribute for the module itself, and declare the constructor as an ImportingConstructor so that the region manager can be set through dependency injection:

using System.ComponentModel.Composition;
using Infrastructure.Constants;
using Prism.Mef.Modularity;
using Prism.Modularity;
using Prism.Regions;

namespace NavigationMenu
{
    /// <summary>
    /// Register components of module with MEF/Prism
    /// </summary>
    [Module(ModuleName = ModuleNames.NAVIGATION_MENU)]
    [ModuleExport(typeof(NavigationMenuModule), InitializationMode = InitializationMode.WhenAvailable)]
    public class NavigationMenuModule : IModule
    {
        private readonly IRegionManager _regionManager;

        [ImportingConstructor]
        public NavigationMenuModule(IRegionManager regionManager)
        {
            this._regionManager = regionManager;
        }

        public void Initialize()
        {
            this._regionManager.RegisterViewWithRegion(RegionNames.MENU_REGION, typeof(NavigationMenu));
        }
    }
}

using System.ComponentModel.Composition;
using Infrastructure.Constants;
using Prism.Mef.Modularity;
using Prism.Modularity;
using Prism.Regions;

namespace NavigationMenu
{
    /// <summary>
    /// Register components of module with MEF/Prism
    /// </summary>
    [Module(ModuleName = ModuleNames.NAVIGATION_MENU)]
    [ModuleExport(typeof(NavigationMenuModule), InitializationMode = InitializationMode.WhenAvailable)]
    public class NavigationMenuModule : IModule
    {
        private readonly IRegionManager _regionManager;

        [ImportingConstructor]
        public NavigationMenuModule(IRegionManager regionManager)
        {
            this._regionManager = regionManager;
        }

        public void Initialize()
        {
            this._regionManager.RegisterViewWithRegion(RegionNames.MENU_REGION, typeof(NavigationMenu));
        }
    }
}

If we build the application, we now see our menu has populated the region on the left-hand side. (The other three modules have also been added with place-holder views.) Of course, it doesn’t do anything at this point, but we will shortly rectify that in Part 4:  Intermodule Communication (coming soon).

The Unity-based solution files and source code for this part can be downloaded by clicking below

The MEF-based solution files and source code for this part can be downloaded by clicking below

A Properly Pleasing Prism Primer – The Parts:

Part 1:  An Introduction
Part 2:  The Shell and Bootstrapper
Part 3:  Modules
Part 4:  Intermodule Communication (Coming soon)

Learn more about DMC’s .NET application development services.

The post A Properly Pleasing Primer Tutorial for WPF Prism – Part 3: Modules appeared first on DMC, Inc..

The Shell

Composite applications are architected such that individual parts of the application can be developed, tested, and modified independent from other parts. If you think of the application as a painting, the shell is the canvas, a container that integrates everything together in a coherent whole. It is essentially the “application” part of the composite application. The XAML file in the shell consists of one or more regions, which are named logical placeholders into which views are injected.  Each region is attached to a common container control such as a ContentControl, ItemsControl, ListBox, or TabControl. The shell we’ll be using for this sample application will consist of four regions each attached to a ContentControl.

Start by opening Visual Studio and selecting the New Project dialog from the file menu. Create a WPF Application.

Click OK to create the project and solution. Though not strictly necessary, I like to rename the automatically generated MainWindow class to Shell due to convention.

Next, we need to create an Infrastructure project as a class library. If the Shell is our canvas, the Infrastructure project is the palette. It holds all classes, resources, and constants that will be shared between the Shell and the various modules, as well as all the interfaces for the shared services.

Delete any classes created and add a reference to this project to your Shell project. Next, add a folder called “Constants” to the Infrastructure project. To this new folder add a new public static class called “RegionNames” and add the constants shown below. If this were a real application rather than an instructive one, the naming conventions for the regions would probably reflect the functional purpose of the injected modules for each region.

namespace Infrastructure.Constants
{
    public static class RegionNames
    {
        public const string MENU_REGION = "MenuRegion";
        public const string SHELL_BOTTOM_REGION = "ShellBottomRegion";
        public const string SHELL_MIDDLE_REGION = "ShellMiddleRegion";
        public const string SHELL_TOP_REGION = "ShellTopRegion";
    }
}

namespace Infrastructure.Constants
{
    public static class RegionNames
    {
        public const string MENU_REGION = "MenuRegion";
        public const string SHELL_BOTTOM_REGION = "ShellBottomRegion";
        public const string SHELL_MIDDLE_REGION = "ShellMiddleRegion";
        public const string SHELL_TOP_REGION = "ShellTopRegion";
    }
}

Now we add the Prism libraries to our Shell. Right click on the PrismSample project and select “Manage NuGet Packages…” Click on the “Browse” tab and type “prism.unity” in the search box. Select the “Prism.Unity” package and install it.

Finally, we implement the Shell XAML. Our layout will be pretty straightforward with a logo in the upper left corner, the menu region below that, and the other three regions taking up the right side.

<Window x:Class="PrismSample.Shell"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
        xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
        xmlns:prism="http://www.codeplex.com/prism"
        xmlns:constants="clr-namespace:Infrastructure.Constants;assembly=Infrastructure"
        mc:Ignorable="d"
        Title="Prism Sample Application" Height="900" Width="1600" Icon="Resources/DMC Wheel Transparent Background.ico">
    <Grid>
        <Grid.ColumnDefinitions>
            <ColumnDefinition Width="Auto" />
            <ColumnDefinition />
        </Grid.ColumnDefinitions>
        <Grid Grid.Column="0" Margin="50, 25" >
            <Grid.RowDefinitions>
                <RowDefinition Height="Auto" />
                <RowDefinition />
            </Grid.RowDefinitions>
            <Image Grid.Row="0" Margin="10,20" Source="Resources/Small_jpg.jpg" />
            <ContentControl Grid.Row="1" prism:RegionManager.RegionName="{x:Static constants:RegionNames.MENU_REGION}" />
        </Grid>
        <Grid Grid.Column="1" Background="#FFE7E7E7">
            <Grid.RowDefinitions>
                <RowDefinition />
                <RowDefinition />
                <RowDefinition />
            </Grid.RowDefinitions>
            <ContentControl Margin="30, 30, 30, 0" Grid.Row="0" prism:RegionManager.RegionName="{x:Static constants:RegionNames.SHELL_TOP_REGION}" />
            <ContentControl Margin="30, 15" Grid.Row="1" prism:RegionManager.RegionName="{x:Static constants:RegionNames.SHELL_MIDDLE_REGION}" />
            <ContentControl Margin="30, 0, 30, 30" Grid.Row="2" prism:RegionManager.RegionName="{x:Static constants:RegionNames.SHELL_BOTTOM_REGION}" />
        </Grid>
    </Grid>
</Window>

<Window x:Class="PrismSample.Shell"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
        xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
        xmlns:prism="http://www.codeplex.com/prism"
        xmlns:constants="clr-namespace:Infrastructure.Constants;assembly=Infrastructure"
        mc:Ignorable="d"
        Title="Prism Sample Application" Height="900" Width="1600" Icon="Resources/DMC Wheel Transparent Background.ico">
    <Grid>
        <Grid.ColumnDefinitions>
            <ColumnDefinition Width="Auto" />
            <ColumnDefinition />
        </Grid.ColumnDefinitions>
        <Grid Grid.Column="0" Margin="50, 25" >
            <Grid.RowDefinitions>
                <RowDefinition Height="Auto" />
                <RowDefinition />
            </Grid.RowDefinitions>
            <Image Grid.Row="0" Margin="10,20" Source="Resources/Small_jpg.jpg" />
            <ContentControl Grid.Row="1" prism:RegionManager.RegionName="{x:Static constants:RegionNames.MENU_REGION}" />
        </Grid>
        <Grid Grid.Column="1" Background="#FFE7E7E7">
            <Grid.RowDefinitions>
                <RowDefinition />
                <RowDefinition />
                <RowDefinition />
            </Grid.RowDefinitions>
            <ContentControl Margin="30, 30, 30, 0" Grid.Row="0" prism:RegionManager.RegionName="{x:Static constants:RegionNames.SHELL_TOP_REGION}" />
            <ContentControl Margin="30, 15" Grid.Row="1" prism:RegionManager.RegionName="{x:Static constants:RegionNames.SHELL_MIDDLE_REGION}" />
            <ContentControl Margin="30, 0, 30, 30" Grid.Row="2" prism:RegionManager.RegionName="{x:Static constants:RegionNames.SHELL_BOTTOM_REGION}" />
        </Grid>
    </Grid>
</Window>

If we were to try to execute our program now, we’d throw an exception indicating a missing service location provider. Prism is designed that when it needs to access a component of the application (in this case the RegionManager) it doesn’t initialize the component directly but instead delegates this task to a ServiceLocator. So how do we let Prism know what ServiceLocator to use? That’s where the next component of our application comes in.

The Bootstrapper

If the Shell is the canvas, the Infrastructure project is the palette, the modules are the images to paint, and Prism is the paintbrush, that would make the Bootstrapper the medium of this tortured artistic metaphor. The Bootstrapper connects the Shell to the Prism services and the Dependency Injection container. Unique for each application, it typically inherits from the abstract classes UnityBootstrapper or MefBootstrapper, depending upon DI container used. (If using a different DI container from either Unity or MEF, there is a base abstract bootstrapper class from which all bootstrap classes inherit. The developer would create their own class which inherits that base class and customize it for that particular DI container.) Since we are using Unity for our DI, we inherit from UnityBootstrapper for our class, thereby letting Prism do most of the difficult work for us.

The first thing we need to do once we’ve created our Bootstrapper is override the CreateShell() method. CreateShell() lets you specify the top-level window for a Prism application. You can either create the shell object yourself, or let the ServiceLocator do it. We’ll opt for the latter.

protected override DependencyObject CreateShell()
{
    return ServiceLocator.Current.GetInstance<Shell>();
}

protected override DependencyObject CreateShell()
{
    return ServiceLocator.Current.GetInstance<Shell>();
}

Next, we override InitializeShell(). InitializeShell() is where you run any initialization steps you need to ensure the Shell is ready to be displayed. After that, you set the Shell as the application’s main window and show it.

protected override void InitializeShell()
{
    Application.Current.MainWindow = (Shell)this.Shell;
    Application.Current.MainWindow.Show();
}

protected override void InitializeShell()
{
    Application.Current.MainWindow = (Shell)this.Shell;
    Application.Current.MainWindow.Show();
}

This is all we have to do with the Bootstrapper for now. We will be returning to it frequently over the course of this series. Here’s the complete class.

using System.Windows;
using Microsoft.Practices.ServiceLocation;
using Prism.Unity;

namespace PrismSample
{
    /// <summary>
    /// Initializes Prism/Unity components and services
    /// </summary>
    public class Bootstrapper : UnityBootstrapper
    {
        /// <summary>
        /// Make main window class as Prism shell
        /// </summary>
        protected override DependencyObject CreateShell()
        {
            return ServiceLocator.Current.GetInstance<Shell>();
        }

        /// <summary>
        /// Set the application's window to the current shell and display it
        /// </summary>
        protected override void InitializeShell()
        {
            Application.Current.MainWindow = (Shell)this.Shell;
            Application.Current.MainWindow.Show();
        }
    }
}

using System.Windows;
using Microsoft.Practices.ServiceLocation;
using Prism.Unity;

namespace PrismSample
{
    /// <summary>
    /// Initializes Prism/Unity components and services
    /// </summary>
    public class Bootstrapper : UnityBootstrapper
    {
        /// <summary>
        /// Make main window class as Prism shell
        /// </summary>
        protected override DependencyObject CreateShell()
        {
            return ServiceLocator.Current.GetInstance<Shell>();
        }

        /// <summary>
        /// Set the application's window to the current shell and display it
        /// </summary>
        protected override void InitializeShell()
        {
            Application.Current.MainWindow = (Shell)this.Shell;
            Application.Current.MainWindow.Show();
        }
    }
}

On a side note, if we were using MEF for our dependency injection container, we’d add one more override to the Bootstrapper: ConfigureAggregateCatalog(). We’d then add a new AssemblyCatalog consisting of our Bootstrapper’s assembly to MEF’s AggregateCatalog inside that method.

All that’s left is to let WPF know that we want the Bootstrapper to be our startup class. First we remove the StartupUri attribute from App.xaml.

<Application x:Class="PrismSample.App"
             xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
             xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
    <Application.Resources>         
    </Application.Resources>
</Application>

<Application x:Class="PrismSample.App"
             xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
             xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
    <Application.Resources>         
    </Application.Resources>
</Application>

Then in App.xaml.cs we override OnStartup() as follows:

using System.Windows;
namespace PrismSample
{
    /// <summary>
    /// Interaction logic for App.xaml
    /// </summary>
    public partial class App : Application
    {
        protected override void OnStartup(StartupEventArgs e)
        {
            base.OnStartup(e);
            new Bootstrapper().Run();
        }
    }
}

using System.Windows;
namespace PrismSample
{
    /// <summary>
    /// Interaction logic for App.xaml
    /// </summary>
    public partial class App : Application
    {
        protected override void OnStartup(StartupEventArgs e)
        {
            base.OnStartup(e);
            new Bootstrapper().Run();
        }
    }
}

And now our application is ready to run. Granted, it doesn’t do much at this point, mainly because we haven’t loaded any modules. We’ll start adding those in Part 3: Modules.

The solution files and source code for this part can be downloaded by clicking below

A Properly Pleasing Prism Primer – The Parts:

Part 1:  An Introduction
Part 2:  The Shell and Bootstrapper
Part 3:  Modules

Learn more about DMC’s .NET application development services.

The post A Properly Pleasing Primer Tutorial for WPF Prism – Part 2: The Shell and Bootstrapper appeared first on DMC, Inc..

For example, let’s say you’ve written a GUI that consists of a single button whose purpose when clicked is to produce a bell sound providing conditioned stimulus to make the user drool. (On the internet no one knows you’re a dog, after all.) The whole application can and should be handled completely by a single View. Usage of a pattern such as Model-View-Controller, Model-View-Presenter, or Model-View-ViewModel would be a sloppy mess, much like the aforementioned user’s screen, keyboard and mouse.

But rarely are applications that simple. Most will benefit from at least some pattern use, and as complexity grows, the advantages of patterns greatly exceed the overhead of implementing them. For applications using Windows Presentation Foundation (WPF), Silverlight, Windows 10 UWP, or Xamarin Forms as their user interface framework, this is where Prism can help.

What is Prism?

Prism, a project originally developed by Microsoft patterns and practices and now under the stewardship of the .NET Foundation, is a collection of resources implementing common design patterns and architectural support for loosely-coupled modular applications. It saves you the time, energy and complexity it would take to implement these resources yourself. To quote Prism’s own documentation:

Prism provides guidance designed to help you more easily design and build rich, flexible, and easy-to-maintain Windows Presentation Foundation (WPF) desktop applications. Using design patterns such as Model-View-ViewModel (MVVM), Composite View, and Event Aggregator that embody important architectural design principles helps you create a modular application—using loosely coupled components that can evolve independently. These types of applications are known as composite applications….It is expected that the application will evolve significantly over its lifetime in response to new requirements and business opportunities. In short, these applications are "built to last" and "built for change." Applications that do not demand these characteristics may not benefit from using Prism.

“Prism” was the early codename for the Composite Application Library (CAL) which was later renamed to Composite Application Guidance for WPF and Silverlight. No doubt realizing that they were headed towards a progression of increasingly long, complex and awkward to verbalize naming conventions, Microsoft took a step back and redubbed it “Prism.” Prism provides many different functionalities, including modular programming support, event aggregation, shared services, logging, command processing (including built-in implementation of the ICommand interface), deploying to multiple frameworks, support for both Model-View-Presenter (MVP) and Model-View-ViewModel (MVVM) presentation patterns (including built-in implementation of INotifyPropertyChanged) and dependency injection (DI) and inversion of control (IoC). For DI/IoC, Prism includes built-in support for both MEF and Unity, but can be configured to use other DI containers if desired. And since each asset is largely independent from the other assets, an application developer is free to use as many or as few of them as they want, depending on the needs of the application. While this blog series will touch on most of the functionality Prism provides, it will concern itself primarily with combining Prism with WPF, MVVM and Unity for UI framework, presentation model and dependency injection, respectively.

Where is Prism?

The Prism libraries and their source code are available on GitHub. The libraries are also available through NuGet. As of this blog post, the current version is 6.2.0.

Documentation can be found also at GitHub or through MSDN. The documentation is well written, thorough and organized and also includes some sample projects. However, it’s also fairly long and detailed, so this blog series will try to provide you with enough of an overview to get you started working with Prism without having to read the entire documentation start to finish. As a result, there are a considerable number of documented features that I won't be addressing in this series.

How Do I Use Prism?

In all honesty, considering all the functionality Prism provides, a full answer to that question exceeds what one can be reasonably expected to accomplish in a blog series. However, if you want a good foundation from which you can start programming with Prism and/or better absorb the documentation already out there, this series has that in spades. It will walk you through a step-by-step creation of a fairly simple WPF application that uses MVVM and Unity and touches upon a significant portion of the more commonly used functionality Prism provides. Each part of the blog will build on the previous part, and source code will be available, along with solution and project files. (Visual Studio 2015; .NET Framework SDK 4.6.2)

Note that this series assumes the reader has at least a passing familiarity with C#, WPF, and the MVVM design pattern.

So without further ado, we continue on to  Part 2:  The Shell and Bootstrapper

A Properly Pleasing Prism Primer – The Parts:

Part 1:  An Introduction
Part 2:  The Shell and Bootstrapper
Part 3:  Modules

Learn more about DMC's .NET application development services.

The post A Properly Pleasing Primer Tutorial for WPF Prism – Part 1: Introduction appeared first on DMC, Inc..

Installation

First step is to install Visual Studio. Visual Studio Community is free and works perfectly for this application.

After installing Visual Studio, go through the PCDK installer. 

Getting Started with FANUC PCDK

Next, start up Visual Studio and create a new Console Application. I called mine “FanucTest”.

After clicking OK, right click on the “References” in the solution, and click “Add Reference”.

Under COM, find FANUC Robotics Controller Interface. Select it and click OK.

Now to begin writing code!

Connecting to a Robot

Add the following highlighted lines to your code to connect to your robot. If this runs, you’ve successfully installed PCDK and you’re ready to communicate with your robot. 

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using FRRobot;      //uses the robot reference we just added

namespace FanucTest
{
    class Program
    {
        static void Main(string[] args)
        {
            Console.WriteLine("Press any key to continue...");
            Console.ReadKey();

            //Create a robot object
            FRCRobot mobjRobot = new FRCRobot();
            //Connect to your robot
            mobjRobot.Connect("192.168.1.123");
            bool connected = mobjRobot.IsConnected;

        }

    }
}

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using FRRobot;      //uses the robot reference we just added

namespace FanucTest
{
    class Program
    {
        static void Main(string[] args)
        {
            Console.WriteLine("Press any key to continue...");
            Console.ReadKey();

            //Create a robot object
            FRCRobot mobjRobot = new FRCRobot();
            //Connect to your robot
            mobjRobot.Connect("192.168.1.123");
            bool connected = mobjRobot.IsConnected;

        }

    }
}

Updating a Position Register

To finish off this hello world program, add the following lines of code to update a position register. We’re accessing position register 1 below and updating the values. 

  //See help topics "Efficient Access to Positions"
            FRCSysPositions sysPositions = mobjRobot.RegPositions;
            FRCSysPosition sysPosition = sysPositions[1];
            FRCSysGroupPosition sysGroupPosition = sysPosition.Group[1];
            FRCXyzWpr xyzWpr = sysGroupPosition.Formats[FRETypeCodeConstants.frXyzWpr];
            //Prepare updated X,Y,Z,W,P, and R values of position register 1
            xyzWpr.X = 475;
            xyzWpr.Y = -275;
            xyzWpr.Z = -231;
            xyzWpr.W = -176;
            xyzWpr.P = 0;
            xyzWpr.R = 0;
            try
            {
                //Update position register 1
                sysGroupPosition.Update();

            }

  //See help topics "Efficient Access to Positions"
            FRCSysPositions sysPositions = mobjRobot.RegPositions;
            FRCSysPosition sysPosition = sysPositions[1];
            FRCSysGroupPosition sysGroupPosition = sysPosition.Group[1];
            FRCXyzWpr xyzWpr = sysGroupPosition.Formats[FRETypeCodeConstants.frXyzWpr];
            //Prepare updated X,Y,Z,W,P, and R values of position register 1
            xyzWpr.X = 475;
            xyzWpr.Y = -275;
            xyzWpr.Z = -231;
            xyzWpr.W = -176;
            xyzWpr.P = 0;
            xyzWpr.R = 0;
            try
            {
                //Update position register 1
                sysGroupPosition.Update();

            }

To learn how to do more with the robot, check out the PCDK help documentation. Depending on your version of Windows, you might need to install another program to view the help documentation. 

Learn more about DMC’s Manufacturing and Automation Intelligence services and contact us today!

The post How to Use FANUC PC Developer’s Kit (PCDK) appeared first on DMC, Inc..

We’re seeing them more and more. Don’t get me wrong, off the shelf solutions are great, and should be used wherever they make sense. But sometimes they don’t fit all of the requirements our customers need. Here are some examples I’ve encountered over the past few months where a custom PC app made the most sense in an industrial setting:

1.    A program that automatically parses CAD drawings of a part, and then sends the resulting data to a PLC.
2.    Multiple offsite PLCs sending Ethernet packets over a cellular modem, to a server-side application that received, parsed, and logged the data.
3.    A web-based interface that translate data back and forth between a custom SQL server and multiple PLCs.

So we’ve established there are situations where a custom app makes sense. But how does one write this type of program? What tools are out there to connect the dots? As it turns out, there are plenty! Here are some of my favorites:

Dot Net PLC Toolbox 
Believe it or not, there’s actually a pretty strong community of .NET developers interested in interfacing to PLCs. One of my favorite open-source libraries is the Dot Net PLC Toolbox. This in-depth, free library allows .NET apps to parse PLC projects, as well as communicate, read tags, and go online. Last year I personally was involved with using this toolbox to create an open-source S7 Source Control Utility.

InGear Drivers 
The guys over at InGear have created easy-to-use .NET drivers for Siemens, OPC, and more. Sure, there are free tools available, but sometimes it’s nice to pay for a product just so you have a support team to rely on when you need them.

Jamod
Most of our development is built on .NET, but sometimes client requirements dictate another language like Java. This is where a library like Jamod can be handy. Jamod is a Java library written for Modbus (serial, TCP, or UDP). Since Modbus is such an open protocol, this library makes it easy to connect your Java application to PLCs, drives, smart IO, and more.

TIA Portal Openness 
For Siemens PLCs in particular, there are official tools available to the interested programmer. With the latest version of TIA Portal, Siemens released an API used to interface with PLC programs. This code library allows developers to “automate” their code development by exporting, modifying, and importing TIA projects. I was pretty familiar with their old software, the Command Interface, and was excited to see them release a tool for Portal as well.

Learn more about DMC’s .NET and automation intelligence capabilities. 

The post Connecting Custom Applications to the Factory Floor appeared first on DMC, Inc..

Sam, Sudeep, and I were fed up with this. On our latest FedEx Day, which is a day dedicated to fun, internal improvement projects, we decided there had to a better way. An advanced, easy-to-use team communication and collaboration tool that served a single, highly-specialized purpose: to figure out what we wanted to eat.

And since we’re a creative bunch, we made exactly that and named it Lunch for Business.

Application Features

It can be hard to get a large group of people all using the same new tool. That’s why our number one goal was to make this stupid simple. It installs with a single click, automatically launches on startup, and lives stowed away in your system tray.  

When you decide that yes, you would very much like a burrito today, you can double click the tray icon, type in “Chipotle”, and hit suggest. At that moment, everyone currently running Lunch for Business gets a little balloon notification saying that a suggestion has been made. People can then click “Join” to hop on your bandwagon, or they can make a suggestion of their own.

Once you’ve joined a lunch spot, you can let people know you’re willing to drive others there. You can also click on the lunch spot to launch Google Maps for directions and check out the traffic conditions. When you’re ready to go, you can click “Leave” and everyone in your group will get notified that it’s time to head out.

Lunch for Business was adopted quickly and has become the de facto way of suggesting places to go eat in the Chicago office. The days of walking around in circles are long gone. Aside from fulfilling an extremely important need, the project has been a nice way to check out cool technologies like SignalR, Hangfire, and the Google Maps API.

We also used a variety of familiar favorites to build the application, including:

• C#
• .NET
• WebSockets
• ASP.NET MVC
• WPF
• Microsoft SQL Server

A Closer Look at DMC's Noshing Preferences

As an added bonus, keeping track of lunch spots has let us keep statistics on where DMC likes to eat. Chipotle and Mariano’s dominate the list, with one of the two being suggested half of the time. But, thankfully, the other half includes a much more diverse list of places in our neighborhood. DMC clearly has some favorites, but we still like to explore different options.

Learn more about DMC's Custom Software and Hardware Development services.

The post Lunch for Business: A Better Way to Lunch appeared first on DMC, Inc..