I was part of a team that developed a generic library to represent all Media topologies - Topology Builder. The Topology builder library essentially does the following:

a. Helps transform any given Media topology into a Directed Graph.

b. Helps serialize this graph into a JSON string

c. Helps de-serialize the JSON back into a Directed Graph

Building the graph

The Directed Graph (with cycles) implementation was such that it was a collection of vertices. Vertex creation and deletions were managed by a memory pool. Each vertex had:

- a unique identifier

- list of neighbors

- a name attribute

- list of properties associated with the vertex. Each property in the vertex was a key-value pair of GUID and PROPVARIANT.

The public interface for building the directed graph exposed the following methods:

- ability to add a vertex

- ability to associate a set of properties to a vertex

- ability to add an edge from one vertex to another

- ability to serialize the graph into a JSON string (explained below)

Graph serialization

The serialized graph would be represented as a JSON string. We picked JSON to be the format for serialization since JSON is a well know format and there are standard libraries available for JSON writers and readers. We picked a C++ implementation for JSON writer four purpose. For an example of a sample topology representation in JSON, please look at the attached file in this blog.

JSON de-serialization

We used JsonObject present under Windows.Data.Json (https://msdn.microsoft.com/en-us/library/windows/apps/windows.data.json.jsonobject.parse.aspx) namespace in .NET for de-serializing the JSON into:

a. a class

b. a DGML representation for debugging (https://en.wikipedia.org/wiki/DGML)

c. a Database representation for statistical analysis

Here's an example view of a Topology JSON de-serialized into DGML:

The entire implementation was a combination of C++ and C# modules.

- Topology builder graph was a C++ implementation

- JSON serialization was a C++ implementation

- JSON de-serialization was a C# implementation

The was highly performing solution with respect to memory and execution time. The space and time complexity of building a Windows Capture Topology could vary between 6 KB (~1 ms) - 17 KB  (~3 ms) for building the graph and serializing it.

TopologyJSON.zip

Example: Normal USB cameras generally expose 1 pin (Preview) , H264 cameras expose 2 pins (1 for Preview and 1 for Record), SOC cameras expose 3 pins (independent Preview, Record and Photo capture).

MediaCapture default mapping of Single pin camera - Media Streams

MediaCapture default mapping of 2 pin camera - Media Streams

MediaCapture default mapping of 3 pin camera - Media Streams

MediaCapture exposes a way to determine this pin independence information. This will come in handy when you are adding effects to a Media Stream and when you don't want any effects to be applied inadvertently to a stream that you didn't desire to apply.

Let's take an example: Say your intension is to apply a custom effect (using AddEffectAsync) to a Photo stream while taking a Photo when Preview and Recording are in progress. For your same code, the behavior will vary when you run your application on a machine with a USB camera attached vs. a machine with H264 camera attached vs. on a SOC device like a Phone or tablet. On a machine with USB camera, your effect will be applied to Preview, Record and Photo. On machine with H264 camera, your effect will be applied to Preview and Photo. On Phone or Tablet, your effect will be applied to Photo only. 

So determining Pin dependence will be helpful in some scenarios. You can use MediaCapture.MediaCaptureSettings.VideoDeviceCharacteristic to determine this behavior: https://msdn.microsoft.com/en-us/library/windows/apps/windows.media.capture.videodevicecharacteristic.aspx

Mirroring is one of the best ways in which you can achieve fault tolerance in a distributed data store environment.  There are various operations around mirroring that are critical and need to be dealt with cautiously. The following few sections discuss some of the validations that a user can perform around these mirroring operations.
a. Setting up mirroring
b. Changing failover options
c. Failing over
d. Breaking up mirroring
e. Changing mirroring port

If you want to look at the entire paper, it is attached to this blog.

Validations around Mirroring setup

Validations around changing "Failover" mode - Changing the failover mode from "Manual" to "Automatic"

“Manual” to “Automatic” failover mode change requires the setting up of a new SQL server as Witness. You can read in detail about setting up a Witness at: https://technet.microsoft.com/en-us/library/ms365603.aspx . You can change the failover mode from “manual” to “automatic” ONLY on the Primary SQL server

Validations around changing "Failover" mode - Changing the failover mode from “Automatic” to “Manual”

Changing the failover mode from “Automatic” to “Manual” simply involves removing the Witness server from the mirroring relationship. You can remove the Witness server either from the Primary or the Secondary. Here are a few validations that you can perform before you change the failover mode from “automatic” to “manual”

Validations around "Failover"

Validations around breaking up mirroring relationship - "normal break up"

 This is the normal breakup scenario where you might want to breakup mirroring when the Primary and Secondary SQL servers are connected. Here is a list of validations that you can perform before performing a breakup.

Validations around breaking up mirroring relationship - "force break up"

There could be situations where the Secondary is in disconnected state. This might happen when the Primary goes down in a “manual” failover mode and “Primary” and “Witness” go down in an “automatic” failover mode. If your Primary and Witness are not in recoverable state, you might want to breakup mirroring and bring the existing Secondary server to process all connections in a standalone mode. Note that this might lead to a data loss [https://msdn.microsoft.com/en-us/library/ms189977.aspx].  

Validations around modifying the mirroring port

Let us say that you want to change the port related to the mirroring endpoint on the Primary or Secondary SQL server which you have already created. Now you need to ensure the following:

a. For databases that are not mirrored on your Primary/Secondary, there is nothing much to worry about
b. For databases that are mirrored, once you change the mirroring endpoint port, the database goes into a disconnected mode since the TCP connection is broken. Now you need to make sure that you re-establish mirroring partnership between the Primary and Secondary for these databases so that they get back into connected state

SQL Mirroring Best Practices.docx

I had a Public class called “Details” in my webservice and I had a method which would return an ArrayList of objects of type “Details” to the client. But I could never access the class “Details” from the client.

Here is what I finally did:

I had a webservice called TestWebService which had many public classes in its namespace. Here is how the namespace looked:

namespace Test.TestWebService

{

    public class Details

    {

        public Details() { }  

        ...

    }

    public class TestWebService

    {

        ...

       [WebMethod]

 public ArrayList GetDetails()à Client couldn’t access the class “Details”

       public List<Details> GetDetails()à Client could access the class “Details”

       {   

            ArrayList list = new ArrayList(); 

            List<Details> details = new List<Details>();

            ///Do all processing

            ///Let us assume that this "list" gets filled up dynamically

            ...

            return list; à Client couldn’t access the class “Details” 

            return details; à Client could access the class “Details”

         }

    }

}

So on the client side (after changing the return type) I tried to access the method this way:

test.TestWebService svc = new ConsoleApplication3.test.TestWebService();

test.Details[] details = svc.GetDetails(1);

So basically I could never access “Details” from my client until it got used somewhere in the web method signature (either as an input parameter or as a return value).

Hope this helps.

Let us say that you have written an application (let's call is Foo.exe). Now let us say that Foo.exe logs some information and it requires the log file location to be passed in as an input via configuration info.

So, here is what you could do. 

1. Add an Application Config file to Foo.exe (You could do this on Visual Studio via Add > New Item > Application Configuration File). Let us call it Foo.config

2. Open Foo.config. It'll look something like this:

<?xml version="1.0" encoding="utf-8" ?>

<configuration>

</configuration>

 3. Add the following lines into Foo.config between the <configuration> </configuration> tags:

<appSettings>

<add key="LoggingFile" value="C:\Logs\Foo.log" />

</appSettings>

 Where the key " LoggingFile" is the key, querying the value of which will fetch you the log file path.

4. Now within your application, here is how you can fetch the value of " LoggingFile":

using System.Configuration;

string logFilePath = ConfigurationManager.AppSettings["LoggingFile"]

Wasn’t that easier than writing your own XML based config files and a parser to fetch the values from it? Hope this helps.

Trust me, using a COM dll in a C# program is far simpler and relieves you of all those ref counting hazzles. Managed code even simplifies the standard COM function calls to QueryInterface, AddRef etc. Making a QueryInterface call is as simple as casting an object of type A to type B and you don't have to make any calls to AddRefs and Releases!

There are 3 simple steps to using your C++ COM dll in your C# program.   

Step 1: Generate a managed COM wrapper dll for your C++ COM dll (let us call it MyComDll.dll). Let us call the generated dll as MyManagedDll.dll.

Step 2: Use the generated MyManagedDll.dll in your C# application (let us cal it MyDotNetApp.exe)

Step 3: Register MyComDll.dll 

Step 1: Generating a managed com wrapper

The first step is to generate a Managed wrapper for MyComDll.dll so that you can add it as a reference into your MyDotNetApp.exe project.

·         If you have been building this COM dll all by yourself, then build your IDL solution separately. This will generate a .TLB file once the compilation succeeds. In this case when we build MyComDll.IDL we get a MyComDll.TLB.

·         Visual Studio 2005 ships with a tool called TlbImp.exe. This tool uses your .TLB file and generates a managed wrapper for it. In this case, when we run Tlbimp.exe on MyComDll.TLB, we will get a managed dll. This is MyManagedDll.dll of which we spoke above.

      You can read more about Tlbimp.exe at https://msdn.microsoft.com/library/default.asp?url=/library/en-us/cptools/html/cpgrftypelibraryimportertlbimpexe.asp.

By the end of step 1, you are all set to use the generated managed dll in your MyDotNetApp project!

Step 2: using the managed com wrapper in your application

Now let us see how we can use the built managed COM wrapper dll in your MyDotNetApp project.

Open your MyDotNetApp project and add this built MyManagedDll.dll as a reference and add the reference in your .cs file via the using keyword. Something like:

using System.Runtime.InteropServices;

using ComDll;

Now you create an instance of the public class exposed from your COM dll (let us call this class as MyAppClass) by doing the following:

MyAppClass application = new MyAppClass();

This will do the CoCreateInstance equivalent part of your COM dll and return you an instance based on its UUID.

Now you are all set to interact with the interfaces of your COM dll. Here is how you do QueryInterface: if you want to query Interface A from a class B, then here is how you do it:

IMyAppA settings = (IMyAppA) myAppBObject;

Step 3: registering your com dll before use

Now, COM dlls either need to be registered or not before they can be used depending on whether it expects a manifest file or not.

If your COM dll is built in a way that it expects a manifest file, then please keep the .manifest file in the same location where your application binary and the dll both reside. In this case when you build MyDotNetApp solution file, VS will create a MyDotNetApp.exe.manifest file for you. The contents of this file will be something like:

<? xml version="1.0" encoding="UTF-8" standalone="yes" ?>

<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">

      <assemblyIdentity version="1.1.0.0" processorArchitecture="x86" name="MyDotNetApp.exe" type="win32" />

<dependency>

<dependentAssembly>

<assemblyIdentity type="win32" name="Microsoft.VC80.CRT" version="8.0.50608.0" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b" />

         </dependentAssembly>

  </dependency>

<dependency>

<dependentAssembly>

<assemblyIdentity version="2.0.0.0" processorArchitecture="x86" name="MyComDll" type="win32" />

</dependentAssembly>

</dependency>

</assembly>

So, make sure that you keep MyDotNetApp.exe.manifest, MyDotNetApp.exe, MyManagedDll.dll and MyComDll.dll all in the same location before you run.

Instead, if your COM dll is built in a way that you need to register it before you can instantiate the class, then make sure that you register it on the machine where you are planning to run the application (under HKCR\CLSID\{…}\ InprocServer32 \). Make sure that you give the correct location where MyComDll.dll resides on your machine in the registration path.

You can read more about manifest files at: https://windowssdk.msdn.microsoft.com/en-us/library/ms717746.aspx

Run your application!

I wanted to make a client-server application that would run both on WinCE/Windows Mobile 5.0 PPC/SP and Windows.

Here is what I wanted to make:

§         A Server EXE which would have to run, both on a Win CE based device and on a Desktop machine.

§         A Client EXE which would talk to the Server. The scenario involved running several instances of client EXE running both on Desktop and Device.

The obvious choice was to write a common Server/Client code which would run both on Device and for Desktop.

So I started looking at the various IPC options that both WinCE and Windows provide to come with an intersection set and then finally choose one of the options from the set.

Surprisingly the intersection set was really small. L

Here is the result of my study.

IPC mechanisms	Windows	Win CE	References
DCOM	Supported.   Provides an option to run the Server as a OUT PROC COM component	Not Supported.   DCOM is an optional component. So you might run into the risk of not able to run your server EXE on the device.	WinCE: https://blogs.msdn.com/cenet/archive/2005/07/13/438424.aspx
File mapping/Shared memory	Supported.   File mapping is supported on Windows platform and you can use this via CreateFileMapping, MapViewOfFile, ReadFile, WriteFile APIs.	Partially Supported.   File mapping is also supported by Win CE, but there is a caveat to it. Here is what MSDN has to say:   “This function will not work on a Windows CE–based platform that does not support Page-In.”	WinCE: https://msdn.microsoft.com/library/default.asp?url=/library/en-us/wcesdkr/html/_wcesdk_win32_createfilemapping.asp (Read the Remarks Section)
Message Queues	Not Supported.   Windows does not seem to be supporting this. At least the MSDN documentation does not list this as a possible IPC mechanism.	Supported.   WinCE supports Message Queues.   You can use the CreateMsgQueue, WriteMsgQueue etc APIs to achieve it.	Windows: https://msdn.microsoft.com/library/default.asp?url=/library/en-us/ipc/base/interprocess_communications.asp
Pipes	Supported.   Windows supports it via CreateNamedPipe, WriteFile, ReadFile etc APIs.	Not Supported.   There is no support for Pipes specifically on WinCE.   But they claim that a point-to-point message queue can be regarded as some sort of pipe.	WinCE: https://msdn.microsoft.com/library/default.asp?url=/library/en-us/dncenet/html/intercommWindowsCENETInterprocessCommunication.asp (Read the Abstract section)
MailSlots/Mailbox	Supported.   Desktop calls this Mail Slots. Take a look at: CreateMailslot, WriteFile, ReadFile etc APIs.	Not Supported.   The Mail Slot APIs are not supported on WinCE.   But there is an implementation of one-way “Mailbox” concept described in MSDN.	Win CE: https://msdn.microsoft.com/library/default.asp?url=/library/en-us/dncenet/html/intercommWindowsCENETInterprocessCommunication.asp
Sockets	Supported	Supported

Looking at all the possible options, I finally felt that Sockets would be the best way to go. Since I had so many device platforms to support, I did not wanted to take the risk of choosing something that works on Desktop and the same thing not working on even one of the Device platforms.

This is just my observation. Please let me know if there is any other option that I have missed out. Hope this helps.

Delegates hold the references/addresses of functions so that the functions can be invoked in a call back manner. If you are familiar with C++, they are just like function pointers. Here is one example of how delegates can aid in structuring your test cases.

Objective

Let us say that you have developed a text editor called Editor+ which is the next version of already developed application called Editor.  Now your goal is to test backward compatibility, i.e. Editor+ should be able to open and modify files that were created using Editor.

To achieve this goal, we need to perform the following 2 tasks:

Task 1: Have a repository called Version 1 Files, which will contain files that were created using

            Editor.

Task 2: Make an application that will:

a.       open each file in this repository

b.       make different kinds of modifications to the contents

c.       save and close the file.

So, you have a set of input, which is constant. But each test case needs to perform a different action on this set.

Performing Task 1

Making the repository is a 1 time job. You can either do it manually or make it using some tools.

Performing Task 2

The application will comprise of mainly 2 components.

1.       A generic class called Reader which will implement the logic of opening each file from the repository, perform the required set of modification, save and close the file.

2.       Test cases which use the Reader class and implement the actual set of modification as per their requirement. Example of a few test cases could be like the following:

TestCase1: Add letter “x” in the beginning of each file in Version 1 Files using Editor+

TestCase2: Delete the last line in each file in Version 1 Files using Editor+

Reader class

Let us define a class called Reader, which can do the following:

·         Provide a function which can recursively look at each file in repository Version 1 Files

·         Open the file

·         Modify the file according to the user’s request

·         Close the file

Here is the pseudo code implementation of such a function in Reader class

Function WorkOnFiles (“Version 1 Files”)

{

     For each file in directory “Version 1 Files”

     {

           Open (File)

           Modify (File)

           Close (File)

     }           
}

The logic of opening and closing each file will be the same for all the files and can be left to the Reader class. But the challenge comes in handling the Modify function since each test case wants to modify the files in a different way. Like the first case wants to “add ‘x’ at the beginning of the file” whereas the other wants to “delete the last line” in the each file.

Using delegates we can handle such a situation. You just need to define the “Modify” function as a delegate in Reader class so that each test case can initialize this with its own implementation of modify function. Just add the following lines in your Reader class.

/// <summary>

/// Delegate that defines the function which will be used to

/// “Make Changes” to a document

/// </summary>

/// <param name="filehandle">The file handle</param>

/// <returns>success/failure</returns>       

public delegate bool modify(Object fileHandle);

private modify  modifyFunction;

/// <summary>

/// Get/Set actions for ModifyFunction so that the test case can call it

/// </summary>

public modify ModifyFunction

{

get {return modifyFunction;}

set { modifyFunction = value;}

}

With the introduction of delegate, the WorkOnFiles function in the Reader class will look like the following.

public bool WorkOnFiles(string directoryName)

{

     bool result true;

     DirectoryInfo info = new DirectoryInfo(directoryName);

     FileInfo[] files = info.GetFiles();

     foreach(FileInfo file in files)

     {

         //Open the file

   object fileHandle = OpenFile(file.Name);

         //Do error handling for the returned file handle

         //object        

   //Call the function specified by the test case that makes

   //changes to the file

         result &= ModifyFunction(fileHandle);

         //Call the function that closes the file

         CloseFile(fileHandle);

     } 

          …

          return result;

}

Test Case logic

Your test case can now provide its own customized Modify function according to its need. Here is how your test cases would initialize the Reader class and use it.

/// <summary>

/// Test case which goes thru each file in a directory,

/// opens each file, adds 'x' in the beginning of the file,

/// saves and closes.

/// </summary>       

public result TestCase1 ()

{

      Reader myReader = new Reader ();

      //The function which will add 'x' at the beginning

      myReader.ModifyFunction = MyAddX;       

      ...

      //Call the function which will recursively open, modify and

      //close the files

      myReader.WorkOnFiles(“Version 1 Files”);

      ...

} 

/// <summary>

/// Test case which goes thru each file in a directory,

/// opens each file, deletes the last line of the file,

/// saves and closes.

/// </summary>   

public result TestCase2 ()

{

      Reader myReader = new Reader ();

      //The function which will delete the last line

      myReader.ModifyFunction = MyDeleteLastLine;  

      ...

      //Call the function which will recursively open, modify and

      // close the files

      myReader.WorkOnFiles(“Version 1 Files”);

      ...

}

/// <summary>

/// Sample MyAddX function

/// </summary>   

public bool MyAddX (object fileHandle)

{

       bool result = true;

       …

       return result;   
} 

/// <summary>

/// Sample MyDeleteLastLine function

/// </summary>   

public bool MyDeleteLastLine (object fileHandle)

{

       bool result = true;

       …

       return result;   
} 

(This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at https://www.microsoft.com/info/cpyright.htm)