While the ability to edit the Ribbon in Microsoft Office was a welcome addition to Outlook 2010, a limitation that has continued to annoy me is the inability to control the size of commands. This can result in a junky looking ribbon since many of the older commands use non-scalable, vector based icons which look messy when displayed in larger dimensions. Conversely, other commands provide a different (and, perhaps, more desirable) interface when displayed larger, such as the "Styles" command.
While the "Customize the Ribbon..." user interface doesn't provide options for controlling these, the metadata file used for importing and exporting ribbon customization (via "exportedUI" files) does. Unfortunately, the schema for this file format doesn't appear to be documented, but MSDN's article Deploying a Customized Ribbon and Quick Access Toolbar in Office 2010 does expose a couple of attributes you might not otherwise identify which can help with the above limitations. This provides some extended control by editing the file in any text editor (such as notepad.exe).
The first of these is the highDensityLayout attribute of the group element; this forces command elements within that group to use the smaller layout. The second is the showInRibbon attribute of the gallery element; this forces gallery commands to be displayed in full size, independent of whether the highDensityLayout attribute is set. (The latter attribute is actually exposed by a standard export, but appears to always set to "false", at least in Office 2013 Consumer Preview).
There are likely other attributes available for the schema that provide even more granular control, such as the ability to specify the icon size for each individual command. I wasn't able to find these, but admittedly didn't dig too deep. If you happen to know where a schema reference is, please let me know. My guess is that these correspond to VBA properties and thus may be documented as part of the VBA object reference. In the meanwhile, this addresses two of the irritations I've found when customizing the ribbon.
Also note that this likely works in Microsoft Office 2010 as well, although I haven't tested that.
One of the handy features of IIS7 is the ability to manage users from within IIS Manager. This can be done using the ".NET Users", ".NET Roles", ".NET Profile" applets exposed by the features view. These are able to interact with any (strongly typed) ASP.NET Membership, Roles or Profile provider - assuming it's configured as the default provider in your web.config file. While the interface isn't great, it's definitely functional, and these tools make it easy to jump-start a new membership application.
Unfortunately, however, these tools aren't available if your website's application pool is running under ASP.NET 4.0. When you load IIS7, the icons related to these applets will be removed. If you add a new application (or convert an existing application) to the ASP.NET 4.0 application pool then the icons will be available, but clicking on them will give you one of the following errors:
This feature cannot be used because the default provider type could not be determined to check whether it is a trusted provider.
You can use this feature only when the default provider is a trusted provider. If you are a server administrator, you can make a provider a trusted provider by added the provider type to the trusted providers list in the Administration.config file. The provider has to be strongly typed and added to the GAC (Global Assembly Cache).
There was an error while performing this operation.
Could not load file or assembly 'System.Web, Version=22.214.171.124, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.
The first one appears if the providers' "type" attribute in the web.config does not contain a fully-qualified reference to the strongly-typed assembly (e.g., if it doesn't contain the PublicKeyToken) - which is the default provider scaffolding for Visual Studio 2010. The latter will occur regardless of whether or not the version is set to 126.96.36.199 or 188.8.131.52.
According to comments on the IIS.NET forums, this is due to the fact that this would require IIS to load .NET 4.0 libraries, which it apparently can't do since it's a .NET 2.0 application. Why it's unable to load this even if you explicitly specify the 184.108.40.206 version is unclear to me, but likely has to do with how .NET handles library versions.
Regardless of the cause, the solution to this is to either a) continue to use ASP.NET 2.0, or b) write a custom application interface using the provider interface - but who wants to do that?
There is one way of having the best of both worlds, however. Since the providers typically reference an external data store (such as an XML file, web service or SQL server) it's possible to have multiple website applications accessing the same data store. As a result, you can setup a separate application in IIS which runs under the ASP.NET 2.0 application pool and can, thus, manage your users. In fact, because IIS allows a virtual application to use a different application pool even if that application pool runs under a different version of ASP.NET, it's possible to simply setup this application as a virtual application underneath your existing website (it doesn't matter what path this points to). The advantage to this is the virtual application will inherit the provider settings from the parent website and, thus, there is no need to decentralize the configuration of your providers. This also eliminates the need to have a separate faux website listed in IIS; you'll still end up with a faux application, of course, but at least it's clearly associated with the parent website.
Once this is setup, you can click on the virtual application (I called mine "UserAdmin") in IIS and you'll have access to the ".NET Users", ".NET Roles" and ".NET Profile" applets again.
tags: ASP.NET, ASP.NET 4.0, Membership Provider, Role Provider, Internet Information Server 7.0, IIS7.
ExtJs's conventions don't directly map to those used by ADO.NET Data Services, but that doesn't mean they can't work together. One disconnect is the syntax for sorting and paging, as expected by Ext.grid.GridPanel and Ext.PagingToolbar. This post explores options to mitigating this disconnect.
ADO.NET Data Services quickly exposes a database as a RESTful web service, including query support. This is useful for AJAX applications, such as those built with ExtJS. Unfortunately, however,while ExtJS 3.0 has built-in REST support, its conventions don’t map well to Data Services. The most obvious case is composite primary keys (e.g., "/Store.svc/Cart(UserID=1,ProductID)"). This post discusses a simple way of accomodating these.
A common requirement in Excel is the ability to provide a dropdown list based on values the user has entered, a technique known as Cascading drop downs. For instance, a user selects "BMW" from manufacturer and the corresponding model cell provides a list of options including "M5", "Z4" and "X6". This post examines one approach to solving this problem - although the technique can be applied to many related problems.