This library has the capability to simultaneously flash up to eight ECUs on separate communication channels. Additionally, these APIs are compatible with several application environments, including LabVIEW.

Learn vFlashStation API Calls

This blog explains how we were able to integrate Vector’s vFlashStation API with NI’s LabVIEW development environment to flash software to multiple ECUs at a time.

To flash an ECU, there are five necessary commands:

1. Initialize()
   
   Description: Synchronously initializes the vFlash library. This must be called before calling any other command.
    
2. Load Project(string Path, uint channelID, out long projectHandle)
   
   Description: Synchronously loads a packed project (.vflashpack) to a specific channel. The flash project contains important data such as the security seed key and necessary flashware. The packed project must be initially created using the vFlash GUI that comes with the hardware.
   
   Parameters:
    
   • Path: filepath to the vFlash packed project (.vflashpack).
      
   • channelID: Channel number for the project. It must match the numbers used in the Vector Hardware Configuration screen (vFlash CAN 1, vFlash CAN 2, etc.).
      
   • projectHandle: The method will return a handle (ID) for the newly loaded project.
      
3. Start(long projectHandle, CallbackProgressDelegate progressCallback, CallbackStatusDelegate statusCallback)
   
   Description: Asynchronously starts the flash process for the channel as indicated by the projectHandle.
    

   Parameters:

   • projectHandle: Handle (ID) to the project to be flashed. Should have been created during the Load Project method.
      
   • progressCallback: Delegate reporting the flash progress in percent and time remaining (seconds).
      
   • statusCallback: Delegate reporting the status of the flash process (enum containing success or error information).
      
4. Unload Project(long projectHandle)
   
   Description: Synchronously unloads the project associated with the project handle.
   
   Parameters:
    
   • projectHandle: ID of the associated project and channel. Should have been created during the Load Project method.
      
5. Deinitialize()
   
   Description: Deinitializes the vFlash library in order to free allocated resources.

These are the bare bone methods required to flash an ECU through the vFlashStation API. While the other methods are not described in detail in this blog post, Vector also created other API calls to customize reporting, networks, flash attributes, and custom actions.

Create a C-Based Wrapper of vFlashStation API

It’s important to note that the Start API method requires two callback delegates in order to correctly query the flashing status information. This is especially important for simultaneously flashing multiple ECUs. However, LabVIEW does not currently have a way to natively access or call a callback delegate.

The best workaround for this is to create a C-based wrapper to handle the callback delegate. In my case, I created a script using Visual Studio that referenced the vFlashStationAutomation DLL and housed my desired methods and callback delegates. The code snippet below shows how the vFlashStation API and callback delegates are utilized in my wrapper.
 

        public VFlashStationResult StartFlash()
        {
            VFlashStationResult startResult = VFlashStationAPI.Start(ProjectHandle, ProgressCallback, StatusCallback);
            return startResult;
        }


        /// <summary>
        /// The StatusCallback handles changes of the reprogramming status.
        /// If the reprogramming process was successfully finished, the callback contains
        /// the result <see cref="VFlashStationStatus.Success"/>.
        /// Otherwise the <paramref name="flashStationStatus"/> contains the error code.
        /// </summary>
        /// <param name="ProjectHandle">The project handle.</param>
        /// <param name="flashStationStatus">The flash station status.</param>
        /// <remarks>If detailed error information is required, 
        /// check <see cref="VFlashStationAPI.GetLastErrorMessage"/>.</remarks>
        private void StatusCallback(long ProjectHandle, VFlashStationStatus flashStationStatus)
        {
            Status = flashStationStatus;
        }

        /// <summary>
        /// The ProgressCallback contains progress information about the current
        /// reprogramming process containing the progress in percent and the
        /// estimated remaining time in seconds to finished the flash process.
        /// </summary>
        /// <param name="ProjectHandle">The project handle.</param>
        /// <param name="progressInPercent">The progress in percent.</param>
        /// <param name="remainingTimeInSeconds">The remaining time in seconds.</param>
        private void ProgressCallback(long ProjectHandle, uint progressInPercent, uint remainingTimeInSeconds)
        {
            PercentProgress = progressInPercent;
            TimeRemaining = remainingTimeInSeconds;
        }

        public VFlashStationResult StartFlash()
        {
            VFlashStationResult startResult = VFlashStationAPI.Start(ProjectHandle, ProgressCallback, StatusCallback);
            return startResult;
        }


        /// <summary>
        /// The StatusCallback handles changes of the reprogramming status.
        /// If the reprogramming process was successfully finished, the callback contains
        /// the result <see cref="VFlashStationStatus.Success"/>.
        /// Otherwise the <paramref name="flashStationStatus"/> contains the error code.
        /// </summary>
        /// <param name="ProjectHandle">The project handle.</param>
        /// <param name="flashStationStatus">The flash station status.</param>
        /// <remarks>If detailed error information is required, 
        /// check <see cref="VFlashStationAPI.GetLastErrorMessage"/>.</remarks>
        private void StatusCallback(long ProjectHandle, VFlashStationStatus flashStationStatus)
        {
            Status = flashStationStatus;
        }

        /// <summary>
        /// The ProgressCallback contains progress information about the current
        /// reprogramming process containing the progress in percent and the
        /// estimated remaining time in seconds to finished the flash process.
        /// </summary>
        /// <param name="ProjectHandle">The project handle.</param>
        /// <param name="progressInPercent">The progress in percent.</param>
        /// <param name="remainingTimeInSeconds">The remaining time in seconds.</param>
        private void ProgressCallback(long ProjectHandle, uint progressInPercent, uint remainingTimeInSeconds)
        {
            PercentProgress = progressInPercent;
            TimeRemaining = remainingTimeInSeconds;
        }

While not shown in this code snippet, I also kept each of the vFlash API calls exposed as individual public methods in my script (like the StartFlash example above). This made my application a little more flexible from the LabVIEW perspective since I could perform the tasks independently in any sequence.

Additionally, I also created a class called ECU in my C# script. This gave me a great way to group the information for each of my channels and neatly dispose of them when I no longer needed them. Each class stores the data that I need such as project path, project handle, channel ID, status, etc.

public class ECU : IDisposable
    {
        public string ECUname { get; private set; }
        public string ProjectPath { get; private set; }
        public long ProjectHandle { get; set; }
        public uint ChannelID { get; private set; }
        public uint PercentProgress { get; private set; }
        public uint TimeRemaining { get; private set; }
        public VFlashStationStatus Status { get; private set; }
        public VFlashStationResult Result { get; private set; }

        /// <summary>
        /// Generate class for each ECU. We get name, project path, and channel ID from LabVIEW
        /// </summary>
        /// <param name="projectHandle"></param>
        public ECU(string Name, string projectPath, uint channelID)
        {
            ECUname = Name;
            ProjectPath = projectPath;
            ChannelID = channelID;
            TimeRemaining = 0;
            PercentProgress = 0;
        }

public class ECU : IDisposable
    {
        public string ECUname { get; private set; }
        public string ProjectPath { get; private set; }
        public long ProjectHandle { get; set; }
        public uint ChannelID { get; private set; }
        public uint PercentProgress { get; private set; }
        public uint TimeRemaining { get; private set; }
        public VFlashStationStatus Status { get; private set; }
        public VFlashStationResult Result { get; private set; }

        /// <summary>
        /// Generate class for each ECU. We get name, project path, and channel ID from LabVIEW
        /// </summary>
        /// <param name="projectHandle"></param>
        public ECU(string Name, string projectPath, uint channelID)
        {
            ECUname = Name;
            ProjectPath = projectPath;
            ChannelID = channelID;
            TimeRemaining = 0;
            PercentProgress = 0;
        }

I then compiled the script to create my own DLL, titled StartFlash.dll. Integrating my wrapper into LabVIEW was simpler since I did not need to worry about the callback delegates.

Call DLL Methods from LabVIEW

There are two ways to call functions wrapped within a DLL: a Call Library Function Node, or an Invoke Node. A Call Library Function is useful when the DLL is a C/C++ DLL, and an Invoke Node is great for C#/.NET assemblies. You can also view NI’s knowledge article, Calling a DLL from LabVIEW, for more details.

In this case, we’ve created a .NET assembly so the correct option is to use the invoke nodes from the .NET palette within LabVIEW.

1. Place a .NET Constructor Node on the block diagram to instantiate a class within the .NET assembly.
   

   

2. Select the constructor by browsing for the desired .NET assembly DLL. For this example, we need the StartFlash DLL I created earlier and my ECU class.
   
   You should now have a constructor node with any required inputs (Name, project path, and channel ID). Wiring controls/constants to these inputs will initialize your class data.
    
   The output of this constructor node is a reference to the newly created class. This reference can now be wired into property nodes or invoke nodes in order to read/write class data or access public methods, respectively.
    

   

   

3. Wire the class reference to the input of an invoke node. You should see it automatically adapt to the reference type wired in.

     
    

   The available methods will automatically be populated based on the class reference. Select the desired method from the method drop-down menu and any inputs/outputs will automatically be created.
    

   That’s how simple it is to access public methods within a DLL. The only thing remaining is to organize the LabVIEW application to call the vFlash methods in the proper order in order to flash up to eight ECUs at a time.
    

   

   One last piece of advice: It’s always important to properly dispose of any references open in LabVIEW. In this case, we need to dispose of our .NET class and our .NET class reference.
    

   

Learn more about DMC’s LabVIEW programming experience.

The post Simultaneously Flash 8 ECUs with LabVIEW and Vector appeared first on DMC, Inc..

Web-based Control and Monitoring

The most appealing aspect of Beckhoff’s platform is that it leverages the internet to allow end users to control and monitor their PLCs from anywhere. Interfacing with industrial controllers via the internet is a common request for DMC, and the TwinCAT HMI makes this easier than ever before with integrated server- and client-side development connecting easily to the underlying PLC access. The key benefit is that a web-based HMI can be accessed from any number of different clients – a traditional monitor screen nearby the device being controlled, a tablet carried around the area by a supervisor, or even a mobile phone halfway around the world. The HMI includes a responsive grid designed to facilitate development for multiple device sizes.

WYSIWYG Web Page Design

As any web developer can tell you, managing the location and arrangement of content on the page can be one of the most time-consuming aspects to do manually. Development for TwinCAT gets around these issues using a What You See Is What You Get style editor, paired with other features to make life easy for developers. Selecting and arranging components is as simple as dragging them in from a menu. The HMI features dozens of prebuilt components, including commonly used displays and controls, as well as advanced charts. We walked through a demo project using several different charts, which update live when linked with the PLC data, making it very easy to display live system data of all sorts to your end users.

Development in Visual Studio

This is a good point to bring up the ease of development afforded by the IDE. Development for the HMI is integrated directly into Visual Studio, which is very familiar to DMC from our extensive .NET development. The Visual Studio pane and menu system’s familiarity makes navigation quick, and Beckhoff’s custom screens are also very easy to use. Integrating development into a widely used and well-regarded editor allows engineers to develop a simple web-based HMIs for their PLCs without requiring extensive knowledge of web technologies. However, developers familiar with web technologies (like DMC) still have access to the generated results, allowing us to tailor a solution to the exact needs of our clients.

Easy Extension and Customization

As mentioned, Beckhoff’s existing framework controls allow for rapid development, especially for simple applications. However, the HMI is also very extensible, allowing for flexible and very custom solutions. DMC took an additional course in designing extensions for custom applications. The extensibility allows for custom Javascript interactive controls, in the case that the provided components don’t quite fit the bill. Further, the HMI allows for custom server controls in C#, which allows us to develop connect to any system, use any library, or employ any custom code from our .NET expertise. The flexibility of these extensions, combined with the ease of creating a simple solution, makes us very excited to work on projects with this new HMI.

Thanks to Zachary Daulton and co. at Beckhoff for hosting us and giving us a preview of the software!

The post DMC Attends Inaugural TwinCAT HMI Training appeared first on DMC, Inc..

While working on a recent Windows application, DMC wanted to add an extra layer of security to our application by protecting our SQL CE database files with a password. Although the process of creating a “.SDF” file from an existing database is simple, there are a few additional steps that are required when adding password protection. 

After finding no good resources on this process anywhere on the internet, I decided to document the process here.

This walkthrough will use the SQL Server Compact Toolbox for Runtime 4.0 which you can download.

Step 1: Create an empty, password protected .SDF file

Right click on No SQL Compact Data Connections Found and select Add SQL Server Compact 4.0 Connection…

A small window will pop up where you will enter your desired password. After your password has been entered, click Create at the top of the window where you will name your new .SDF file. 

Finally, click Close at the bottom of the window in order for your new empty .SDF to be created.

Your password protected .SDF file will now appear on the left-hand side in the main window of the toolbox. 

Step 2: Export your existing SQL Server Database to a .SQLCE file.

Right click on SQL Server Compact Data Connections and select Script SQL Server Database Schema and Data…

A window will popup that requires you to enter information to connect to your existing SQL Server DB. 

Enter the server name and select the database name from the drop-down menu. 

Finally, click Ok and name your new .SQLCE file. 

In the next popup, select the tables from your existing database which you want to export by clicking the appropriate check boxes. This will vary based on your application. 

Step 3: Move the exported data into your new password protected SDF.

Next, right-click on your new password protected DB that has been created on the left side of the toolbox and select Open SQL Editor”. 

An editor will open up on the main part of the screen.

Select Open and navigate to the location of the .SQLCE file you just created.

Once this step is completed, you will see text commands opened in the main window. 

Click Execute and wait for this operation to complete. Once completed, you will be able to verify the operation was successful by expanding Tables in the left-hand side tree view and checking that the correct tables have been added.

SQL Server Database has now successfully been moved into a password protected .SDF file!

As a final note, when using this in your Windows application you must enter the .SDF’s password. Microsoft provides information about how to accomplish this. 

Learn more about DMC’s Custom Software & Hardware development services. 

The post Creating a Password Protected SDF File from an Existing SQL Database appeared first on DMC, Inc..

First of all, this article assumes you know/have the following things:

1. Intermediate C# and .NET development experience or knowledge
2. A license for Revit (preferably 2013 or later) so you can actually test your add-in
3. A license for Visual Studio (I’ll be using 2015 for this example). You can develop Revit macros using Revit’s built-in code editor, but developing add-ins (external commands and external applications) pretty much requires Visual Studio.

The first thing you’ll want to do is set up your development machine. I chose to use a virtual machine (VM) running Windows 8, for reasons that are beyond the scope of this article. Make sure you check the system requirements for the version of Revit that you’re developing for. Install Revit and your chosen version of Visual Studio, and you’re ready to get started.

To create a new Revit add-in, open up Visual Studio and start a new Class Library project.

Visual Studio is kind enough to provide us with a class, named “Class1.cs”.

Either rename it, or delete it and replace it with another class (.cs) file, and make sure the new class is named something that makes sense. I’m naming mine “RevitTutorialExternalCommand”. Once that’s done, we’re going to make our new class implement the interface “IExternalCommand”.

As you probably know, that squiggly red underline means Visual Studio doesn’t recognize that reference. This is because IExternalCommand is an interface from the Revit API libraries. So to use it, we’ll have to add a reference in our project to the Revit API dlls. You can find these in the directory where you installed Revit. The files we’re looking for are RevitAPI.dll and RevitAPIUI.dll. These are the two libraries that you’ll use most often when developing add-ins for Revit.

Once we’ve added references in our project to these files, we can add the line:

using Autodesk.Revit.UI;

to our class file.

Now we still have the red squiggly underline; as you probably guessed, Visual Studio now recognizes the interface name, but it’s warning us that we’re not correctly implementing the interface. In order for our class to implement it, we have to add the Execute method to the class. This method has the following signature:

public Result Execute(
    ExternalCommandData commandData,
    ref string message,
    ElementSet elements)

public Result Execute(
    ExternalCommandData commandData,
    ref string message,
    ElementSet elements)

The access modifier has to be public in order for Revit to be able to run our add-in. This method essentially serves as the entry point for your add-in – this is the equivalent of “public static void Main()”. There’s one more thing we should do before actually writing code – add an attribute that determines the transactional behavior of the external command. This attribute is in the namespace Autodesk.Revit.Attributes, so you’ll want to add that to your using statements. Revit transactions are outside the scope of this article, but the short version is that anything your add-in does to change the file that it’s working with has to be done within the scope of a transaction, so the TransactionMode enum that we supply to the Transaction attribute allows us to decide whether a transaction is automatically wrapped around our entire add-in, or whether we have to manually start and commit Transactions. It’s usually a good idea to use Manual, so that’s what I’m showing here.

Finally, let’s write some code to make this add-in actually DO something. We’ll keep it simple for this first tutorial: we’ll just display a message box for the user.

In the above image, you can see I’ve used a class called TaskDialog’s “Show” method, and passed it two strings as its parameters. The first parameter is the “title” displayed at the top of the message box. The second parameter is the content text of the message box. At the end of our Execute method, we return an Autodesk.Revit.UI.Result, an enum with three possible values: “Cancelled”, “Succeeded”, and “Failed”. We’ll return Succeeded for now.

Finally, we’ll build our solution, start Revit, and try it out.

But wait, there’s a problem… When we have add-ins loaded, there’s supposed to be an “Add-ins” menu tab at the top, right next to “Modify”. You can see in the above picture that it’s not there. This is because we haven’t actually deployed our add-in so that it can be loaded by Revit. We need to do two things to make this happen: 

1. Write an add-in file (an XML file with a “.addin” extension) that Revit reads when it starts up in order to determine which add-ins are to be loaded
2. Build our project to produce a dll file, and place it somewhere accessible (we’ve already done this one)

Let’s go ahead and write that .addin file. You can do this using Notepad, Notepad++, or any other text editor. When creating the file, you need to put it in the add-ins folder for your targeted version of Revit, which can be found at C:\Users\[YOUR USERNAME]\AppData\Roaming\Autodesk\Revit\Addins\[YOUR REVIT VERSION YEAR]. So for me, it’s C:\Users\Christopher Olsen\AppData\Roaming\Autodesk\Revit\Addins\2014. The AppData folder is usually hidden by default, so you’ll have to make sure Windows Explorer is configured to show hidden files and folders.

As mentioned before, this .addin file is in XML format.

Our root element here is the RevitAddIns tag. Within this tag, you’ll place one or more Addin tags (yes, you can use one file to specify multiple add-ins for Revit to load). The “Type” attribute on the Add-in tag is for specifying what kind of add-in this is. The two most popular options are “Command” and “Application”. Since we’ve written an external command (as indicated by the fact that we used the IExternalCommand interface), we’ll use the “Command” value for this attribute.

Nested inside the AddIn tag, we have several important elements. The Text tag is where we specify the display name for our add-in in the “External Commands” drop-down menu in Revit. The Assembly tag must contain the file path to the dll for our add-in – in this example, I’ve pointed it toward the dll file in my project’s obj\Debug folder in order to make testing and debugging easier. AddInId is essentially the ID of your add-in, and must be unique for a session of Revit – the best way to do this is to generate a new GUID in visual studio (you can do this by going to the Tools menu, and clicking on “Create GUID”. You don’t have to put this GUID in your code somewhere, but it’s common practice to place it in a comment right above your class definition.

Next, we have the FullClassName tag, which must contain the namespace and class name for your external command. The VendorID tag is required, and is supposed to be unique for a given session of Revit – Autodesk recommends using the url of your company’s website. Finally, VendorDescription is a more verbose description of your company – if your external command throws an unhandled exception, Revit will display an error message on screen that ends with “For more info, contact this knucklehead that developed the add-in: [VendorDescription]”. I’ve paraphrased the actual text of the error message, for comical effect.

And that’s it. There are many more things we can specify in that .addin file, but these are the core ones you’ll really want to use. Other tags you can add to this file include the path to an image that will be displayed for your add-in in the external command drop-down menu. For a full run-down, check out the table on Autodesk’s knowledge base website.

Now, if we open Revit, we see that the “Add-Ins” tab has been added, and clicking on the “External Tools” drop-down shows us our add-in. If we click on it, our external command’s “Execute” method runs, and we get our message box.

Now that we’ve got the super basic stuff out of the way, we can turn our attention to doing something meaningful in a Revit add-in. In my next blog post, we’ll go over how we can have our user select elements, and how we can then perform operations on those elements.

Learn more about how DMC can help you develop custom software.

The post The Revit API: Creating Your First Add-In 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..

Fortunately, pulling data from the AD and using it in your application is much easier than you might think, and allows you to maintain data integrity by keeping your data in just one place. Also, SharePoint developers will be happy to learn that the AD can be queried from within a SharePoint add-in with the same code that I’ll be sharing here.

First, let’s have a brief review of what the Active Directory (AD) is:

The AD is, for the purpose being discussed here, basically a database, except that its storage is hierarchical in nature. The data it stores typically regards the different components in a computer network. For example, a very common use of the AD is to store various pieces of information about a user (email address, name, phone number, title/job description, etc.) It may also contain data about user groups, such as the marketing department, IT, etc.

Getting Started

The first thing you’ll need to do is figure out what your AD domain path is. Also, if you’re querying the AD from within a SharePoint add-in, you’ll need to make sure that the user under which the Add-in web service is running has the proper permissions to access the AD.

And finally, it should be said at this point that you’ll need to use a few .NET assemblies that you may have never touched before:

using System.DirectoryServices;

using AD = System.DirectoryServices.ActiveDirectory;
using AP = System.DirectoryServices.Protocols;
using AM = System.DirectoryServices.AccountManagement;

using System.DirectoryServices;

using AD = System.DirectoryServices.ActiveDirectory;
using AP = System.DirectoryServices.Protocols;
using AM = System.DirectoryServices.AccountManagement;

Example: Getting User Info

Something I often find myself having to do is get a list of all users in the AD, along with some piece of data associated with them. In this example, we’ll be building a Dictionary that associates each user with the name of their manager.

First, let’s show you the code, then we’ll explain it.

After we’ve declared an empty dictionary, and retrieved our current path, we go ahead and create an instance of the DirectoryEntry class, passing our domain path as a parameter to its constructor. It should be noted that most of these DirectoryServices classes implement the IDisposable interface, meaning that we need to make sure we dispose of them after we’re done using them. To make this easier, of course, we utilize “using” statements here, so that our unmanaged resources automatically get released.

Next, we pass our DirectoryEntry as a parameter to the DirectorySearcher class constructor. The DirectorySearcher class’ main purpose is to allow us to query the AD.

Now that we have our DirectorySearcher instance, the wise thing to do is to use a filter to narrow our search results – if we skip this step, we sacrifice performance. So we assign to the DirectorySearcher’s Filter property a string that represents an LDAP query. In this case, our query “(&(objectCategory=User)(objectClass=person))” returns only objects that are in the User category and that implement the “person” class.

Now, for a given AD object, there can be dozens or even hundreds of properties. So to save on performance, we only want our query to return those properties which we’ll actually be using. To do this, we add property names as strings to the PropertiesToLoad property of our DirectorySearcher. Finally, we execute the query by calling the FindAll method of the DirectorySearcher. This returns a SearchResultCollection.

Iterating through this collection gives us access to SearchResult class instances. To avoid a null reference exception, I like to ensure that each SearchResult actually has the properties that I’m looking for. After that, getting our values is a simple matter of accessing the Properties property of the SearchResult with a string indexer. In this case, both are properties are simply strings, so I only want to return element zero, but if the property I was querying were an array, I would probably be iterating through it or doing some other operation.

So the final step here is to add the value of our user’s display name and the value of the “manager” property as a KeyValuePair in my Dictionary, and move on to the next SearchResult. Once we’ve iterated through the entire collection, we can simply return our Dictionary.

Learn more about our Microsoft Consulting Services

The post Querying the Active Directory 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..