In our last post, we set up our Microsoft Azure account and created a search service.  In this post, we will create a project in Visual Studio, will create a test to populate our data, and then we will create a simple ASP.NET MVC project to do a simple search of the data.

You can follow along here, or you can pull the project with the BlackBarLabs.Search.Azure project.  This project in its entirety is available as BlackBarLabs.Search.Azure.Sample from Github.

To get started, lets create a new ASP.NET Web Application project in Visual Studio called AFDSearch.


And let’s choose MVC with No Authentication:


The first thing that we want to do after our project is created, is create a new test project.  We will write a simple unit test to read information from a csv file and use this to populate our search index.  Right click on the Solution node in the Solution Explorer, click Add, click New Project, select Test\Unit Test Project, then rename the project to AFDSearch.Test and click OK.


Let’s do some renaming in our test project.  First, select the default test file, “UnitTest1.cs.  Right-click and rename it to “DataImportTest.cs”.  In the test file itself, rename “TestMethod1” to “ImportData”.


Now let’s go add the BlackBarLabs.Search.Azure library to our solution.  You will need to clone the library in from Github.  You can see all of the BlackBarLabs libraries at, but the specific one we want is at  Clone this library to your machine.

Right-click on the AFD Solution and Add\Add Existing Project…  Select the BlackBarLabs.Search.Azure.csproj file and click OK.  You will now see that the BlackBarLabs.Search.Azure library is in your solution.


Go to the AFDSearch.Test project and add a reference to the search library:


While there, go ahead and add a reference to Microsoft.VisualBasic.  We will use this library to parse our data source csv file.  Also add a reference to System.Configuration.  We will use it to read from the config file.

Next, add an App.Config file to the AFDSearch.Test project.  Right-click on the project, select Add\New Item…  In the dialog, select “Application Configuration File”.  Just stick with the default name of App.config and click OK.  Now, in that file replace the contents with this:

Now, using the name and key you saved from when you created the search service in the Azure Portal earlier, replace the service name and api key values.  Save and close this file.

Now that we have the config file set up, let’s set up our data file.  Right-click on the AFDSearch.Test node and click Add\New Item…  In the dialog, select Text File and rename the file to airports.csv.  Click Add.   This is very important – right-click on the newly created airports.csv and click Properties.  In the properties dialog, change Build Action to Embedded Resource.

Now, copy the following contents into the airports.csv file.  Click save and close the file.

We will now edit our DataImportTest.cs file such that we can use the ImportData test to read from the airports.csv file and import its data into our search index named “airports”.

Let’s get started by setting up the test initialization.  Bear in mind that this isn’t really a test.  We’re just using the Microsoft test framework to help up bootstrap up our importer.  This could just as easily be done through a simple console app, but the test is a simple solution that we will employ.

Paste the following code before the ImportData test:

When our importer tests fires up, it first runs this code.  This code will go out to our App.config file, get our settings, create a search engine, and load up our csv of data into a stream in memory.

Next, paste this code into the ImportData test function.

This code is a little more interesting in that it sets up a list of tasks to be executed.  These tasks are run as the file is parsed, indexing each airport as it goes.  Note also that the indexer will call back to have us create the index if it is not yet there, which will be the case the first time we call the indexer.

When we call the indexer, the BlackBarLabs.Search.Azure library is doing some pretty cool stuff for us for free.  What you won’t realize when the test is run is that when the indexer is being created, subsequent calls to add items to the index will cause an error to be returned from Azure telling the library that the index is still being created.  In this case, the library will continue to try until Azure finishes creating the index and frees up.  Then it the library will ensure that the document is properly indexed.

As a last step in the test class, paste in the supporting code for the import below the ImportData function:

This code is supporting code to parse out the csv and to set up the search index. What you will find most interesting is the AirportFieldInfo class.  This class contains an array of SearchFieldInfo objects.  These are used in defining the fields of our search.  Here, you set fields as key, searchable, filterable, sortable, facetable, and retrievable.  We will discuss these attributes more later and they are documented by Microsoft here.

On final step is that we need to define the Airport class in the AFDSearch library and we will need to reference AFDSearch in the test.  Expand the AFDSearch project node and go to the Models folder.  Right-click on the folder and select Add\New Item…  Select Class and name the class Airport.cs.  Replace the contents of Airport.cs with the following:

Now go back to AFDSearch.Test, right-click on References, and add AFDSearch as a project reference.  This will resolve the Airport model.

At this point, the code should be good to go and you should be ready to import the airport data into the search service that you created on Azure.  Go ahead and run the test.  As it runs, you can look at the search index at  If you continually close and reopen the blade (at present there isn’t a refresh, which is a bit annoying, so you have to close the blade and reopen to refresh).  Eventually, you will see your new airports index.


If you continually refresh by opening and closing this blade, you will eventually see the Document Count rise to 982, the number of airports in our source file.  This number will climb to this count as the test runs.  Don’t be alarmed – the test will finish and the count will still be climbing in Azure.  This is because the indexing process will take a bit longer to complete in Azure, even after your test finishes.

When you get to 982 documents, click on the airports index line.  This will open up another blade to the right.  On this blade you can see a listing of the fields in our index.  At the top, you will see the Add/Edit Fields button.  Clicking on this opens another blade where you can examine the fields and their properties that we set when we created the index.


Close the fields blade and click on Search Explorer.  This will open up the explorer to the right.


In the query string, type in something to search for.  I like to type in the airports I have flown out of.  Try “HSV”, “BNA”, “MDQ” (without the quotation marks).  For each string, when you search, you will see the data input for each airport in the explorer.


Congratulations!  You can see that you have created a search index on Azure, have populated it with data, and can now query that data via the Azure Portal’s Search explorer tool.  In our next post, Microsoft Azure Search – A Practical Introduction – Part 3, Basic Search, we will use the BlackBarLabs.Search.Azure library to do simple text-based searches of this data.