Bill has me salivating over the Personal Media Center. I started to imagine myself downloading MSDN TV, Channel 9 videos, and TechEd webcasts to watch at my leisure, away from the desktop. There are just two problems with this dream:
[Updated with MSDN Webcasts new URL].
The disappointment has been in not getting a new beta of the ‘real thing’, the ‘Venti espresso’, the ‘yellow yolk of the Yukon egg’.
I have not tried to do much with SQL Express. As soon as I heard the product mentioned in the same sentence as MSDE, I pictured it appearing in the Server Explorer window of the IDE, doing all the mundane things databases have done for the last 5 years. I think a previous forced experience in wrestling with MSDE helped me figure out some of the quirks, like hunting down the instance name to make a connection [use (local)\SQLEXPRESS].
I did come across an interesting error message. I was curious to see if SQL Express, like MSDE, defaults to Windows Authentication only (and it does). In toying around, I tried to “sp_addlogin ‘user’, ‘user’” (just as a test, you see, to set the password the same as the username), and had the following thrown back at me:
Password validation failed. The password does not meet policy requirements because it is not complex enough.
With the Shared Add-In extensibility project wizard and code from “An Introduction to Programming Outlook 2003 Using C#”, I thought I was 90% of the way there, except it didn’t work. Specifically, the following line of code from the article would never return:
CommandBars commandBars = applicationObject.ActiveExplorer().CommandBars;
The call would literally disappear in the opaque goo of COM interop. No exceptions, no error dialogs, no abnormal behavior as Outlook continued to work. I thought I must have a configuration problem and began double-checking primary interop assembly versions and looking for updates. I happened to run across a knowledge base article using the following code:
activeExplorer = applicationObject.GetType().InvokeMember("ActiveExplorer",BindingFlags.GetProperty,null,applicationObject,null); commandBars= (CommandBars)activeExplorer.GetType().InvokeMember("CommandBars",BindingFlags.GetProperty,null,activeExplorer,null);
The above code, using reflection, worked perfectly. I managed to finish the code for my button click event, but not without some irritation.
The base class library in .NET spoils developers, and I think if Microsoft wants people to develop for Office they should provide a higher level of abstraction on top of the runtime callable wrappers. The interface should be subject to the same design rules and usability testing as the rest of the .NET libraries. Let me give you a couple examples about why I am griping.
Selected items are kept in a Selection collection. Indexing into the collection gives me a plain object reference. It would be nice if there was a base class representing any type of item in Outlook which I could perform some operations on. As it stands, I had to dig through the documentation to find the types of Items I am interested in: MailItem and PostItem objects. I had to find these items in the object browser of the IDE as the documentation I used (VBAOF11.chm – the Microsoft Office Object Model) make no mention of them.
Without documentation I decided the best way to get to know these classes was by inspecting them in the debugger. Unfortunately, if I cast an object reference to type MailItem, all I see in the debugger quick watch is a System.__ComObject, which gives me nothing to go on. If, however, I cast the reference to the interface type of _MailItem (notice the underscore), then I can see all the properties and values I am interested in.
The fact that there are three types available to work with (MailItem, _MailItem, and MailItemClass) only adds to the confusion. My fading COM memories tell me these types probably exist because of the difference is dispatch and vtable binding, but when I just want to get something done in Outlook I don’t really care to learn the differences. I just wish it was easier, and with integrated documentation, like the rest of the .NET development experience. Whine, whine, whine.
P.S. I found the easiest way to debug an add-in which is loaded by Outlook when Outlook starts is to invoke System.Diagnostics.Debugger.Launch(), and let's not talk about the number of times you need to put in System.Reflection.Missing.Value as a parameter to a method. Complain, complain, complain.
It’s refreshing to be visiting a small, rural hospital, where I can walk in the back door without being fingerprinted, and go to the bathroom without leaving a trail of breadcrumbs.
A contrast arises because the IT department here has more security in place for the network than many of the places where physical security is much tighter. The use of the IIS Lockdown Tool, the Baseline Security Analyzer, group policy, and software to monitor the network for vulnerable machines on the LAN makes the deployment of a web application a little more challenging. Not that I’m complaining, it’s just the way it has to be.
In debugging some web service wierdness I downloaded Fiddler. Fiddler is an excellent tool for viewing and experimenting with the HTTP headers and payload exchanged between client and server. I've never used a debugging proxy that is so easy and informative.
Any software using the WinINET API (like IE) will automatically send traffic through fiddler when the “Act as System Proxy” check box is checked.
For the .NET classes like HttpWebRequest and WebClient, I found the GlobalProxySelection class is pretty useful for setting the proxy programatically:
GlobalProxySelection.Select = new WebProxy("127.0.0.1", 8888);
Before yesterday I didn't know this class existed. It's amazing what I can find when I venture outside of my “framework comfort zone”.
Let’s see what adds up...
Scoble says there is a launch coming next week that requires Slashdot-compliant servers.
I’ve had a fresh Virtual PC machine ready for weeks in anticipation of a major event.
I’ve named the machine SQL2005B2...