Twitter Feed Popout byInfofru

Adventures in .NET Software Craftsmanship!

Back From The Dead - BlogEngine.NET

Ok, so it has been four years since I wrote a blog post, time does fly when you are writing code and chasing deadlines. Anyway, lately I have been feeling the need to revive my blog, most importantly because I have caught the writing bug again and also because I am extremely excited about how the software technology landscape is looking these days, but more about that later.  I wanted to focus on what I had to do to get my blog up and running again.  

Staying with BlogEngine.NET

My original blog ran on BlogEngine.NET version 1.6.1, these days there are a lot of better options if you are starting from scratch or upgrading your blog, but mostly out of curiosity and seeking the path of least resistance I decided to stay on BlogEngine.NET and upgrade to version 3.2.  The latest version of BlogEngine.NET provides a modern, responsive look and feel that allows readers to use a vast range of mobile devices to browse the content of this site.  At the end of day, this was really all I was looking to achieve in this effort, to make sure that the site no longer looked like a Web 2.0 website and that it adhered to modern web design standards.

How I made it work?

Upgrading from BlogEngine.NET was relatively straight forward. I followed the instructions provided at the following link and ran into very few issues. I did not migrate my custom content, scripts, theme, or styles as I intended to switch to a more modern theme.

Upgrading Blog Engine

Important Make sure you run all database scripts necessary to upgrade your database. Including those on the root /setup/[dbengine]/ folder.


Since I did not migrate the original theme the website did not render on the first attempt. Figuring out the problem was not trivial, but the only thing I needed to do was update the settings for BlogEngine.NET by running the following database script to change the theme back to the default. 


I am very satisfied with the end result. I did do some additional work that I will be posting about in the near future.  Additional work worth mentioning: Enabled Disqus as comment platform, added support for embedded Gist via a BlogEngine.NET extension, added a Social Bar that allows readers to share posts across the traditional social networking platforms (Facebook, Twitter, LinkedIn, and Google+).


Rumble Radar Released!

Recently, motivated by the launch of Windows 8 and the recent seismic activity on the Mid-Atlantic region.  I began to work on a very simple project, a Windows 8 Store application that showcases recent significant seismic activity worldwide using the data provided by the United States Geological Survey (  I am proud to announce that the first version of my app “Rumble Radar” is available now for download from the Windows 8 Store. 


Click here to download:

- Geocodes and groups significant earthquakes, as designated by USGS, for the past 7 days.
- Color encodes earthquakes using alert level, as assigned by USGS.
- Links to detail information at USGS Website. 

Roadmap/Future Enhancements
- Expand dataset to include all earthquakes of magnitude 2.5 and greater for the past 30 days.
- Interactive map of all earthquakes.
- Generate date based statistics per region.

WinJS: Do I have internet access?

Odds are the new shiny Windows Store application you are writing will pull some information from the internet for your users to consume.  In fact, the default templates that Microsoft provides already make that assumption. That makes it very likely that you will want to know if the device your application is running on has an active internet connection.  Well Microsoft provides us with a very rich Network API (click here for more info) that you could use to answer such a question. But if want to write less code or want to provide an abstraction layer from WinRTs API, then you could write something similar to this: 

A very basic sample would look like:

Or my favorite style:

TIP: Nokia Lumia 920 Internet Sharing //Build

Disclaimer: This post does not imply that the Internet Sharing feature will only work if you have the Spanish keyboard installed. It only implies that the build on the Windows Phone 8 devices handed out at //Build/ had an issue that prevented users on the ATT network to use Internet Sharing. My guess is that by adding a keyboard (any keyboard probably) to the device we are also triggering an update that solves the Internet Sharing issue.  

Update (11/26/2012):  If the issue happens again installing another keyboard does the trick (I used Vietnamese).

I was very excited to receive a Nokia Lumia 920 while attending the //Build conference last week, but was extremely disappointed that the Internet Sharing feature was not working even though my ATT plan supported it. Obviously, that was one of the first things I wanted to do since I wanted to share the Data Plan on the device with my brand new Microsoft Surface.  Well, by sheer luck, I was able to get it to work just follow the instructions bellow to enable it on your //Build Nokia Lumia 920 device: 

1) Go to Settings
2) Go to Keyboard
3) + Add Keyboards
4) Select Spanish (Spain)
5) Click on the checkmark icon to install.

The only reason why I found this workaround is because I write a lot of messages to my family in Spanish and I hate the fact that the English keyboard tries to autocorrect Spanish using an English dictionary as I type. But, little did I know that it was going to have this wonderful and unexpected side effect. 

Automating EF 4.3.x Data Migrations in your Build

I was asked to clarify what I meant by “some combinations of parameters not working” so I took it upon myself to rewrite the post to be a bit more specific about the problems that I had when using the migrate.exe tool.

If you are looking for a way to automate the execution of your Entity Framework data migrations in your build process the data team has provided us with a command line tool, migrate.exe,  that exposes all the commands available to us in the Package Manager Console in Visual Studio.  The tool is already conveniently part of the Entity Framework’s NuGet package tool folder.  the tool works as advertised, but it does have some quirks, but first let me show my two favorite ways to utilize the tool. If you are totally new to EF data migrations do visit David Hayden’s blog post with a very basic tutorial on the topic which is simple and to the point, or visit Pluralsight and purchase Julie Lerman’s amazing 1 hour tutorial on the topic (see the details here).

Two ways to use Entity Framework’s Migrate.exe
Option 1 – Reusing the app.config

This is the most straight forward option as you are reusing the settings in your applications app.Config to execute the migrations from the command line so the margin for error is relatively small.  The downside is, if you have different connection string settings for all the different environments you want to target with the database migration tool then you will have to come up with a strategy to modify the settings of the app.Config, one possible solution is, if you are working on top of a Web Application project, like an MVC application, you could use web.config transformations during the build process to change application settings.

@rem run_db_migrations.cmd
SET CurrentPath=%CD%
SET ConfigFile=%CurrentPath%\Data\App.config
SET MigrateExe=.\packages\EntityFramework.4.3.1\tools\migrate.exe

%MigrateExe% Data.dll /StartUpDirectory:%CurrentPath%\Data\bin\Debug\ /startUpConfigurationFile:"%ConfigFile%"

The following table explains the data being passed to the command line tool.

Options Comment
Data.dll The assembly with the DbContext and migrations to be executed.
/StartUpDirectory This is the directory where your assembly is located.
/startUpConfigurationFile This is the path to the configuration file that holds the connection string to be used.
/verbose [Optional] use this option to have the tool output all SQL being executed or generated to the command console.


Option 2 – No app.Config

This is by far my favorite approach as you will not need to write complex scripts to modify your app.Config to accomplish targeting multiple environments. I don’t believe there is really a downside to this approach. 

@rem run_db_migrations.cmd
SET StartUpDirectory=%CD%\Data\bin\Debug\ 
SET ConnectionStringProvider=System.Data.SqlClient
SET MigrateExe=.\packages\EntityFramework.4.3.1\tools\migrate.exe

%MigrateExe% Data.dll /StartUpDirectory:%StartUpDirectory% /ConnectionString:"%ConnectionString%" /connectionStringProvider:%ConnectionStringProvider%

The following table explains the data being passed to the command line tool.

Options Comment
Data.dll The assembly with the DbContext and migrations to be executed.
/StartUpDirectory This is the directory where your assembly is located.
/ConnectionString This is the full connection string for your target environment.
/connectionStringProvider This is the ADO.NET provider type to be used when executing against your target environment.
/verbose [Optional] use this option to have the tool output all SQL being executed or generated to the command console.



I attempted to learn how use this tool by using the command line executable and just messing with the parameters to see which ones where needed and that approach backfired as in some scenarios I wasn’t getting much feedback from the tool as you can see from the following screenshot.  Now, I admit I made the mistake of not providing the connectionStringProvider to the command line tool but I expected it to handle this more gracefully.




Automating your Entity Framework data migrations in your build server is extremely simple and flexible, so feel free to go version and manage your database the efficient way.