Hey, did you know that I'm a Microsoft MVP? As an MVP, sometimes Microsoft lets me do some cool stuff.
For instance, they let me write some blog posts about Couchbase with Windows and .NET for the MVP Award Program Blog! There are three total parts, and part 1 was just published.
I always want to thank fellow MVP Travis Smith for being the technical editor for these posts! He provided some great feedback, and he's an overall great guy!
I'm trying to familiarize myself with node.js, since it seems to be in use by a lot of Couchbase customers. I heard that Visual Studio code had some pretty good node.js support built in, so I decided to give it a shot.
I already had node and npm installed on my Windows machine. I don't remember why. If you aren't sure if you do, open up Powershell (or cmd) and try:
(If metaphors help you, I think of node as ASP.NET and I think of npm as NuGet)
The next easiest thing you can do is create a file with text editor, say "app.js". Put this into that file:
var msg = "Hello, world!"; console.log(msg);
Woo. Now back at the command line, type:
And guess what it will write out? If you guessed "Hello, world!" then give yourself 10 points.
I have a web page on domain A and, say, a Json endpoint on domain B. I would like domain A to make an Ajax request to domain B, but when I try that, I get an error message, as shown here:
Let's explore the jsonp option. Here's a similar request to the one above, except this time it's using jsonp.
It does not raise an error.
The way jsonp works is a little wacky, but the main thing you need to know is that you need to specify a callback function. jQuery handles this automatically on the client side. Here's how I handle it on the server side with ASP.NET MVC using the Mvc.Jsonp package.
Notice three things:
The benefit is that you can now do cross-domain scripting. So far the drawbacks seems to be that:
I'm giving it a shot on Ledger, and seems to be working fine so far.
Based on a Twitter conversation with Seth Petry-Johnson about mocking/faking SqlException objects in .NET, I decided to go ahead and put what I had written into an open-source project on GitHub. I didn't spend much time on the name: I thought about Sharp Stick and Pointy Stick, but those repo names have already been taken! So, I thought about "stick" some more and remembered the famous line from Lady Macbeth: "screw your courage to the sticking place". Well, I guess I don't have much of a future in professional naming.
Since I was creating a repo anyway, I thought I'd throw a couple of other helpers in there. I put in some of my favorite ASP.NET / ASP.NET MVC helpers and an obscure little string helper. I'm not trying to remake PGK Extensions or anything--just putting some stuff out there that might help someone.
I should also note that the SqlExceptionHelper stuff isn't entirely original: I borrowed some code from a 2006 blog post by Rido, and just updated the reflection code since the private constructor has changed since then (and could possibly change again, since it's a private constructor in a sealed class).
Anyway, go check out Sticking Place on GitHub and let me know what you think.
I was recently demoing the project to my partner on the staging site (Azure), and I ran into a troubling error having to do with data connections (that I had not experienced running it locally on IIS yet). I immediately thought that it must be an issue with the SQL connections (SqlDbConnection objects that implement the IDbConnection interface, per Dapper) not being closed and/or disposed of correctly.
I remember encountering the same issue when I was developing this very site that you are reading, and the solution is to use the HttpContext scope within StructureMap when configuring it for the IDbConnection interface.
Here's what I started with:
And here's what I refactored it to:
I just added HttpContextScoped (the default is PerRequest scope, see StructureMap docs on Scoping and Lifecycle Management). I also added the ReleaseAndDisposeAllHttpScopedObjects to Global.asax.cs, so that StructureMap would...release and dispose those objects at the end of each request.
However, when I did that, I was still getting problems. I would get exceptions saying that the SqlConnection ConnectionString was the empty string. Something wasn't right. I did some searching around about the issue in the docs, and couldn't really find what I was looking for. I did come across someone with a similar issue on StackOverflow, also trying to understand HttpContextScoped. The top answer from PHeiberg (not the accepted answer) pointed me the right direction.
I used a lambda expression instead of just passing the SqlConnection directly. So now my SqlDbConnections are scoped to the HttpContext, and will be cleaned up after every request. That should squash the issue I was seeing on the staging stie.
Matthew D. Groves lives in Central Ohio. He works remotely, loves to code, and is a Microsoft MVP.