Ramblings from the Creator of WilsonDotNet.com
I've got a bizarre situation where a call to webresource.axd for some users is failing -- and only some users. Everything is installed on the server, and as far as I can tell it is all setup correctly -- and this is demonstrated by 95% or more of the users not having any problem. But these particular users have this problem getting webresource.axd regardless of the computer, network, or browser -- other members on my team can take the same user credentials and repeat the problem, while other good users continue to work on all the same computers. We are able to consistently reproduce the problem as we have identified a commonality between these user accounts -- the length of their login email is between 27 and 30 characters inclusively. Of course that login email is no where used to pull webresource.axd to my knowledge, but it is maybe somehow part of the session authentication cookie -- and maybe that's why things are failing. But I do not know of anything else to look at as far as configuration and authentication goes to troubleshoot -- we do not have this problem in our QA environment, nor do we have this problem for existing users (just newly registered users). We are using BEA's Plumtree ALUI 6.5 portal, so its a very complex and particular environment that I wouldn't expect others to have -- but maybe someone else has experienced something similar or has a thought.
My nephew, Matthew O'Bryant, was one of the two US military personnel that was killed in the terrorist bombing of the Pakistan Marriott last weekend. He was a great kid (22 years old) and he will be missed very much by his wife, brother and sisters, parents, the rest of our family, and his many friends.
Scott Bellware's working in Alpharetta for a few weeks. Contact me if you're in Alpharetta and want to join us for lunch on Tuesday, August 5th. So far Dave Ward is also joining us, but there's room for a few more.
From the Atlanta Code Camp site:
"LINQ in Action", published by Manning, is by far the best book available on Linq, both for those new to Linq and those already following it. The authors, Fabrice Marguerie, Steve Eichert, and Jim Wooley, have done a fabulous job of explaining Linq from the basics to the advanced. They even made it enjoyable to read, which makes it one of the best .Net books ever!
The authors' introductory chapter shows us right away that this book is different by presenting a perfect balance of the problem, the history, and the solution. Linq is a huge subject, but the authors are up to it, and they quickly whet the readers appetite for all of Linq -- Objects, Sql, and Xml. We then get a very thorough explanation of the new language enhancements that Linq relies on, but which the authors clearly show to have uses of their own. The chapter on Linq's building blocks, covering sequences, query operators, query expressions, and expression trees, was especially instructive to me, even though I've followed Linq from the alpha days, so again I'm sure this book has something for everyone. The book then covers Linq to Objects very thoroughly, including common scenarios and performance considerations that other books never consider.
The book then progresses to three chapters on Linq to Sql, which are of course my favorite since I'm really into O/R Mapping. The authors cover not just the basics to get beginners up to speed, but they also cover far more advanced content than I was expecting. For instance, they discuss not just the designer to setup mappings, but also the SqlMetal tool, and manual mappings using either attributes or xml. They also discuss the various concurrency options, the entity life cycle, inheritance, and more. The authors then give us three chapters on Linq to Xml, which again have something for everyone -- I especially like the chapter on common scenarios. The book finishes with a very thorough chapter on extending Linq, with a Linq to Amazon example, and a chapter that ties it all together with a real-world example that was gradually put together during the course of the entire book.
The authors also provide additional support and material online, including a bonus chapter on Linq to Datasets. There is also downloadable code in both C# and VB, although the book actually shows both languages in most cases, and always points out the differences when there are differences between them.
Disclaimer: I personally know Jim and have seen him present on Linq multiple times, Steve was a user of my WilsonORMapper, even contributing to it, and I've known Fabrice in the online world for quite some time too -- but I did very much enjoy and learn even more from their most excellent book on Linq.
Do .net 2.0 service pack 1 compiled binaries fail when ran on machines without that service pack? Developers automatically get force-fed .net 2.0 sp1 when we install VS 2008, which doesn't sound like it should be a big concern typically. But what about the next time you compile an existing VS 2005 app and deploy on machines without sp1, which would of course be the case for most non-dev machines right now? I believe I have found a case where this is indeed happening, at least that's the only explanation I can find so far, and it looks like there are a few others reporting things too -- but the details so far are sketchy at best.
I've got an existing .net 2.0 app (written in C#) that calls a 3rd party web service that has always ran just fine. I needed to make a couple of small updates to my app which did not change anything related to the calling of this web service at all. Everything works flawlessly on my development pc, which has service pack 1 for .net 2.0, but fails when deployed on my qa server, which does not have service pack 1. Here are the exception details:
Its been a very long time since my last post, but here I am again at last. I just started a new job with McKesson this week as an ASP.NET Architect, where I'll be working on internal tools to support sales and marketing. McKesson is currently 18th on the Fortune 50 list, being the largest health-care company, and I'll be working in their Alpharetta, GA, office. I'm very excited about this change, both for the short-run and long-term, and I'm calling this a birthday present to myself since I just turned 40. I still believe Mimsware to be the best Atlanta-based consulting company, and I highly recommend them, but I decided I wanted a more permanent role. And McKesson isn't just any company -- they are also big enough that I can make a career with them and still find opportunity for change if I desire. Its also a pleasant drive for me, taking back-roads from Woodstock, GA, although its a big change for myself and my family to not work from home.
So that explains this post, but what have I been doing since the last one? I suppose the easiest explanation is to simply say that I've been living! My focus has very much been my family, and much less on being a tech guru, which was only a coincidence due to having lots of time a few years ago. My wife Jenny is still cancer-free, and now reconstructive surgery is done, but earlier this year there was a tough time dealing with a reconstructive surgery that didn't heal which led to a much bigger surgery than expected. But she's fine now and back at her job as a nurse in a cardiac cath lab. Meanwhile, my kids are growing -- Tori is 10 and still enjoys dancing, while Zack is 9 and enjoys video games, and both stay busy with friends. We also got a Wii, which is finally a game system we all can play together -- and I count it as real exercise in air-conditioning with no allergens! I got Mario and Sonic Olympics for my birthday and even got a little sore.
So what about the latest MS technology and my own endeavors like my O/RM? I never set out to spend time on forums or to create a popular O/R Mapper -- I simply had a lot of free time several years back that I used wisely. I love learning new technology, and I like to build something real that is useful to myself as part of that process, which is how it all started out. I then discovered that others also found things I did very useful, which encouraged me to do even more, but then my O/RM took on a life of its own. I found that I was no longer just learning or making something for myself, instead I was adding features for others and doing a lot of support also. So Brian DeMarzo has taken my O/RM open source, and I'm just going to once again play with the latest MS stuff, like Linq to Sql and MVC for ASP.NET. I may yet build something I think is useful enough to share with others, or at least learn enough for a new post, but if I don't then that's OK too.
Several Atlanta area user groups have teamed up to meet on a single night with multiple tracks -- and the next meeting is Monday, May 7th, 2007, at 6:00pm in the Microsoft Alpharetta office. Shawn Wildermuth will be giving the combined short talk, and then the group will split into several tracks, featuring Mike Culver, Jim Wooley, and maybe more. Get more details on the Cutting Edge site.
I almost can't believe the great news that came from MS today. That's right, the ADO.NET Entity Framework has been delayed ! I bet most of you think I'm being sarcastic, but I am serious. I've got at least three reasons why this is good news to me.
First, this gives Linq to Sql a better opportunity to thrive. Linq to Sql is the "simpler" OR/M that's looking good enough for the vast majority of cases, while ADO.NET EF is far more complex -- and yet most gurus only wanted to talk about the EF.
Next, since ADO.NET EF is so complicated, it absolutely must have a great designer ship concurrently, which was not the plan. MS has apparently accepted this feedback since this is at least the publicly given rationale for the delay in shipping the EF.
Finally, and this one may not pan out, but it is my own hope that ADO.NET EF is being re-aligned somewhat with Linq to Sql. These two O/RMs are similar enough to share at least some code, and I believe that some of the MS guys have hinted at this too.
So I'm happy that at first there will be one O/RM -- Linq to Sql. The gurus may be disappointed, but the vast majority of MS devs will be new to O/RMs anyhow, and Linq to Sql will be good enough. Very much like my simple WilsonORMapper has been so widely used.
I've got a small app in production that's been running without a glitch until the other day. It turned out to be a case where the server didn't have enough disk space and nothing more. That should have been the end of it, but I also decided to add myself to the error emails. The next day someone reported not getting their regular email, and I couldn't figure it out.
Why would something that had been working perfectly and not been changed just fail randomly? I looked everywhere in the code and could find no reason, and nothing was logged about this. That said, there was an exception that was logged, but it was about my email, not the other. My email address was on another domain, and that wasn't allowed, but I just shrugged it off. Then it happened again today and all the sudden I realized what should have been very obvious.
That small configuration change I had made to send myself error emails was the actual problem! My code first sent error emails before sending routine emails, all of which was one try/catch So when I added myself to the error emails, I introduced an exception that skipped the others. This was now easy to fix -- just make each email send be in its own try/catch, instead of one.
And the lesson learned: any change, even a tiny configuration change, can introduce problems. Even bigger lesson: when problem occurs after small change, then your change is likely cause. Those should really have been obvious in retrospect, but I managed to convince myself otherwise.