Category Archives: Visual Studio

jQuery Code Snippets for Visual Studio

I contributed a Getting Started Guide to the open source jQuery Code Snippets project earlier today.  Honestly, it doesn’t take much to install the bits and reap the benefits of the snippet collection, but I ran into a minor snag (as did another commenter) and I figured that documentation couldn’t hurt.  Of course, the jury is still out on this one.

If you are new to code snippets, shortcuts and IntelliSense support in Visual Studio, John Sheehan posted a 25 Second Demo Video showing the jQuery Snippets in action.   If you like what you see, simply download the file from CodePlex, extract the contents, run the provided jQuerySnippets.msi and you’re good to go.  Now go forth and code with snippet magic.

Wait! I mentioned something about a minor snag.  Right. I’m running ReSharper.  Maybe you are too?  As you might know, ReSharper offers its own snippets library which sometimes overrides the Visual Studio IntelliSense features. In order to take full advantage of the Visual Studio snippets, you may need to modify your default ReSharper options. If you have installed the jQuery Snippets and the behavior isn’t as promised, visit Tools > Options > ReSharper > General and toggle your ReSharper selection to “Visual Studio.”


Note, if you wish to maintain “ReSharper” as your default option, you may still use the jQuery Snippets but you won’t have the luxury of using IntelliSense as a guide.  Just provide the full shortcut and hit Tab. 

Try out the jQuery Code Snippets for Visual Studio 2010 and please let me know if there’s anything I should add to the Getting Started Guide.

Web Deployment Projects and WebConfigReplacementFiles for Custom Sections

I have previously explained how to properly configure your web deployment projects to replace web.config sections.  The example I used was pretty standard – swap out connection strings to support the specific deployment environment.  It worked great, right?  Well, today this technique complete fell short for me as I was dealing with a custom section. 

We recently introduced NServiceBus message sending into our ASP.NET MVC 2 web application.  It’s working so well I can hardly believe it.  Anyway, we put a two configSections in place for the NServiceBus:

  1. <configSections>
  2.   <section name="MsmqTransportConfig"
  3.     type="NServiceBus.Config.MsmqTransportConfig, NServiceBus.Core"></section>
  4.   <section name="UnicastBusConfig"
  5.     type="NServiceBus.Config.UnicastBusConfig, NServiceBus.Core"></section>
  6. </configSections>

  1. <!– NServiceBus –>
  2. <MsmqTransportConfig InputQueue="SendingEndpointQueue"
  3.     ErrorQueue="error" NumberOfWorkerThreads="1" MaxRetries="5"></MsmqTransportConfig>
  4. <UnicastBusConfig>
  5.     <MessageEndpointMappings>
  6.         <add Messages="Project.Messages" Endpoint="ReceivingEndpointQueue"></add>
  7.     </MessageEndpointMappings>
  8. </UnicastBusConfig>

When I attempted to replace these settings, the WDP threw the following build exception:

An error occurred creating the configuration section handler for MsmqTransportConfig: Could not load file or assembly NServiceBus.Core’ or one of its dependencies.  The system cannot find the file specified.

I tried a number of workarounds, but I wasn’t able to resolve the issue.  In the end, I abandoned the WebConfigReplacement technique and started replacing the entire the web.config file using an ExcludeFromBuild command…

  1. <ItemGroup Condition="'$(Configuration)|$(Platform)' == 'Release|AnyCPU'">
  2.   <ExcludeFromBuild Include="$(SourceWebPhysicalPath)\obj\**\*.*" />
  3.   <ExcludeFromBuild Include="$(SourceWebPhysicalPath)\**\.svn\**\*.*" />
  4.   <ExcludeFromBuild Include="$(SourceWebPhysicalPath)\**\.svn\**\*" />
  5.   <ExcludeFromBuild Include="$(SourceWebPhysicalPath)\**\*.csproj" />
  6.   <ExcludeFromBuild Include="$(SourceWebPhysicalPath)\**\*.user" />
  7.   <ExcludeFromBuild Include="$(SourceWebPhysicalPath)\bin\*.pdb" />
  8.   <ExcludeFromBuild Include="$(SourceWebPhysicalPath)\Notes.txt" />
  10.   <!– WebConfigReplacement validates configSection references before
  11.         replacement and NServiceBus.Core or dependencies could not be found.
  12.         Now we are excluding web.config from build as it will be
  13.         manually replaced in BeforeBuild step.   –>
  14.   <ExcludeFromBuild Include="$(SourceWebPhysicalPath)\web.config" />
  15. </ItemGroup>

…and a BeforeBuild Copy task…

  1. <Target Name="BeforeBuild">
  2.   <Copy SourceFiles="$(SourceWebPhysicalPath)\Config\Web.Int.config"
  3.         DestinationFiles="$(CopyBeforeBuildTargetPath)\web.config" />
  4. </Target>

This approach considerably reduced the number of configuration files which I need to manage.  And it works too.  I’m not saying you should change your approach, but be aware of the potential issue if you start to implement custom configuration sections. 

Note: I’ve read that the WebConfigReplacement technique will only work for types which have been installed in the GAC.  I added NServiceBus.dll and NServiceBus.Core.dll to the GAC and that didn’t make much difference.  Perhaps NServiceBus.Core dependencies are the culprit?  I also read that some folks have implemented their own msbuild task to do a simple text replacement of the configSource property to solve this problem. The configSource property isn’t made available by NServiceBus and I didn’t go ahead and add it.Lazy me. Last thought: I tried many things but flipping the <ValidateWebConfigReplacement> switch to false would fix everything.  It didn’t.

T4Toolbox and Visual Studio 2010

I’ve been using the T4Toolbox to help generate my ASP.NET MVC models and scaffolding for a while now.  Another developer tried using my generator project last week and ran into troubles due to a breaking change around the RenderCore() and TransformText() methods in support for VS 2010

If you upgraded to the latest version of T4Toolbox and receive a build error similar to the following, you are probably in the same boat:

GeneratedTextTransformation.[Template].RenderCore(): no suitable method found to override

We took the easy way out.  I had him uninstall the latest version of T4Toolbox and install version which my templates were initially coded against.  For now, that worked great, but it sounds like I’ll be doing some rework of the 20+ templates in my project to support Visual Studio 2010 when we migrate later this month.

Uncovering Compiler Errors in ASP.NET MVC Views

ASPX and ASCX files are compiled on the fly when they are requested on the web server. This means it’s possible that you aren’t catching compile errors associated with your views when you build your ASP.NET MVC project in Visual Studio.  Unless you’re willing to click through your entire application, rendering each view looking for errors, you application is left a little vulnerable to user issues. 

Fortunately, there’s a work around.  Open up your MVC project file in notepad or within the Visual Studio IDE by unloading the project and then editing the .csproj file (both actions are available by right-clicking on the Project Node in Solution Explorer.)  Notice the MvcBuildViews option.  It’s probably set to false.  Flip the value to true and you’ll magically start compiling your views when you build your application.

  1. <MvcBuildViews>false</MvcBuildViews>

Taking this action will slow down your builds a bit, but if you’re a hack like me, it’ll probably save your day in the long run.

Now you’re probably thinking, “Neat trick – how’s it work?”  Scroll down toward the bottom of your csproj file and you will notice the AfterBuild target triggers the AspNetCompiler action if the MvcBuildViews option is set to true. 

  1. <Target Name="AfterBuild" Condition="'$(MvcBuildViews)'=='true'">
  2.   <AspNetCompiler VirtualPath="temp"
  3.                   PhysicalPath="$(ProjectDir)\..\$(ProjectName)" />
  4. </Target>

Great. One more thing. Let’s say you don’t want to slow down all of your builds, but you absolutely want to know if there are any compiler issues with your views before you commit your code to version control or deploy or whatever.  Here’s what you can do – change the AfterBuild condition to run if your configuration is set to Release mode. 

  1. <Target Name="AfterBuild" Condition="'$(Configuration)'=='Release'">
  2.   <!– Always pre-compile ASPX and ASCX in release mode –>
  3.   <AspNetCompiler VirtualPath="temp"
  4.                   PhysicalPath="$(ProjectDir)\..\$(ProjectName)" />
  5. </Target>

Now your debug mode builds will continue to be as fast as ever and you can quickly validate your views by building in release mode when you so choose.  There’s one little catch – this setup won’t consider the MvcBuildViews option whatsoever! So if you decide to go with this configuration, you might want to add a comment near the MvcBuildViews option letting other developers know they can change the MvcBuildViews option as much as they’d like but it’s not going to affect the AfterBuild action.  Or don’t include the comment and let your team members figure it out for themselves…

Managing .NET External Dependencies

Noah and I continue our screencast series by sharing our approach to managing external dependencies referenced within a .NET solution.  This is another introductory episode but you might find a hidden gem in the short 4-minute clip. 

ELMAH (Error Logging Modules and Handlers) is the external dependencies we are focusing on in the presentation.  If you are not familiar with ELMAH, this episode may be worth your time.


This is one of our first screencasts.  If you have feedback, I’d love to hear it.

Visual Studio 2008 Solution Setup

In this screencast, Noah and I demonstrate preferred practices around .NET solution setup, naming conventions and version control.  I consider this an introductory video.  If you’ve been around the block, you might want to skip this episode but if you’re a .NET/Visual Studio newbie, it may be worth a look. 



This is one of our first screencasts.  Actually it is the very first.  If you have feedback, I’d love to hear it.

Deploy ASP.NET Web Applications with Web Deployment Projects

One may quickly build and deploy an ASP.NET web application via the Publish option in Visual Studio.  This option works great for most simple deployment scenarios but it won’t always cut it.  Let’s say you need to automate your deployments. Or you have environment-specific configuration settings. Or you need to execute pre/post build operations when you do your builds.  If so, you should consider using Web Deployment Projects.


The Web Deployment Project type doesn’t come out-of-the-box with Visual Studio 2008.  You’ll need to Download Visual Studio® 2008 Web Deployment Projects – RTW and install if you want to follow along with this tutorial.

I’ve created a shiny new ASP.NET MVC project.  Web Deployment Projects work with websites, web applications and MVC projects so feel free to go with any web project type you’d like. 


Once your web application is in place, it’s time to add the Web Deployment project.  You can hunt and peck around the File > New > New Project… dialogue as long as you’d like, but you aren’t going to find what you need.  Instead, select the web project and then choose the “Add Web Deployment Project…” hiding behind the Build menu option.


I prefer to name my projects based on the environment in which I plan to deploy.  In this case, I’ll be rolling to the QA machine.


Don’t expect too much to happen at this point.  A seemingly empty project with a funny icon will be added to your solution.  That’s it.


I want to take a minute and talk about configuration settings before we continue.  Some of the common settings which might change from environment to environment are appSettings, connectionStrings and mailSettings.  Here’s a look at my updated web.config:

  1. <appSettings>
  2.   <add key="MvcApplication293.Url" value="http://localhost:50596/" />    
  3. </appSettings>
  4. <connectionStrings>
  5.   <add name="ApplicationServices"
  6.        connectionString="data source=.\SQLEXPRESS;Integrated Security=SSPI;AttachDBFilename=|DataDirectory|aspnetdb.mdf;User Instance=true"
  7.        providerName="System.Data.SqlClient"/>
  8. </connectionStrings>
  10. <>
  11.   <mailSettings>
  12.     <smtp from="">
  13.         <network host="" userName="username" password="password" port="587" defaultCredentials="false"/>
  14.     </smtp>
  15.   </mailSettings>
  16. </>

I want to update these values prior to deploying to the QA environment.  There are variations to this approach, but I like to maintain environment-specific settings for each of the web.config sections in the Config/[Environment] project folders.  I’ve provided a screenshot of the QA environment settings below.


It may be obvious what one should include in each of the three files.  Basically, it is a copy of the associated web.config section with updated setting values.  For example, the AppSettings.config file may include a reference to the QA web url, the DB.config would include the QA database server and login information and the StmpSettings.config would include a QA Stmp server and user information.

  1. <?xml version="1.0" encoding="utf-8" ?>
  2. <appSettings>
  3.   <add key="MvcApplication293.Url" value="" />
  4. </appSettings>


  1. <?xml version="1.0" encoding="utf-8" ?>
  2. <connectionStrings>
  3.   <add name="ApplicationServices"
  4.        connectionString="server=QAServer;integrated security=SSPI;database=MvcApplication293"
  5.        providerName="System.Data.SqlClient"/>  
  6. </connectionStrings>


  1. <?xml version="1.0" encoding="utf-8" ?>
  2. <smtp from="">
  3.     <network host="" userName="qausername" password="qapassword" port="587" defaultCredentials="false"/>
  4. </smtp>


I think our web project is ready to deploy.  Now, it’s time to concentrate on the Web Deployment Project itself.  Right-click on the project file and open the Property Pages.


The first thing to call out is the Configuration dropdown.  I only deploy a project which is built in Release Mode so I only setup the Web Deployment Project for this mode.  (This is when you change the Configuration selection to “Release.”)  I typically keep the Output Folder default value – .\Release\.  When the application is built, all artifacts will be dropped in the .\Release\ folder relative to the Web Deployment Project root.  The final option may be up for some debate.  I like to roll out updatable websites so I select the “Allow this precompiled site to be updatable” option.  I really do like to follow standard SDLC processes when I release my software but there are those times when you just have to make a hotfix to production and I like to keep this option open if need be.  If you are strongly opposed to this idea, please, by all means, don’t check the box.


The next tab is boring.  I don’t like to deploy a crazy number of DLLs so I merge all outputs to a single assembly.  Again, you may have another option and feel free to change this selection if you so wish.


If you follow my lead, take care when choosing a single assembly name.  The Assembly Name can not be the same as the website or any other project in your solution otherwise you’ll receive a circular reference build error.  In other words, I can’t name the assembly MvcApplication293 or my output window would start yelling at me.


Remember when we called out our QA configuration files?  Click on the Deployment tab and you’ll see how where going to use them.  Notice the Web.config file section replacements value.  All this does is swap called out web.config sections with the content of the Config\QA\* files.  You can reduce or extend this list as you deem fit. 


Did you see the “Use external configuration source file” option?  You know how you can point any of your web.config sections to an external file via the configSource attribute?  This option allows you to leverage that technique and instead of replacing the content of the sections, you will replace the configSource attribute value instead.

  1. <appSettings configSource="Config\QA\AppSettings.config" />

Go ahead and Apply your changes.  I’d like to take a look at the project file we just updated.  Right-click on the Web Deployment Project and select “Open Project File.”


One of the first configuration blocks reflects core Release build settings.  There are a couple of points I’d like to call out here:

  • DebugSymbols=false ensures the compilation debug attribute in your web.config is flipped to false as part of build process.  There’s some crumby (more likely old) documentation which implies you need a ToggleDebugCompilation task to make this happen.  Nope. Just make sure the DebugSymbols is set to false. 

  • EnableUpdateable implies a single dll for the web application rather than a dll for each object and and empty view file. I think updatable applications are cleaner and include the benefit (or risk based on your perspective) that portions of the application can be updated directly on the server.  I called this out earlier but I wanted to reiterate.

  1. <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
  2.     <DebugSymbols>false</DebugSymbols>
  3.     <OutputPath>.\Release</OutputPath>
  4.     <EnableUpdateable>true</EnableUpdateable>
  5.     <UseMerge>true</UseMerge>
  6.     <SingleAssemblyName>MvcApplication293</SingleAssemblyName>
  7.     <DeleteAppCodeCompiledFiles>true</DeleteAppCodeCompiledFiles>
  8.     <UseWebConfigReplacement>true</UseWebConfigReplacement>
  9.     <ValidateWebConfigReplacement>true</ValidateWebConfigReplacement>
  10.     <DeleteAppDataFolder>true</DeleteAppDataFolder>
  11.   </PropertyGroup>

The next section is self-explanatory.  The content merely reflects the replacement value you provided via the Property Pages.

  1. <ItemGroup Condition="'$(Configuration)|$(Platform)' == 'Release|AnyCPU'">
  2.     <WebConfigReplacementFiles Include="Config\QA\AppSettings.config">
  3.       <Section>appSettings</Section>
  4.     </WebConfigReplacementFiles>
  5.     <WebConfigReplacementFiles Include="Config\QA\Db.config">
  6.       <Section>connectionStrings</Section>
  7.     </WebConfigReplacementFiles>
  8.     <WebConfigReplacementFiles Include="Config\QA\SmtpSettings.config">
  9.       <Section></Section>
  10.     </WebConfigReplacementFiles>
  11.   </ItemGroup>

You’ll want to extend the ItemGroup section to include the files you wish to exclude from the build.  The sample ExcludeFromBuild nodes exclude all obj, svn, csproj, user, pdb artifacts from the build. Enough though they files aren’t included in your web project, you’ll need to exclude them or they’ll show up along with required deployment artifacts. 

  1. <ItemGroup Condition="'$(Configuration)|$(Platform)' == 'Release|AnyCPU'">
  2.     <WebConfigReplacementFiles Include="Config\QA\AppSettings.config">
  3.       <Section>appSettings</Section>
  4.     </WebConfigReplacementFiles>
  5.     <WebConfigReplacementFiles Include="Config\QA\Db.config">
  6.       <Section>connectionStrings</Section>
  7.     </WebConfigReplacementFiles>
  8.     <WebConfigReplacementFiles Include="Config\QA\SmtpSettings.config">
  9.       <Section></Section>
  10.     </WebConfigReplacementFiles>
  11.     <ExcludeFromBuild Include="$(SourceWebPhysicalPath)\obj\**\*.*" />
  12.     <ExcludeFromBuild Include="$(SourceWebPhysicalPath)\**\.svn\**\*.*" />
  13.     <ExcludeFromBuild Include="$(SourceWebPhysicalPath)\**\.svn\**\*" />
  14.     <ExcludeFromBuild Include="$(SourceWebPhysicalPath)\**\*.csproj" />
  15.     <ExcludeFromBuild Include="$(SourceWebPhysicalPath)\**\*.user" />
  16.     <ExcludeFromBuild Include="$(SourceWebPhysicalPath)\bin\*.pdb" />
  17.     <ExcludeFromBuild Include="$(SourceWebPhysicalPath)\Notes.txt" />
  18.   </ItemGroup>

Pre/post build and Pre/post merge tasks are added to the final code block.  By default, your project file should look like the following – a completely commented out section.

  1. <!– To modify your build process, add your task inside one of
  2.        the targets below and uncomment it. Other similar extension
  3.        points exist, see Microsoft.WebDeployment.targets.
  4.   <Target Name="BeforeBuild">
  5.   </Target>
  6.   <Target Name="BeforeMerge">
  7.   </Target>
  8.   <Target Name="AfterMerge">
  9.   </Target>
  10.   <Target Name="AfterBuild">
  11.   </Target>
  12.   –>

Update the section to remove all temporary Config folders and files after the build. 

  1. <!– To modify your build process, add your task inside one of
  2.        the targets below and uncomment it. Other similar extension
  3.        points exist, see Microsoft.WebDeployment.targets.  
  4.   <Target Name="BeforeMerge">
  5.   </Target>
  6.   <Target Name="AfterMerge">
  7.   </Target>  
  8.   <Target Name="BeforeBuild">   
  9.   </Target>
  10.       –>
  11.   <Target Name="AfterBuild">
  12.     <!– WebConfigReplacement requires the Config files. Remove after build. –>
  13.     <RemoveDir Directories="$(OutputPath)\Config" />
  14.   </Target>

That’s it for setup.  Save the project file, flip the solution to Release Mode and build.  If there’s an issue, consult the Output window for details.  If all went well, you will find your deployment artifacts in your Web Deployment Project folder like so.


Both the code source and published application will be there. Inside the Release folder you will find your “published files” and you’ll notice the Config folder is no where to be found.  In the Source folder, all project files are found with the exception of the items which were excluded from the build.

I’ll wrap up this tutorial by calling out a little Web Deployment pet peeve of mine: there doesn’t appear to be a way to add an existing web deployment project to a solution.  The best I can come up with is create a new web deployment project and then copy and paste the contents of the existing project file into the new project file.  It’s not a big deal but it bugs me.

Getting Started with ASP.NET Membership, Profile and RoleManager

A new ASP.NET MVC project includes preconfigured Membership, Profile and RoleManager providers right out of the box.  Try it yourself – create a ASP.NET MVC application, crack open the web.config file and have a look. 

First, you’ll find the ApplicationServices database connection:

  1. <connectionStrings>
  2.   <add name="ApplicationServices"
  3.        connectionString="data source=.\SQLEXPRESS;Integrated Security=SSPI;AttachDBFilename=|DataDirectory|aspnetdb.mdf;User Instance=true"
  4.        providerName="System.Data.SqlClient"/>
  5. </connectionStrings>


Notice the connection string is referencing the aspnetdb.mdf database hosted by SQL Express and it’s using integrated security so it’ll just work for you without having to call out a specific database login or anything.

Scroll down the file a bit and you’ll find each of the three noted sections:

  1. <membership>
  2.   <providers>
  3.     <clear/>
  4.     <add name="AspNetSqlMembershipProvider"
  5.          type="System.Web.Security.SqlMembershipProvider, System.Web, Version=, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
  6.          connectionStringName="ApplicationServices"
  7.          enablePasswordRetrieval="false"
  8.          enablePasswordReset="true"
  9.          requiresQuestionAndAnswer="false"
  10.          requiresUniqueEmail="false"
  11.          passwordFormat="Hashed"
  12.          maxInvalidPasswordAttempts="5"
  13.          minRequiredPasswordLength="6"
  14.          minRequiredNonalphanumericCharacters="0"
  15.          passwordAttemptWindow="10"
  16.          passwordStrengthRegularExpression=""
  17.          applicationName="/"
  18.             />
  19.   </providers>
  20. </membership>
  22. <profile>
  23.   <providers>
  24.     <clear/>
  25.     <add name="AspNetSqlProfileProvider"
  26.          type="System.Web.Profile.SqlProfileProvider, System.Web, Version=, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
  27.          connectionStringName="ApplicationServices"
  28.          applicationName="/"
  29.             />
  30.   </providers>
  31. </profile>
  33. <roleManager enabled="false">
  34.   <providers>
  35.     <clear />
  36.     <add connectionStringName="ApplicationServices" applicationName="/" name="AspNetSqlRoleProvider" type="System.Web.Security.SqlRoleProvider, System.Web, Version=, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
  37.     <add applicationName="/" name="AspNetWindowsTokenRoleProvider" type="System.Web.Security.WindowsTokenRoleProvider, System.Web, Version=, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
  38.   </providers>
  39. </roleManager>

Really. It’s all there. Still don’t believe me.  Run the application, walk through the registration process and finally login and logout.  Completely functional – and you didn’t have to do a thing!

What else?  Well, you can manage your users via the Configuration Manager which is hiding in Visual Studio behind Projects > ASP.NET Configuration.


The ASP.NET Web Site Administration Tool isn’t MVC-specific (neither is the Membership, Profile or RoleManager stuff) but it’s neat and I hardly ever see anyone using it.  Here you can set up and edit users, roles, and set access permissions for your site. You can manage application settings, establish your SMTP settings, configure debugging and tracing, define default error page and even take your application offline.  The UI is rather plain-Jane but it works great.


And here’s the best of all.  Let’s say you, like most of us, don’t want to run your application on top of the aspnetdb.mdf database.  Let’s suppose you want to use your own database and you’d like to add the membership stuff to it.  Well, that’s easy enough. Take a look inside your [drive:]\%windir%\Microsoft.Net\Framework\v2.0.50727\ folder.  Here you’ll find a bunch of files.  If you were to run the InstallCommon.sql, InstallMembership.sql, InstallRoles.sql and InstallProfile.sql files against the database of your choices, you’d be installing the same membership, profile and role artifacts which are found in the aspnet.db to your own database. 

Too much trouble?  Okay. Run [drive:]\%windir%\Microsoft.Net\Framework\v2.0.50727\aspnet_regsql.exe from the command line instead.  This will launch the ASP.NET SQL Server Setup Wizard which walks you through the installation of those same database objects into the new or existing database of your choice. You may not always have the luxury of using this tool on your destination server, but you should use it whenever you can. 


Last tip: don’t forget to update the ApplicationServices connectionstring to point to your custom database after the setup is complete.

At the risk of sounding like a smarty, everything I’ve mentioned in this post has been around for quite a while. The thing is that not everyone has had the opportunity to use it.  And it makes sense. I know I’ve worked on projects which used custom membership services.  Why bother with the out-of-the-box stuff, right?   And the .NET framework is so massive, who can know it all. Well, eventually you might have a chance to architect your own solution using any implementation you’d like or you will have the time to play around with another aspect of the framework.  When you do, think back to this post.