Robert McLaws: FunWithCoding.NET

Why Glitches over the Holidays are Bad

We determined the source of the technical problems we are having on our servers. It seems that between Longhornblogs.com, PatchDayReview.com, and the rest of the Interscape websites, we were getting so much traffic, that our dinky little 10-Base-T network card was pegged pretty much all the time. Well, early Monday morning it decided to totally crap out on us. The problem with that is, there is minimal staff at our hosting center right now due to the holidays, so it won't be fixed till Friday at the earliest.

Because they can't upgrade the network cards (they have to keep all the boxes identical) we'll be moving to a new hosting provider soon. I can't really afford to lose a weeks worth of sales again. In the meantime, we'll have the site back up as soon as we possibly can. In the meantime, you can still browse all of our content at http://interscapeusa.mykb.com (man, I LOVE how that stuff works, Scott Cate rules). Hopefully soon we'll be able to afford failover servers.

Update: My e-mail is down too, so until my servers are back up, you can e-mail me at rmclaws@devadvice.com.

.Text Tip

One of my MS friends (who asked to remain nameless) stumbled upon a nifty piece of code that you can use to help improve your .Text aggregated sites. Leave it to Steve Schofield to come to the rescue again. He talks about how to add a link to the comments of an entry on the aggregated home page. Thanks Steve! I'll be making that update globally as soon as .Text 0.95 is released.

Also, for those of you dealing with editing existing posts with FreeTextBox (stuff doesn't get HtmlEncoded properly when dumped in from ViewState), someone posted a solution in the FTB Forums. He says it might not work in downlevel browsers, but it looks like it should work ok. The only thing this guy needs to do now is strong-sign his assembly. Then it could be GACed. Oh yeah, and he should set up a GDN Workspace for it too. Then contributors can post updates without hassle.

Technical Difficulties

The Confusing Role Of Programmers

I was surfing the Blogosphere tonight, catching up on some of Don Box's writings, when he led me to Chris Sells. Sells, it seems, was distressed that the Don Box / Mary Jo Foley interview was just plain boring, so he left a RFC post on his blog, soliciting questions to ask him in a later interview. What I found there was startling.

“With all the connection/transport technology, ease of use and rapid development in terms of creating applications, and easy of exposing of data that Microsoft are providing where do you see the role of a software developer going? Are we resigned to connecting pre built components together, relying on Microsoft to provide all our underlying architecture and frameworks?

While I appreciate what Microsoft are providng, and support the idea of a SOA underpinning their new OS and tools (and in fact have been harping on about it at our own seminars in 2003) it makes me wonder where a lot of Windows Developer jobs are going. As we make it easier and easier to create complex applications and systems how do we maintain our market worth and indeed our jobs as more and more of the magic that today we get paid to craft is provided for free by Microsoft?”

I was flabbergasted. It seems to me that this guy, who only listed his name as “Ian”, perceives the worth of a developer to be in creating problems to be solved. He doesn't want to be “resigned” to lacing pre-built systems together, and thinks he will be of lesser value when the work he currently does is provided for free by Microsoft.

 I cannot understand this mentality at all. I though the value in being a developer was in solving problems through code. So, right now one of the biggest problems in computing is getting information from one place to another. Out of Outlook and into AIM. Out of yoru aggregator and into your Outlook contacts... whatever. If these problems are solved, is that the end of software development? HELL NO. Cause what is the real problem here? People HATE using computers. I hate computers with a passion. Why? Because they're too hard to use, and I hate watching people put up with so much crap just to get it to do something.

So when Longhorn, indigo, and Whitehorse come out, do we all just go “Great, now we're gonna get fired because Microsoft solved most of the problems we're dealing with now?” NO. Go solve new problems. Make me enjoy using he my computer. Better yet, make my mom enjoy using my computer. Make it easier for me to get my information in to where I need it. Help reduce device clutter. Refine software production so that buying software is cheaper. But to be all Henny Penny about your job? Please, this stuff will only make you lose your job if you can't come up with new ways to use it by the time it comes out. You have TWO YEARS for pete's sake. If you can't come up with something by then, you missed your calling waiting tables or something.

DotNet Jobs

Strong Naming Notes

I noticed earlier in the week that someone pointed out that you can use ILDASM to pull out the strong-name from a strong-named assembly, and recompile using a different key. I remembered an article I came across on MSDN that talked about this, so I thought I'd quote it here.

Most of the wizard-generated projects in Microsoft Visual Studio® .NET place this attribute in a file called AssemblyInfo, but you can put it in any source file you like. When the compiler sees this attribute, it copies the entire public key into the assembly's metadata, and uses the private key to form a digital signature. This is done by hashing the files in the assembly, incorporating those hash values into the manifest for the assembly, hashing the manifest, and, finally, encrypting this final hash value using the corresponding private key and tucking it away as yet another block of metadata in the assembly.

(Note that using this simplistic approach, the compiler needs to have not only the public key, but the private key as well, from the file c:\temp\mykeyfile. You'll see a safer way to approach code signing later in this article.)

If you look at an assembly's manifest using ILDASM, you'll be able to see its public key quite plainly, as shown in Figure 1.

Figure 1. A public key assigned to an assembly

What you won't see is the signature or the intermediate hash values. This sometimes confuses people who are learning about strong names. ILDASM doesn't show these things because ILDASM is a disassembler—it is supposed to produce IL that can be compiled into an assembly, and remember that the signature and hash values are output by the compiler (which would be ILASM in this case).

So there you have it. Just because you can use ILDASM doesn't mean you'll be able to access everything in an assembly. You can change the public key, but you won't be able to change the signature or the hash. By changing the public key, you'll render the signature invalid, and the assembly will fail to load.

Now, what they can do is delay-sign malicious code using your public key, and spoof any publicly available delay-signed assemblies... and very easily, I might add. This is why, you should NEVER let unsigned or delay-signed assemblies outside whatever environment you develop in. If you're a third party component developer, and you're releasing unsigned assemblies.... SHAME ON YOU.

I might note that the point (at least from Microsoft's perspective) was to not be able to substitute assemblies in a componentized environment. If you built the program with a strong named assembly system, the name, version number, culture code, and public key hash are stored in the manifest. If the runtime comes across an assembly with the same weak name but missing or incorrect strong name, it will fail to execute.

This prevents someone from building an assembly with the same names and methods but does something bad, like deleting everything out of the "Program Files" directory or something. Even if they could recompile an assembly without signatures, and had physical access to your server to replace it, it still would not work.

What really needs to happen is twofold.... there needs to be an Identity Authority to be able to have certificates specific to the publisher that can be authenticated, revoked, etc (kind of like Authenticode, but I don't belive that works for .NET), and you need to be able to encrypt assemblies using a PKI, and have the assemblies decrypted in protected memory (NGSCB anyone?) and then executed. That would stop people from disassembling production assemblies, and compormising security.

DeadBolt.NET Re-Released

Merry Christmas Everyone! Just wanted to let you know that DeadBolt.NET is ready for download... again. In case you missed it, DeadBolt.NET is an Assembly Signing Addin for Visual Studio .NET 2003, written by Jamie Cansdale and Michael O'Hearn. Oh yeah, and it's free (my holiday present to you). We're now using the proper procedure for extracting the PublickKeyToken of the Assembly Signing Key, and it has been tested on about 20 different keys. If you download it, make sure to read the User's Guide. There is a two-page introduction to Assembly Signing, and a bunch of walkthroughs on how to use the app.

As always, please let me know if you have any problems, and happy holidays!

My Christmas Present To You

A version of ScrollingGrid that actually works in a production environment. Today I've released ScrollingGrid 1.1. This new version opens up the previously private variable that sets the width to adjust for the Scrollbar. Now, if it's not rendering properly, you can adjust it yourself. ScrollingGrid was originally designed this way, but we had a design review a few weeks prior to launch, and it was determined that the property did not need to be exposed. A month's worth of real-world use showed this not to be the case, so I overrode the team and put it back in.

This does not mean that you won't still have to specifically the column widths, that feature will not be available until version 1.2, due out at the end of January.

I also updated the User's Guide to include a new two page troubleshooting section, that will walk you through correcting “shallow” and “deep” headers, and help with some problems we've had in the past with the Xheo.Licensing assembly. If you are currently using ScrollingGrid 1.0, please uninstall it before installing ScrollingGrid 1.1. As always, suggestions are appreciated. Let me know if you have any problems.

If you've given it a try before, I'd like you to download it again, if anything, so that you can tell us what you think of our attempted improvements.

Download ScrollingGrid 1.1 Now! (direct link)

DeadBolt.NET Suspended

Tim Heuer pointed me to an article that represents a fundamental flaw in our implementation of DeadBolt.NET. It is written by the great Don Box and Chris Sells, and describes what is going on under the covers of SN.EXE. I did a lot of research on the subject of Strong Name Signing before helping to write this add-in, and never came across this article. Hopefully, by pointing it out, more people will understand how it works, as I obviously didn't. Basically, our implementation is flawed because we're pulling the PublicKeyToken from the combined public/private key, and not just the public key (apparently, SN.EXE dioesn't pay attention to the difference). The assembly is being signed properly, we're just extracting the wrong information for the Public Key part.

Due to this fact, I'm suspending all downloads of DeadBolt.NET, pending a resolution. It may come as early as tonight, possibly not till after Christmas. I'm sorry for the delay, I can't believe that it didn't make it past our tests. A whole heap of thanks goes to Tim Heuer for his assistance. It's good to see some shining positive (yet often quiet) faces out there lending a hand. His help the past few weeks has been invaluable to me.

Credit Card Processing for .NET Developers

A few months ago, I had a huge problem with Interscape's credit card processing. I bloggeed about it in a post entitled “How To Screw Up And Still Come Out Ahead” It was quite an ordeal. Well, I decided that I wanted to help make the process easier for people in the .NET world. So Interscape teamed up with MerchantPlus.cc for Phase One of a two-phase system to make it ridiculously easy to process credit cards on a website. Phase One is the Merchant Account, which is the way that the cards are processed. These accounts are tied to a “gateway”, which in this case is Authorize.net, and that is included in the package. We worked to get the lowest prices possible, and we're passing those prices directly on to you.

So what is Phase Two? We're not telling yet. It's still in development, but needless to say, it will revolutionize the way business is done online. A big statement? You betcha. Hype? That's for you to decide. In the meantime, Interscape and MerchantPlus will give you $1000 if we can't beat your current rates. If you're using PayPal, quit screwing around and start doing some serious business. Check out our rates, then complete our 100% electronic sign-up process (it's REALLY cool, that's what got me hooked... you even sign the contract online).

If you need to get started integrating your Authorize.net processing on your website, there are a bunch of options. Until ours is finished, I'd recommend CodeSine's solution. It's not perfect, but it's cheap and it works.

Oh yeah, anyone that signs up between now and Phase Two will get our Phase Two offering free. So, if you have any questions, as always feel free to contact me. I'll do my best to help you out in any way I can. And feel free to send me feedback too.... I'd like to know if there is anything we can do to make the process simpler.