Public/Private key problems

Lately, I’ve been working on a project that has some pretty heavy duty encryption requirements.  This stuff is very cool, but somewhat mysterious.  I have run into these two errors and couldn’t really find a good description of what they are or more importantly, how to fix them.

Input too large for rsa cipher


Unknown block type

The problem is that without the code changing at all these two errors pop up all the time but very randomly. Read more

Pausing to catch your breath in C#

Sometimes in your code, you find the need to try an operation that’s dependent upon some other system.  That other system might be a little laggy.  As such, you want to try your operation and then pause a moment or two before you try again.  A simple way to do this is with


That little snippet of code will wait for one second and then continue.  There’s a better way though…

Read more

WebAPI – Accepting both form data and query string parameters

Recently, I had to write a WebAPI method in C# that would be an HTTP POST.  Basically, I wanted to hit


and pass a bunch of data in the body of the request. Simple, no?

In our project, we make heavy use of the Route attribute to decouple the method name from the URL.  My method looked okay.

    public class DemoController : ApiController
        public IHttpActionResult Sample([FromBody] string requestBody, string id)
            return Ok(String.Format("Request with ID {0} body has a length of {1}", id, requestBody.Length));

This sample code is clearly very simple.  I have decoupled the controller to api-demo and the method to samplemethod. It appears like everything would work as expected, however when I would test it via POSTMAN, I get the following response:

  "$id": "1",
  "Message": "No HTTP resource was found that matches the request URI 'http://localhost:99/api-demo/samplemethod/1134630'.",
  "MessageDetail": "No type was found that matches the controller named 'api-demo'."

Read more

Performance – Using Try/Catch

I just wrote the stupidest program ever.  It is inefficient by design.  If anyone did this thinking “hey… this is great code” they should be fired.

Anyway… generally speaking, using try/catch blocks is not a great idea.  There are a myriad of reasons but it’s usually something along the lines of:

If you truly have an unexpected error it’s better to let the program crash and then fix the bug.

If you do have to use the try/catch exception handling block, you should only catch explicit exceptions.  For example catch a file access exception or a database invalid primary key exception.  Just catching the generic exception is poor practice.

There’s another reason to avoid try/catch though… it is a performance hog.

Read more

Performance – Inline SQL vs Parameterized Queries

In the search for better and better performance, there are many techniques developers can use.  A technique used early on by some entry level or “still learning” developers is to build inline SQL.  That looks something like this:

string name = "Mark";
string query = "SELECT * FROM users WHERE FirstName='" + name + "'";
OleDbCommand cmd = new OleDbCommand(query);
OleDbDataReader reader = cmd.ExecuteReader();

There are steps missing… this is just example code


This is something more seasoned developers learn to avoid almost immediately.  There’s a variety of reasons why inline SQL is bad.  The most important reason is security.

However, there’s another reason to avoid it.  Performance.

Read more

Inherited Object Serialization with Newtonsoft.JSON

Wow… I’m coming up with some sexy titles for posts lately.

This is going to be how to deserialize JSON objects into native C# objects using Newtonsoft.JSON.  Serialization of objects to JSON is very straightforward.  Serializing objects inherited from a base class is pretty simple, but there’s a little bit of doing to do first. Converting those items back though… that’s a trick.

Read more

Scroll To Top