I've added a few articles to the site recently:
And Poonam has chipped in too:
The provider design pattern in ASP.NET 2.0 is sweet. I’ve been toying around in the SiteMapProvider area since the first CTP. There is an XmlSiteMapProvider which let’s you describe the navigation and layout of your web site in an XML file like so:
<?xml version="1.0" encoding="utf-8" ?> <siteMap> <siteMapNode title="Home" url="Default.aspx" > <siteMapNode title="Products" url="Products.aspx"> <siteMapNode title="Seafood" url="Seafood.aspx"/> <siteMapNode title="Produce" url="Produce.aspx"/> </siteMapNode> <siteMapNode title="Contact" url="Contact.aspx"> <siteMapNode title="Email Us" url="Email.aspx"/> <siteMapNode title="Phone List" url="Phones.aspx" /> </siteMapNode> </siteMapNode> </siteMap>
Without writing a line of code (just some drag and drop operations), you can give all the pages in your site a tree view of the site hierarchy and a bread crumb control:
What if your site navigation comes from a database table?
NodeID URL Name ParentNodeID ------ ------------- -------- ------------ 1 Default.aspx Home 0 2 Products.aspx Products 1 3 Seafood.aspx Seafood 2 4 Produce.aspx Produce 2 5 Contact.aspx Contact 1 6 Email.aspx Email 5 7 Phones.aspx Phone 5
All you need to do is derive from the abstract class SiteMapProvider and override a handful of methods, like GetParentNode and GetChildNodes. These methods can be straightforward to implement with a few pre-built collections of type Dictionary<string, SiteMapNode>. SiteMapNode objects represent the nodes in the site map, while a Dictionary is one of the exciting new classes from the System.Collections.Generic namespace, which you can use to build strongly typed collections.
One you have some code querying SQL Server and implementing the SiteMapProvider methods, you just need to tell the runtime about your new provider via a config file:
<siteMap defaultProvider="MySqlSiteMapProvider" enabled="true"> <providers> <add name="MySqlSiteMapProvider" type="SqlSiteMapProvider" connectionStringKey="ConnectionString"/> </providers> </siteMap>
You can have multiple providers for a site. If half of the site navigation information comes from XML and the other half from the database, that’s quite possible. It will be interesting to see what other providers come out. I'm sure SQL, and File System providers will be in demand.
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.