<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:trackback="http://madskills.com/public/xml/rss/module/trackback/" xmlns:wfw="http://wellformedweb.org/CommentAPI/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/"><channel><title>Ignia Blogs</title><link>http://blogs.ignia.com/MainFeed.aspx</link><description /><generator>Subtext Version 2.1.1.1</generator><item><title>User Administration in .NET 4.0</title><link>http://blogs.ignia.com/Levi.Fleischman/archive/2010/05/26/iismembershipadministration.aspx</link><pubDate>Thu, 27 May 2010 00:23:18 GMT</pubDate><guid isPermaLink="true">http://blogs.ignia.com/Levi.Fleischman/archive/2010/05/26/iismembershipadministration.aspx</guid><wfw:comment>http://blogs.ignia.com/Levi.Fleischman/comments/18.aspx</wfw:comment><wfw:commentRss>http://blogs.ignia.com/Levi.Fleischman/comments/commentRss/18.aspx</wfw:commentRss><comments>http://blogs.ignia.com/Levi.Fleischman/archive/2010/05/26/iismembershipadministration.aspx#comment</comments><slash:comments>2</slash:comments><trackback:ping>http://blogs.ignia.com/Levi.Fleischman/services/trackbacks/18.aspx</trackback:ping><source url="http://blogs.ignia.com/Levi.Fleischman/rss.aspx">User Administration in .NET 4.0</source><description>&lt;p&gt;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.  &lt;/p&gt;
&lt;p&gt;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:&lt;/p&gt;
&lt;blockquote dir="ltr" style="MARGIN-RIGHT: 0px"&gt;
&lt;p&gt;This feature cannot be used because the default provider type could not be determined to check whether it is a trusted provider.&lt;/p&gt;
&lt;p&gt;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).&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p dir="ltr"&gt;Or:&lt;/p&gt;
&lt;blockquote dir="ltr" style="MARGIN-RIGHT: 0px"&gt;
&lt;p dir="ltr"&gt;There was an error while performing this operation.&lt;/p&gt;
&lt;p dir="ltr"&gt;Details:&lt;/p&gt;
&lt;p dir="ltr"&gt;Could not load file or assembly 'System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=&lt;font face=""&gt;b03f5f7f11d50a3a' or one of its dependencies.  The system cannot find the file specified.&lt;/font&gt;&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;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 2.0.0.0 or 4.0.0.0.  &lt;/p&gt;
&lt;p&gt;According to &lt;a href="http://forums.iis.net/p/1166801/1940556.aspx"&gt;comments on the IIS.NET forums&lt;/a&gt;, 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 2.0.0.0 version is unclear to me, but likely has to do with how .NET handles library versions.&lt;/p&gt;
&lt;p&gt;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?  &lt;/p&gt;
&lt;p&gt;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 &lt;em&gt;separate application &lt;/em&gt;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.  &lt;/p&gt;
&lt;p&gt;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.  &lt;/p&gt;
&lt;p&gt;tags: &lt;a rel="tag" href="http://blogs.ignia.com/Levi.Fleischman/Tags/ASP.NET/Default.aspx"&gt;ASP.NET&lt;/a&gt;, &lt;a rel="tag" href="http://blogs.ignia.com/Levi.Fleischman/Tags/ASP.NET 4.0/Default.aspx"&gt;ASP.NET 4.0&lt;/a&gt;, &lt;a rel="tag" href="http://blogs.ignia.com/Levi.Fleischman/Tags/Membership Provider/Default.aspx"&gt;Membership Provider&lt;/a&gt;, &lt;a rel="tag" href="http://blogs.ignia.com/Levi.Fleischman/Tags/RoleProvider/Default.aspx"&gt;Role Provider&lt;/a&gt;, &lt;a rel="tag" href="http://blogs.ignia.com/Levi.Fleischman/Tags/Internet Information Server 7.0/Default.aspx"&gt;Internet Information Server 7.0&lt;/a&gt;, &lt;a rel="tag" href="http://blogs.ignia.com/Levi.Fleischman/Tags/IIS/Default.aspx"&gt;IIS7&lt;/a&gt;. &lt;/p&gt;&lt;img src="http://blogs.ignia.com/Levi.Fleischman/aggbug/18.aspx" width="1" height="1" /&gt;</description><dc:creator>Levi Fleischman</dc:creator></item><item><title>ExtJS with ADO.NET Data Services (Part 2 of 2): Sorting and Paging</title><link>http://blogs.ignia.com/Levi.Fleischman/archive/2009/09/11/extjs.dataservices.paging.aspx.aspx</link><pubDate>Fri, 11 Sep 2009 18:41:30 GMT</pubDate><guid isPermaLink="true">http://blogs.ignia.com/Levi.Fleischman/archive/2009/09/11/extjs.dataservices.paging.aspx.aspx</guid><wfw:comment>http://blogs.ignia.com/Levi.Fleischman/comments/17.aspx</wfw:comment><wfw:commentRss>http://blogs.ignia.com/Levi.Fleischman/comments/commentRss/17.aspx</wfw:commentRss><comments>http://blogs.ignia.com/Levi.Fleischman/archive/2009/09/11/extjs.dataservices.paging.aspx.aspx#comment</comments><slash:comments>4</slash:comments><trackback:ping>http://blogs.ignia.com/Levi.Fleischman/services/trackbacks/17.aspx</trackback:ping><source url="http://blogs.ignia.com/Levi.Fleischman/rss.aspx">ExtJS with ADO.NET Data Services (Part 2 of 2): Sorting and Paging</source><description>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.&lt;img src="http://blogs.ignia.com/Levi.Fleischman/aggbug/17.aspx" width="1" height="1" /&gt;</description><dc:creator>Levi Fleischman</dc:creator></item><item><title>ExtJS with ADO.NET Data Services (Part 1 of 2): RESTful URLs</title><link>http://blogs.ignia.com/Levi.Fleischman/archive/2009/09/10/extjs.dataservices.rest.aspx</link><pubDate>Thu, 10 Sep 2009 18:47:21 GMT</pubDate><guid isPermaLink="true">http://blogs.ignia.com/Levi.Fleischman/archive/2009/09/10/extjs.dataservices.rest.aspx</guid><wfw:comment>http://blogs.ignia.com/Levi.Fleischman/comments/16.aspx</wfw:comment><wfw:commentRss>http://blogs.ignia.com/Levi.Fleischman/comments/commentRss/16.aspx</wfw:commentRss><comments>http://blogs.ignia.com/Levi.Fleischman/archive/2009/09/10/extjs.dataservices.rest.aspx#comment</comments><slash:comments>4</slash:comments><trackback:ping>http://blogs.ignia.com/Levi.Fleischman/services/trackbacks/16.aspx</trackback:ping><source url="http://blogs.ignia.com/Levi.Fleischman/rss.aspx">ExtJS with ADO.NET Data Services (Part 1 of 2): RESTful URLs</source><description>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.&lt;img src="http://blogs.ignia.com/Levi.Fleischman/aggbug/16.aspx" width="1" height="1" /&gt;</description><dc:creator>Levi Fleischman</dc:creator></item><item><title>Dynamically Filtered Ranges in Excel</title><link>http://blogs.ignia.com/Levi.Fleischman/archive/2009/08/20/exceldynamicallyfilteredranges.aspx</link><pubDate>Thu, 20 Aug 2009 21:41:45 GMT</pubDate><guid isPermaLink="true">http://blogs.ignia.com/Levi.Fleischman/archive/2009/08/20/exceldynamicallyfilteredranges.aspx</guid><wfw:comment>http://blogs.ignia.com/Levi.Fleischman/comments/15.aspx</wfw:comment><wfw:commentRss>http://blogs.ignia.com/Levi.Fleischman/comments/commentRss/15.aspx</wfw:commentRss><comments>http://blogs.ignia.com/Levi.Fleischman/archive/2009/08/20/exceldynamicallyfilteredranges.aspx#comment</comments><slash:comments>0</slash:comments><trackback:ping>http://blogs.ignia.com/Levi.Fleischman/services/trackbacks/15.aspx</trackback:ping><source url="http://blogs.ignia.com/Levi.Fleischman/rss.aspx">Dynamically Filtered Ranges in Excel</source><description>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.&lt;img src="http://blogs.ignia.com/Levi.Fleischman/aggbug/15.aspx" width="1" height="1" /&gt;</description><dc:creator>Levi Fleischman</dc:creator></item><item><title>ASP.NET Control Suites vs. JavaScript Frameworks</title><link>http://Blogs.Ignia.com/Jeremy.Caney/archive/2009/08/05/aspnetcontrolsuites.aspx</link><pubDate>Wed, 05 Aug 2009 20:55:49 GMT</pubDate><guid isPermaLink="true">http://Blogs.Ignia.com/Jeremy.Caney/archive/2009/08/05/aspnetcontrolsuites.aspx</guid><wfw:comment>http://Blogs.Ignia.com/Jeremy.Caney/comments/14.aspx</wfw:comment><wfw:commentRss>http://Blogs.Ignia.com/Jeremy.Caney/comments/commentRss/14.aspx</wfw:commentRss><comments>http://Blogs.Ignia.com/Jeremy.Caney/archive/2009/08/05/aspnetcontrolsuites.aspx#comment</comments><slash:comments>1</slash:comments><trackback:ping>http://Blogs.Ignia.com/Jeremy.Caney/services/trackbacks/14.aspx</trackback:ping><source url="http://Blogs.Ignia.com/Jeremy.Caney/rss.aspx">ASP.NET Control Suites vs. JavaScript Frameworks</source><description>Traditionally, wrapping client-side controls in server libraries simplifies integration by abstracting backend and client development. To support this, control developers (e.g., ComponentArt, Infragistics) provide all-inclusive frameworks complete with custom AJAX, JavaScript-enabled controls and server-side APIs. Given modern development practices (e.g., MVC, AJAX) and the maturity of JavaScript frameworks (e.g., Prototype, ExtJS), however, do these benefits still apply?&lt;img src="http://Blogs.Ignia.com/Jeremy.Caney/aggbug/14.aspx" width="1" height="1" /&gt;</description><dc:creator>Jeremy Caney</dc:creator></item><item><title>Mapping ExtJS to custom REST APIs</title><link>http://blogs.ignia.com/Levi.Fleischman/archive/2009/07/26/extjsrest.aspx</link><pubDate>Sun, 26 Jul 2009 20:17:06 GMT</pubDate><guid isPermaLink="true">http://blogs.ignia.com/Levi.Fleischman/archive/2009/07/26/extjsrest.aspx</guid><wfw:comment>http://blogs.ignia.com/Levi.Fleischman/comments/13.aspx</wfw:comment><wfw:commentRss>http://blogs.ignia.com/Levi.Fleischman/comments/commentRss/13.aspx</wfw:commentRss><comments>http://blogs.ignia.com/Levi.Fleischman/archive/2009/07/26/extjsrest.aspx#comment</comments><slash:comments>1</slash:comments><trackback:ping>http://blogs.ignia.com/Levi.Fleischman/services/trackbacks/13.aspx</trackback:ping><source url="http://blogs.ignia.com/Levi.Fleischman/rss.aspx">Mapping ExtJS to custom REST APIs</source><description>Out of the box, ExtJS expects to send and receive data in a very specific format.  Since our customer had an API intended to serve multiple different clients this wasn't practical. By writing custom LoadJson and SubmitJson actions, we were able to centralize this custom logic without the need to configure a redundant JsonReader, JsonWriter and Ajax.request() for each form.&lt;img src="http://blogs.ignia.com/Levi.Fleischman/aggbug/13.aspx" width="1" height="1" /&gt;</description><dc:creator>Levi Fleischman</dc:creator></item><item><title>ASP.NET AJAX WebMethods</title><link>http://blogs.ignia.com/Levi.Fleischman/archive/2009/07/25/webmethod.aspx</link><pubDate>Sun, 26 Jul 2009 01:45:02 GMT</pubDate><guid isPermaLink="true">http://blogs.ignia.com/Levi.Fleischman/archive/2009/07/25/webmethod.aspx</guid><wfw:comment>http://blogs.ignia.com/Levi.Fleischman/comments/12.aspx</wfw:comment><wfw:commentRss>http://blogs.ignia.com/Levi.Fleischman/comments/commentRss/12.aspx</wfw:commentRss><comments>http://blogs.ignia.com/Levi.Fleischman/archive/2009/07/25/webmethod.aspx#comment</comments><slash:comments>0</slash:comments><trackback:ping>http://blogs.ignia.com/Levi.Fleischman/services/trackbacks/12.aspx</trackback:ping><source url="http://blogs.ignia.com/Levi.Fleischman/rss.aspx">ASP.NET AJAX WebMethods</source><description>A particularly overlooked and, for its simplicity, useful feature of ASP.NET AJAX is the WebMethod, which is a server-side method that can be called by client script.  The .NET compiler automatically adds client-side methods that take care of the AJAX request, JSON encoding and, to a degree, data type conversion. Sure, you COULD do this using a web service and XmlHttpRequest - but this is a quick-and-easy way of AJAX-enabling standard web form pages.&lt;img src="http://blogs.ignia.com/Levi.Fleischman/aggbug/12.aspx" width="1" height="1" /&gt;</description><dc:creator>Levi Fleischman</dc:creator></item><item><title>ASP.NET AJAX 1.0</title><link>http://blogs.ignia.com/Levi.Fleischman/archive/2009/07/25/microsoftajax.aspx</link><pubDate>Sun, 26 Jul 2009 00:19:03 GMT</pubDate><guid isPermaLink="true">http://blogs.ignia.com/Levi.Fleischman/archive/2009/07/25/microsoftajax.aspx</guid><wfw:comment>http://blogs.ignia.com/Levi.Fleischman/comments/11.aspx</wfw:comment><wfw:commentRss>http://blogs.ignia.com/Levi.Fleischman/comments/commentRss/11.aspx</wfw:commentRss><comments>http://blogs.ignia.com/Levi.Fleischman/archive/2009/07/25/microsoftajax.aspx#comment</comments><slash:comments>0</slash:comments><trackback:ping>http://blogs.ignia.com/Levi.Fleischman/services/trackbacks/11.aspx</trackback:ping><source url="http://blogs.ignia.com/Levi.Fleischman/rss.aspx">ASP.NET AJAX 1.0</source><description>Microsoft has a long history of misnamed and mis-marketed developer tools. My favorite example is .NET, a relatively simple concept complicated by an initial decision to attach the label to Microsoft's upcoming generation of servers (e.g., "Windows .NET Server 2003"). The latest blunder is ASP.NET AJAX, a useful suite of technologies only partially related to "AJAX" development.  Unfortunately, as a result of this some of the more useful aspects of the technology have been overlooked.&lt;img src="http://blogs.ignia.com/Levi.Fleischman/aggbug/11.aspx" width="1" height="1" /&gt;</description><dc:creator>Levi Fleischman</dc:creator></item><item><title>The "Web 2.0" Aesthetic</title><link>http://Blogs.Ignia.com/Jeremy.Caney/archive/2009/07/25/webv2.aspx</link><pubDate>Sat, 25 Jul 2009 22:54:05 GMT</pubDate><guid isPermaLink="true">http://Blogs.Ignia.com/Jeremy.Caney/archive/2009/07/25/webv2.aspx</guid><wfw:comment>http://Blogs.Ignia.com/Jeremy.Caney/comments/10.aspx</wfw:comment><wfw:commentRss>http://Blogs.Ignia.com/Jeremy.Caney/comments/commentRss/10.aspx</wfw:commentRss><comments>http://Blogs.Ignia.com/Jeremy.Caney/archive/2009/07/25/webv2.aspx#comment</comments><slash:comments>0</slash:comments><trackback:ping>http://Blogs.Ignia.com/Jeremy.Caney/services/trackbacks/10.aspx</trackback:ping><source url="http://Blogs.Ignia.com/Jeremy.Caney/rss.aspx">The "Web 2.0" Aesthetic</source><description>I've never been fond of the term "Web 2.0" - in part because it's often used to imply a new suite of technologies even though it's largely founded on concepts that have been well-established (but not widely-utilized) for over a decade.  For example, XMLHttpRequest - the backbone of the AJAX style of development - first shipped with Internet Explorer 5.0 in 1999.  The term thus struck me as another example of the popular trend in software of rebranding old technologies as the "next big thing".&lt;img src="http://Blogs.Ignia.com/Jeremy.Caney/aggbug/10.aspx" width="1" height="1" /&gt;</description><dc:creator>Jeremy Caney</dc:creator></item><item><title>Backing up and Restoring Boot Camp Partitions</title><link>http://Blogs.Ignia.com/Jeremy.Caney/archive/2009/03/19/backing-up-and-restoring-boot-camp-partitions.aspx</link><pubDate>Fri, 20 Mar 2009 06:49:49 GMT</pubDate><guid isPermaLink="true">http://Blogs.Ignia.com/Jeremy.Caney/archive/2009/03/19/backing-up-and-restoring-boot-camp-partitions.aspx</guid><wfw:comment>http://Blogs.Ignia.com/Jeremy.Caney/comments/9.aspx</wfw:comment><wfw:commentRss>http://Blogs.Ignia.com/Jeremy.Caney/comments/commentRss/9.aspx</wfw:commentRss><comments>http://Blogs.Ignia.com/Jeremy.Caney/archive/2009/03/19/backing-up-and-restoring-boot-camp-partitions.aspx#comment</comments><slash:comments>3</slash:comments><trackback:ping>http://Blogs.Ignia.com/Jeremy.Caney/services/trackbacks/9.aspx</trackback:ping><source url="http://Blogs.Ignia.com/Jeremy.Caney/rss.aspx">Backing up and Restoring Boot Camp Partitions</source><description>The majority of our workstations are Apples running Windows Vista (we are, after all, Windows developers).  This introduces certain IT challenges - the most notable being backing up of the operating system.  This post discusses various approaches to solving this problem, including must have tools and general recommendations.&lt;img src="http://Blogs.Ignia.com/Jeremy.Caney/aggbug/9.aspx" width="1" height="1" /&gt;</description><dc:creator>Jeremy Caney</dc:creator></item><item><title>Google Chrome</title><link>http://Blogs.Ignia.com/Jeremy.Caney/archive/2008/09/03/google-chrome.aspx</link><pubDate>Thu, 04 Sep 2008 08:18:40 GMT</pubDate><guid isPermaLink="true">http://Blogs.Ignia.com/Jeremy.Caney/archive/2008/09/03/google-chrome.aspx</guid><wfw:comment>http://Blogs.Ignia.com/Jeremy.Caney/comments/8.aspx</wfw:comment><wfw:commentRss>http://Blogs.Ignia.com/Jeremy.Caney/comments/commentRss/8.aspx</wfw:commentRss><comments>http://Blogs.Ignia.com/Jeremy.Caney/archive/2008/09/03/google-chrome.aspx#comment</comments><slash:comments>1</slash:comments><trackback:ping>http://Blogs.Ignia.com/Jeremy.Caney/services/trackbacks/8.aspx</trackback:ping><source url="http://Blogs.Ignia.com/Jeremy.Caney/rss.aspx">Google Chrome</source><description>Despite a bias against both Google as well as new entries into the browser market, I'm quite impressed by Chrome.  More importantly, however, I feel that Google is well-positioned to drive progress in the W3C in a way that Firefox hasn't even attempted and which Microsoft was destined to fail due to fundamental disagreements in style.  &lt;img src="http://Blogs.Ignia.com/Jeremy.Caney/aggbug/8.aspx" width="1" height="1" /&gt;</description><dc:creator>Jeremy Caney</dc:creator></item><item><title>MSDN Code Gallery</title><link>http://Blogs.Ignia.com/Jeremy.Caney/archive/2008/04/03/msdn-code-gallery.aspx</link><pubDate>Fri, 04 Apr 2008 00:27:18 GMT</pubDate><guid isPermaLink="true">http://Blogs.Ignia.com/Jeremy.Caney/archive/2008/04/03/msdn-code-gallery.aspx</guid><wfw:comment>http://Blogs.Ignia.com/Jeremy.Caney/comments/7.aspx</wfw:comment><wfw:commentRss>http://Blogs.Ignia.com/Jeremy.Caney/comments/commentRss/7.aspx</wfw:commentRss><comments>http://Blogs.Ignia.com/Jeremy.Caney/archive/2008/04/03/msdn-code-gallery.aspx#comment</comments><slash:comments>0</slash:comments><trackback:ping>http://Blogs.Ignia.com/Jeremy.Caney/services/trackbacks/7.aspx</trackback:ping><source url="http://Blogs.Ignia.com/Jeremy.Caney/rss.aspx">MSDN Code Gallery</source><description>Microsoft recently released the the MSDN Code Gallery. Compared to CodePlex, the site offers less project management, collaboration and source control features and, in concept, is more optimized for quickly publishing code snippets. Unfortunately, though, I don't think think they went far enough in simplifying CodePlex and, as such, it's impractical for its intended purpose.&lt;img src="http://Blogs.Ignia.com/Jeremy.Caney/aggbug/7.aspx" width="1" height="1" /&gt;</description><dc:creator>Jeremy Caney</dc:creator></item><item><title>ORM vs. DAL</title><link>http://Blogs.Ignia.com/Jeremy.Caney/archive/2007/11/24/orm-vs.-dal.aspx</link><pubDate>Sun, 25 Nov 2007 01:55:14 GMT</pubDate><guid isPermaLink="true">http://Blogs.Ignia.com/Jeremy.Caney/archive/2007/11/24/orm-vs.-dal.aspx</guid><wfw:comment>http://Blogs.Ignia.com/Jeremy.Caney/comments/6.aspx</wfw:comment><wfw:commentRss>http://Blogs.Ignia.com/Jeremy.Caney/comments/commentRss/6.aspx</wfw:commentRss><comments>http://Blogs.Ignia.com/Jeremy.Caney/archive/2007/11/24/orm-vs.-dal.aspx#comment</comments><slash:comments>0</slash:comments><trackback:ping>http://Blogs.Ignia.com/Jeremy.Caney/services/trackbacks/6.aspx</trackback:ping><source url="http://Blogs.Ignia.com/Jeremy.Caney/rss.aspx">ORM vs. DAL</source><description>During a discussion this weekend I realized that a lot of the complexity of DAL and ORM projects stems from the attempt to accomplish both needs in the same library. And perhaps that makes sense; it might be argued that the only pragmatic difference is cache strategy.  Nonetheless, as with all development projects, identifying the project requirements and evaluating them against the innate benefits of each approach is critical.&lt;img src="http://Blogs.Ignia.com/Jeremy.Caney/aggbug/6.aspx" width="1" height="1" /&gt;</description><dc:creator>Jeremy Caney</dc:creator></item><item><title>Navigating by Tags</title><link>http://Blogs.Ignia.com/Jeremy.Caney/archive/2007/11/16/navigating-by-tags.aspx</link><pubDate>Sat, 17 Nov 2007 10:48:02 GMT</pubDate><guid isPermaLink="true">http://Blogs.Ignia.com/Jeremy.Caney/archive/2007/11/16/navigating-by-tags.aspx</guid><wfw:comment>http://Blogs.Ignia.com/Jeremy.Caney/comments/5.aspx</wfw:comment><wfw:commentRss>http://Blogs.Ignia.com/Jeremy.Caney/comments/commentRss/5.aspx</wfw:commentRss><comments>http://Blogs.Ignia.com/Jeremy.Caney/archive/2007/11/16/navigating-by-tags.aspx#comment</comments><slash:comments>0</slash:comments><trackback:ping>http://Blogs.Ignia.com/Jeremy.Caney/services/trackbacks/5.aspx</trackback:ping><source url="http://Blogs.Ignia.com/Jeremy.Caney/rss.aspx">Navigating by Tags</source><description>I have mixed views on tagging.  On one hand, I agree that most information architecture forces the user to channel the content owner in order to find content; the inability to (easily) cross-reference data into multiple categories in most systems compounds this problem.  At the same time, tagging doesn't innately solve this.  With this in mind, Ignia has implented a different strategy for tagging that begins to address some of these limitations.&lt;img src="http://Blogs.Ignia.com/Jeremy.Caney/aggbug/5.aspx" width="1" height="1" /&gt;</description><dc:creator>Jeremy Caney</dc:creator></item><item><title>MOSS 2007: Lessons Learned</title><link>http://Blogs.Ignia.com/Jeremy.Caney/archive/2007/11/16/moss-2007-lessons-learned.aspx</link><pubDate>Sat, 17 Nov 2007 09:56:38 GMT</pubDate><guid isPermaLink="true">http://Blogs.Ignia.com/Jeremy.Caney/archive/2007/11/16/moss-2007-lessons-learned.aspx</guid><wfw:comment>http://Blogs.Ignia.com/Jeremy.Caney/comments/4.aspx</wfw:comment><wfw:commentRss>http://Blogs.Ignia.com/Jeremy.Caney/comments/commentRss/4.aspx</wfw:commentRss><comments>http://Blogs.Ignia.com/Jeremy.Caney/archive/2007/11/16/moss-2007-lessons-learned.aspx#comment</comments><slash:comments>2</slash:comments><trackback:ping>http://Blogs.Ignia.com/Jeremy.Caney/services/trackbacks/4.aspx</trackback:ping><source url="http://Blogs.Ignia.com/Jeremy.Caney/rss.aspx">MOSS 2007: Lessons Learned</source><description>We've done quite a few SharePoint 2007 sites but a recent project required diving much deeper into the product, including extensive use of custom web parts, search indexes and registration on top of the standard arsenal of master pages, layouts, XSL style sheets, web part definitions, etc. Additionally, this was the first MOSS project for two of the project members which meant a steep learning curve for the team.  This post discusses some of the lessons learned.&lt;img src="http://Blogs.Ignia.com/Jeremy.Caney/aggbug/4.aspx" width="1" height="1" /&gt;</description><dc:creator>Jeremy Caney</dc:creator></item><item><title>Standards Zealots</title><link>http://Blogs.Ignia.com/Jeremy.Caney/archive/2007/05/13/standards-zealots.aspx</link><pubDate>Mon, 14 May 2007 09:53:49 GMT</pubDate><guid isPermaLink="true">http://Blogs.Ignia.com/Jeremy.Caney/archive/2007/05/13/standards-zealots.aspx</guid><wfw:comment>http://Blogs.Ignia.com/Jeremy.Caney/comments/3.aspx</wfw:comment><wfw:commentRss>http://Blogs.Ignia.com/Jeremy.Caney/comments/commentRss/3.aspx</wfw:commentRss><comments>http://Blogs.Ignia.com/Jeremy.Caney/archive/2007/05/13/standards-zealots.aspx#comment</comments><slash:comments>6</slash:comments><trackback:ping>http://Blogs.Ignia.com/Jeremy.Caney/services/trackbacks/3.aspx</trackback:ping><source url="http://Blogs.Ignia.com/Jeremy.Caney/rss.aspx">Standards Zealots</source><description>Given my firm's rigid code formatting, organization and commenting standards I may seem like the person least likely to criticize standards zealots. Nevertheless, hearing terms like "web standards" or "semantic web" makes me cringe. It's not that there is anything wrong with these concepts (contrary!) so much that their proponents have become so mired in the principals that they've forgotten the objectives - as well as those of their clients.&lt;img src="http://Blogs.Ignia.com/Jeremy.Caney/aggbug/3.aspx" width="1" height="1" /&gt;</description><dc:creator>Jeremy Caney</dc:creator></item><item><title>MOSS 2007 Tip: Customizing the CQWP</title><link>http://Blogs.Ignia.com/Jeremy.Caney/archive/2007/04/14/moss-2007-tip-customizing-the-cqwp.aspx</link><pubDate>Sun, 15 Apr 2007 02:34:52 GMT</pubDate><guid isPermaLink="true">http://Blogs.Ignia.com/Jeremy.Caney/archive/2007/04/14/moss-2007-tip-customizing-the-cqwp.aspx</guid><wfw:comment>http://Blogs.Ignia.com/Jeremy.Caney/comments/2.aspx</wfw:comment><wfw:commentRss>http://Blogs.Ignia.com/Jeremy.Caney/comments/commentRss/2.aspx</wfw:commentRss><comments>http://Blogs.Ignia.com/Jeremy.Caney/archive/2007/04/14/moss-2007-tip-customizing-the-cqwp.aspx#comment</comments><slash:comments>0</slash:comments><trackback:ping>http://Blogs.Ignia.com/Jeremy.Caney/services/trackbacks/2.aspx</trackback:ping><source url="http://Blogs.Ignia.com/Jeremy.Caney/rss.aspx">MOSS 2007 Tip: Customizing the CQWP</source><description>Many SharePoint 2007 articles discussing the customization of the Content Query Web Part assume access to the centralized style library.  Users without this access can still customize the CQWP's XSL file by modifying the Web Part Definition file's ItemXslLink node.&lt;img src="http://Blogs.Ignia.com/Jeremy.Caney/aggbug/2.aspx" width="1" height="1" /&gt;</description><dc:creator>Jeremy Caney</dc:creator></item><item><title>Sprocs with regard to DALs</title><link>http://Blogs.Ignia.com/Jeremy.Caney/archive/2007/04/14/dalsprocs.aspx</link><pubDate>Sun, 15 Apr 2007 00:59:59 GMT</pubDate><guid isPermaLink="true">http://Blogs.Ignia.com/Jeremy.Caney/archive/2007/04/14/dalsprocs.aspx</guid><wfw:comment>http://Blogs.Ignia.com/Jeremy.Caney/comments/1.aspx</wfw:comment><wfw:commentRss>http://Blogs.Ignia.com/Jeremy.Caney/comments/commentRss/1.aspx</wfw:commentRss><comments>http://Blogs.Ignia.com/Jeremy.Caney/archive/2007/04/14/dalsprocs.aspx#comment</comments><slash:comments>2</slash:comments><trackback:ping>http://Blogs.Ignia.com/Jeremy.Caney/services/trackbacks/1.aspx</trackback:ping><source url="http://Blogs.Ignia.com/Jeremy.Caney/rss.aspx">Sprocs with regard to DALs</source><description>I sat down to write a defense of stored procedures with specific regard to DAL/ORM solutions, but found myself painted into a corner.  When it comes to generated code, many of the benefits of stored procedures start to crumble - or, at least, deny the luxury of automated approaches.&lt;img src="http://Blogs.Ignia.com/Jeremy.Caney/aggbug/1.aspx" width="1" height="1" /&gt;</description><dc:creator>Jeremy Caney</dc:creator></item></channel></rss>
