randolpho - Developer IT

Computer: Tea. Earl Gray. Hot.

- by Randolpho St. John

I just bought an awesome geek mug and thought I'd share: You can get it too, if you head over to Cafe Press.

"The protocol 'net.msmq' is not supported."

OMG, a new lesson! Will wonders never cease? So I ran into an interesting issue setting up a WCF service to consume an MSMQ queue. I won't bother you with the details of how to actually build a WCF/MSMQ service; there are plenty of tutorials on the subject. I want to share with you an interesting error that I ran into and the surprisingly simple fix. The error occurs when attempting to generate a Service Reference or even simply browsing to the WSDL of your WCF/MSMQ service in the form of a YSOD with the following error: "The protocol 'net.msmq' is not supported." After a lot of Googling on the subject turning up plenty of questions with the same error but no answers. So I went digging into some application level config files on a server that already had a WCF/MSMQ service successfully set up by the network admin, and the answer was amazingly simple: If you are hosting an MSMQ/WCF service in IIS, you have to tell IIS to allow net.msmq protocol. It's in the advanced settings for the application or site in which you are hosting the service. .... aaaand, that's it.

Read the article

Finegrain Performance Reporting on svchost.exe

- by Randolpho

This is something that's always bothered me, so I'll ask the serverfault community. I love me some Process Explorer for keeping track of more than just the high-level tasks you get in the Task Manager. But I constantly want to know which of those dozen services hosted in a single process under svchost is making my processor spike. So... is there any non-intrusive way to find this information out?

Read the article

Base 128 or 256 Encoding for the Binary Lexical Octet Adhoc Transport Protocol?

- by Randolpho

I'm in the process of implementing a network driver for the Binary Lexical Octet Adhoc Transport (BLOAT) protocols in the hopes of replacing the TCP/UDP/IP stack with a much more flexible XML structure. BLOAT is detailed in RFC 3252, so if you're unfamiliar with the protocol I highly recommend you read the entire RFC before providing any comments. Don't worry, it's short and sweet; you might even enjoy it. Anyway, my problem is this: BLOAT requires that the payload be Base64 encoded which doesn't make sense to me. I mean, sure, it's the internet standard for binary payloads, but there are better, more efficient encodings available: Base128 and Base256, for example. That the RFC requires Base64 and doesn't allow for any other payload encoding really bothers me. To that end, I'm considering a small optional change to the protocol. Embrace and extend, right? Anyway, I'd like to modify the payload element to accept an encoding attribute, which can extend the encoding to Base128 or Base256, or even to other encodings I can't conceive of at the moment. If the encoding attribute isn't present, Base64 would be assumed. So my question is this: should I? I mean, BLOAT is an accepted standard, even if it isn't exactly omnipresent. If I make this change, will there be compatibility issues? I don't foresee any, but perhaps you, oh great Stack Overflow Community, can? If I do implement this change, should I contact the original RFC author? Should I offer a supplemental RFC?

Read the article

What Features Do You Want To See in .NET 5/C# 5?

- by Randolpho

.NET 4 and Visual Studio 2010 are finally here, along with a host of new features. But we wouldn't be who we are if we didn't long for a feature that didn't make the cut, or that was never even considered. So sound off and let the folks at Microsoft know: What features do you want to see in .NET 5? What features do you want to see in C# 5? F#? VB.NET? Before you vote to close: some may find this question too subjective to let stand, but there are other threads that have stood the test of time. Let this one stand as well.

Read the article

Unit Testing the Use of TransactionScope

- by Randolpho

The preamble: I have designed a strongly interfaced and fully mockable data layer class that expects the business layer to create a TransactionScope when multiple calls should be included in a single transaction. The problem: I would like to unit test that my business layer makes use of a TransactionScope object when I expect it to. Unfortunately, the standard pattern for using TransactionScope is a follows: using(var scope = new TransactionScope()) { // transactional methods datalayer.InsertFoo(); datalayer.InsertBar(); scope.Complete(); } While this is a really great pattern in terms of usability for the programmer, testing that it's done seems... unpossible to me. I cannot detect that a transient object has been instantiated, let alone mock it to determine that a method was called on it. Yet my goal for coverage implies that I must. The Question: How can I go about building unit tests that ensure TransactionScope is used appropriately according to the standard pattern? Final Thoughts: I've considered a solution that would certainly provide the coverage I need, but have rejected it as overly complex and not conforming to the standard TransactionScope pattern. It involves adding a CreateTransactionScope method on my data layer object that returns an instance of TransactionScope. But because TransactionScope contains constructor logic and non-virtual methods and is therefore difficult if not impossible to mock, CreateTransactionScope would return an instance of DataLayerTransactionScope which would be a mockable facade into TransactionScope. While this might do the job it's complex and I would prefer to use the standard pattern. Is there a better way?

Developer IT