Head in the Cloud

I Googled, Binged, and scoured internet and various documentation and could not find this setting.  I was able to reverse engineer the declarative markup based on the properties in the classes and code samples. If you want to use the shared access signature authentication with the netMessagingBinding in WCF declaratively in your web.config or app.config, here's how.... Given the service bus connection string.... Endpoint=sb://acme.servicebus.windows.net/;SharedAccessKeyName=efudd;SharedAccessKey=f9JFgRYdLdnPTQv4/EC5ixt4iHVUSTCnhOg1uep9lsW= The configuration for your transportClientEndpointBehavior looks like this... < transportClientEndpointBehavior > < tokenProvider > < sharedAccessSignature keyName ="efudd" key ="f9JFgRYdLdnPTQv4/EC5ixt4iHVUSTCnhOg1uep9lsW=" /> </ tokenProvider > </ transportClientEndpointBehavior > Happy Coding!

Normally, when specifying joins in in Hibernate or NHibernate using HQL it's via the mapped associations.  For example: select {p} from Person p join p.Address a where a.AddressType = 'Mailing' The explicit join is through the mapped one-to-many association from Person to Address. We recently had a need to join two entities that didn't have associations. For that, we can resort to joins in the where clause: select {p} from Person p, Address a where p.PersonId = a.PersonId  and a.AddressType = 'Mailing'

I've been having some fun lately on an integration project involving and on-premises BizTalk 2010 implementation and the Windows Azure Service Bus.  We've run across some interesting challenges that aren't well documented, if at all, so I wanted to share with you all.  I'll take a tutorial approach through real world scenarios as well as talk a little bit about the academics. The business requirement:  Publish a BizTalk Orchestration to the Windows Azure Service Bus and secure the service with client/service certificates. Seems simple enough, but the implementation had me banging my head against a wall.  Rather than throw it all at you at once, let's start small... A Simple WCF Service Let's start with a simple WCF service and client that we'll use throughout the rest of the discussion/lab.  I won't go to too much into the detail of creating WCF services and consuming them.  I 'm assuming if you're researc...

" Everything should be made as simple as possible, but no simpler. " -Albert Eistein. Ok, I have to rant for a bit.  I apologize if the article is brass or if I ramble in places, but I promise, out of it comes a lesson in simplicity and efficiency. For any developer (or any tradesman for that matter), good habits and sharp skills require a solid foundation.  For me, that foundation came from my course work at Bay Path Regional Vocational Technical High School.  One of my instructors there, Bill Bostock, the very first day of class, wrote on the chalk board in large letters: K.I.S.S. Then asked us what it meant.  After some giggling and music references, he elaborated: K eep I t S imple S tupid The KISS Principle That day and that lecture will stick in my mind for ever.  I even use it in my own introduction to computer programming lectures at American Career Institute.  He told us there are many answers to any given problem, some complex,...

I noticed the fans in my Macbook Pro were running excessively.  When looking at Activity Monitor, I noted that the Dock was using 100% of the CPU.  A quick search on Google, and I found the culprit to be Parallels.  The root cause is an issue with the graphics API between OS X 10.6.8 and Parallels Desktop 6.  I had indeed recently updated to 10.6.8 in preparation for Lion. The details can be found in this Parallels KB article: Mac Dock consuming 100% of CPU core after upgrade to Mac OS X 10.6.8 Symptoms: Dock consumes 100% of CPU Environment: Mac OS X 10.6.8 Parallels 6.0.12090 The Solution Rather than downloading from the web site, I simply ran the "Check for Updates" on the Parallels application menu.

If you want to handle events when working with System.Diagnostics.Process -- for example, the Exited event -- you have to first enable the raising of events using the EnableRaisingEvents property on Process. 1: using System.Diagnostics; 2:   3: class MyClass 4: { 5: void RunProcess() 6: { 7: Process p = new Process(); 8: p.EnableRaisingEvents = true ; 9: p.Exited += new EventHander(Process_Exited); 10: } 11:   12: }

Bit by yet another not-so-well documented "feature" in Microsoft .Net.  We were compiling in release mode for QA, since we've seen other behavioral differences between debug and release.  We also wanted to emit the line numbers in the stack trace so the engineers would have a better idea of what caused the error.  We added the /degub:pdbonly option, but left the /optimize+.  We noticed that some of the errors when compared to the line numbers didn't make sense.  It turned out that most of the stack trace was wrong... or at least wrong when compared to the original source code. If you want to emit debug symbols, ie. pdb files, when compiling in release mode, you have to disable optimizations.  Compiler optimizations will often reorganize instructions for the most efficient execution.  As a result, any stack trace will produce unexpected line numbers... you'll get the line number in the newly optimized code, not the line in your original source code. ...