Using PostgreSQL ODBC in .NET Apps

I’ve worked with many database architectures over the years, and written many apps in a variety of languages across them. Recently, I finally got the opportunity to turn my attention to PostgreSQL. This database system remains one of the most popular and is about as robust as you can get for free (save maybe for Microsoft’s SQL Server Express). One thing I’ve learned to appreciate about PostgreSQL is how lightweight it is.

While PHP or Python may be the “go to” languages working with PostgreSQL, we .NET developers can have it in our apps, too. There are a number of commercial drivers and APIs you can purchase but for the sake of simplicity and just simple trying it out—even for simpler, non-commercial apps—you can use ODBC. I know what you’re probably thinking. WHAT?! ODBC?! But this is 2015! Don’t get your panties in a bunch, just read on.

Here are the steps to get up and running quickly:

  1. Download and install PostgreSQL –
  2. Download and install the latest  sql_odbc_0n_0n .msi* –
  3. From the Run window, type odbcad32.exe and click OK, then click the System DSN tab. Note you have two new PostgreSQL drivers available:

  4. Select the ANSI(x64) driver and click Finish. The driver configuration window should appear:

  5. At this point, you have the option of specifying all the appropriate information in the ODBC setup. My personal preference is to save only the Data Source name here (which also acts as the DSN) and the port. Note: This is the PostgreSQL default. You can also exclude it in the setup and include in the connection string as shown below.
  6. Finally, create a console project in Visual Studio to test the connection. The below code demonstrates a test method.

You should see the following results if all’s well:

* As an alternative to downloading and installing the ODBC drivers manually, some PostgreSQL installations include a program called Application Stack Builder. This includes common tools and languages, as well as drivers for node, Java, and ODBC 32/64-bit. You can use Stack Builder to install the drivers, as shown.

And that’s it. You can now write .NET apps against PostgreSQL. Happy coding!

My Wife’s New Blog

It’s a proud day for me! It’s the day my wife finally decided to come out of her little shell and share her experiences and knowledge with others. Marilyn’s never been much of a writer (she thinks that role should be solely for me, which is ridiculous), but as I’ve explained to her she has a lot to offer, and if she’s writing then she’s a writer. It doesn’t matter who reads the work or even how many people read it: it matters that she writes what makes her happy and she’s finally taken my advice to heart.

So I’m proud to let everyone know that Marilyn’s new blog is called “Life Over 60″ and she’s made her first entry. You can find it here. Way to go, darling!

ASP.NET MVC from Scratch

I’ve found there are times when I want to start a new ASP.NET MVC project but I only want to add the very minimum assemblies in order to build my application. The steps to do this aren’t as difficult as you might think. The basics needed to do this are implemented through the install of a single NuGet script. Here are the high-level steps.

  1. Create a new project and select the Empty template.
  2. Once created, launch the package manager and run the following:
PM> Install-Package Microsoft.AspNet.Mvc

This will install four packages:

  • Microsoft.AspNet.Mvc
  • Microsoft.AspNet.Razor
  • Microsoft.AspNet.WebPages
  • Microsoft.Web.Infrastructure

It will also load the many corresponding assemblies containing a code library essential to building ASP.NET MVC applications. Continue reading

Conflicts in Dependent Assemblies

You’re sitting in your ASP.NET app, happily coding along on a 4.5 MVC project, when you install some packages for Microsoft.AspNet.Identity. All of the sudden you get this ambiguous message in your output:

Warning MSB3277: Found conflicts between different versions of the same dependent assembly that could not be resolved. These reference conflicts are listed in the build log when log verbosity is set to detailed.

I first encountered this problem when I was working on package installation for bundling and minification, when a similar conflict occurred between versions of Newtonsoft.Json and WebGrease. So what’s really going on? Well, the plain fact of the matter is that whatever you ask of the NuGet package manager, that’s what it’s going to give you (i.e., the latest version).

Theoretically, such conflicts shouldn’t happen because package installation through NuGet comes with some dependency checking. However, there are times where depending on your implementation, you may get some unexpected conflicts. So it can be hit-or-miss. In this case, I used process of elimination to determine the problem. Check out the package log:

In this case, the issue was caused between Microsoft.AspNet.Identity.Owin and, wait for it, Microsoft.Owin.Security.OAuth. Note the versions are the same, the reason mostly being due to the fact that when I installed the Owin package on Microsoft’s Identity, it automatically loaded the 2.1.0 version of OAuth on the Microsoft.Owin.Security package. You see the dependency is the >= 2.1.0. By default, the matching version got installed, not the latest.

It’s pretty easy to correct. In package manager:

PM> Install-Package Microsoft.Owin.Security.OAuth -Version 3.0.0

Once that’s done, the package manager will automatically install the latest version of OAuth. You should be able to then build and compile the project and clear the errors. Happy coding!

The Comeback Kid?

Fed Cover

Coming Soon!

So I know there are going to be a few people who will see this and say, “Told you so!” Well, before you get too cocky, there’s a few things I think I ought to explain. First off, I’m a “retired” professional author: the key word being professional. That means doing something someone pays me to do.

Writing began as something I loved, but as I got better at it and discovered others would pay me to publish my work, I saw it as a way to supplement my income and support my family. And that’s exactly what it’s done for the past eighteen years.

Then in the fall of 2014, after another frustrating failure by another traditional publisher, I decided I’d had my fill of writing professionally and I announced my retirement.  I didn’t know how I was going to live without that supplemental income but I was determined to let software engineering carry me. As good fortune and God’s blessings abounded, I found a job that pays me plenty and allows me to work from home. Glory! Now I’m quite comfortable and don’t have to write for money any more.

During all of life’s transitions in 2014, I had an unfinished novel I’d started called Fed, the story of an FBI agent named Ramsey McDade who accidentally kills an innocent bystander. Although he’s cleared of any wrongdoing, it shakes him up enough that he begins to question his own faith and whether he can continue doing his duty.

Ultimately, with the pressure off, I decided I just could not bow out of the game unless I finished and published this book. So that’s what I’m doing. I’m going back to writing for the love of writing. Win, lose, or draw I have to see this through to the end. It’s simply a story I must write!