Archives

Archives / 2006 / April
  • Atlas Control Toolkit Refresh Hopefully Shipping Next Week

    Shawn gave a quick update on the Atlas Control Toolkit, and a potential refresh drop his team is pushing to-do next week.  His team has been doing a great job of answering posts on the Atlas Control Toolkit Forums and in getting feedback and suggestions on improvements.  It sounds like a lot of nice feature additions (including several new cool controls) and bug fixes will be coming next week -- along with expanded Safari browser support.

  • Debugging Unhandled Exceptions in ASP.NET

    Tess really has the best blog I've seen that discusss how to investigate runtime issues with ASP.NET.  She is an escalation engineer at Microsoft whose team is dedicated to helping debug and solve customer problems.  I blogged about some of her great posts back in February here.  If you haven't subscribed to her RSS feed -- you should!

  • Always set the "applicationName" property when configuring ASP.NET 2.0 Membership and other Providers

    I helped out a few folks last night on the ASP.NET Forums with this problem, so I thought it might make sense to turn this into a blog post to help share information about this.

     

    Scenario:

     

    You develop an ASP.NET 2.0 application locally using the new ASP.NET 2.0 Membership, Roles or Profile features.  You create several new users and everything works fine.

     

    You then copy the application to a remote server (or even another directory on your local server) and run the application.  For some reason it appears that you are able to connect to your membership database just fine – but when you try to login it doesn’t let you.  It doesn’t throw a connection error, but rather when you attempt to login you get an error message that says something like: “Login attempt unsuccessful, please try again.”

     

    Cause:

     

    The reason this usually happens is because a membership (or roles or profile) provider has been added in the application’s web.config file – but without an applicationName attribute being specified (assume below that the applicationName in bold was missing):

     

          <membership>

                <providers>

                    <clear/>

                    <add name="AspNetSqlMembershipProvider"

                        type="System.Web.Security.SqlMembershipProvider, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"

                        connectionStringName="LocalSqlServer"

                        enablePasswordRetrieval="false"

                        enablePasswordReset="true"

                        requiresQuestionAndAnswer="true"

      requiresUniqueEmail="false"

                        passwordFormat="Hashed"

                        maxInvalidPasswordAttempts="5"

                        minRequiredPasswordLength="7"

                        minRequiredNonalphanumericCharacters="1"

                        passwordAttemptWindow="10"

                        passwordStrengthRegularExpression=""

                        applicationName="/"

                    />

                </providers>

          </membership>

     

    When no applicationName attribute is configured, ASP.NET uses the application vroot path within the web-server to automatically calculate the applicationName to use when adding data to an ASP.NET Application Service database.  To see this in action, you can open up your ASPNETDB database, and look within the aspnet_Applications table:

     

     

    This table stores a unique ApplicationID for each applicationName.  Because I didn’t specify an “applicationName” attribute when I registered users within my application, it calculated the application name as /website8 (which happened to be the name my dev machine was using at the time).

     

    Users created with the membership API will then be associated with this ApplicationID and in turn the applicationName.  You can see this by opening up the aspnet_Users table:

     

     

    This works fine when the application continues to run in the “/WebSite8” application virtual path.  But if it is copied to another location or server with a different virtual path (for example: “/app1” or more commonly just "/"), then when the Membership APIs are used they will not “see” the users already in our database – since they will lookup membership data using a different application name and filter the users in the application_Users table accordingly.  That is why you’ll get a “Login attempt unsuccessful, please try again.” message when you try to login.

     

    How to Solve This

     

    The easiest way to solve this is to open up the aspnet_Users and aspnet_Applications tables within the ASPNETDB database and figure out what application name was used when creating the users and other data during development (look in the aspnet_Application table to work this out).

     

    You can then go back to your web.config file, and add an “applicationName” attribute to your provider declaration with that application name value.  For example, note how the applicationName value below is now the same as the one in the aspnet_Application table:

     

          <membership>

                <providers>

                    <clear/>

                    <add name="AspNetSqlMembershipProvider"

                        type="System.Web.Security.SqlMembershipProvider, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"

                        connectionStringName="LocalSqlServer"

                        enablePasswordRetrieval="false"

                        enablePasswordReset="true"

                        requiresQuestionAndAnswer="true"

      requiresUniqueEmail="false"

                        passwordFormat="Hashed"

                        maxInvalidPasswordAttempts="5"

                        minRequiredPasswordLength="7"

                        minRequiredNonalphanumericCharacters="1"

                        passwordAttemptWindow="10"

                        passwordStrengthRegularExpression=""

                        applicationName="/website8"

                    />

                </providers>

          </membership>

     

    When the applicationName is set like above, the Membership API will always use that application name when connecting to the ASP.NET application service database.  That means it will work regardless of where the application is deployed or what path is used.

     

    You should also then make sure that you do this for any Roles, Profile, WebPartPersonalization or other providers you configure.

     

    Your application will then work fine.

     

    How to Prevent This in the First Place

     

    The best way to prevent this from ever happening is to always specify the “applicationName” attribute when declaring your providers.  One good default value to use is “/” – which is the root application name.  This is the value specified for the default provider that ships with ASP.NET 2.0 (which by default stores the application service data within the ASPNETDB.MDF file under /app_data), and is why if you don’t override the provider settings it will work if you copy an app to another machine.

     

    For other ASP.NET Security Links and Resources please check out (and bookmark) this large post of content I did.

     

    Hope this helps,

     

    Scott

     

    P.S. In case it isn’t obvious, the reason why the applicationName setting even exists in the first place is so that you can map multiple applications and sites to the same database.

     

    P.P.S. In hindsight, we should have defaulted the provider collection to have a value of "/" for applicationName if it wasn't specified.

  • My Upcoming ASP.NET Presentations in France, Finland, Ireland, Boston, New Zealand, Australia, and Las Vegas

    I’ll be in Europe the next 2 weeks on business, and will be presenting at a number of events if you are interested in dropping by to say hi.  Here are the dates and details of where I am speaking:

    I’m also then speaking the following month at TechEd in Boston (June 11th-16th), and will be making my first ever trip to New Zealand and Australia in August for TechEd New Zealand (August 21st-23rd) and TechEd Australia (August 22nd-25th).

     

    I’ll also then be speaking at the ASP.NET Connections conference November 6th-9th in Las Vegas (we had 3000 people there last fall, and had a great turn out earlier this month at the ASP.NET Connections Orlando event – check out these demos+slides from one of my talks if you missed them).

     

    Hope this helps (and now I have to run and start packing since my flight leaves in a few hours!),

     

    Scott

  • Analyze .NET assemblies using NDepend

    Patrick pointed me at the cool (and free!) NDepend code analyzer that he has built for .NET 2.0.  It analyzes .NET assemblies and generates reports on design quality metrics, along with warnings and diagrams.  Some of the graphical reports in particular are very cool:

  • Cool new IIS7 Features and APIs

    IIS7 is a major upgrade of IIS, and will ship in both Windows Vista as well as Windows Longhorn Server.  It includes a ton of new functionality, including some very rich integration with ASP.NET.  This includes:

  • Atlas Control Toolkit (And Why It is Really Cool)

    Earlier this week we released the April CTP refresh of Atlas (which, like the March CTP drop, supports a go-live license). 

     

    Yesterday we then made available the first download of our new Atlas Control Toolkit, which runs on top of the core Atlas bits and provides a bunch of cool free Atlas-enabled controls that make even more common Ajax scenarios no-brainer easy to implement.  You can run the samples from the Atlas Control Toolkit online here.  You can then download the Atlas Control Toolkit here.

     

    I’m really jazzed about the Atlas Control Toolkit for three reasons:

     

    1) It is the start of what is going to be a very large set of controls that make common Ajax scenarios super easy.  Want to add nested drop-downlists to your page?  Use the new CascadingDropDownList extender.  Want in-line popup support within a page? Use the new PopupControl.  Want to implement smooth show/hide support?  Use the new Collapsable Panel.  Want to add water-marking support to input controls?  Use the new TextBoxWaterMark extender.  All of these controls can be used on a page without having to write any code or custom JavaScript, and have Visual Web Developer and Visual Studio toolbox and WYSIWYG support built-in.

     

    This first release is just the beginning -- our goal is to have the Atlas Control Toolkit contain between 50-100 useful, high-quality Atlas controls over the next few months.  You’ll be able to add the assembly into any project and be able to immediately get great Ajax value out of it with very little effort.

     

    2) It provides an easy developer framework to build Atlas-enabled controls.  Included within the Toolkit are a set of .VSI templates that help get developers started building Atlas controls, as well as a set of base-classes that you can use to easily build your own useful re-usable controls with minimal code required.  The toolkit is designed to help make the overall control developer experience straight-forward – when you create a new control it will provide templates for the client-side Atlas JavaScript component, a server control class that can integrate with it, as well as a class that you can use to provide WYSIWYG designer and rich property grid editor support within VS 2005 and Visual Web Developer. 

     

    Click here to then see a page that has the TextBoxWaterMark control on it in WYSIWYG mode within Visual Web Developer (notice how the extender control points at the TextBox, and is able to add properties in the property grid to the TextBox it is pointing at).

     

    All of the controls in the toolkit are obviously shipped with full source as well, so you can look to see how they are built and re-use techniques/source when building your own controls.

     

    3) We are going to use a collaborative, open-source, model to develop it.  Specifically, we are going to setup a source control repository on the Internet and allow both Microsoft and non-Microsoft developers to work on the project together.  This means you’ll be able to contribute controls of your own to the toolkit, make improvements to existing ones, and fix bugs.  We’ll then publish regular binary drops (with source of course) that any ASP.NET developer will be able to download and use within their sites (if popular your control might even be used billions of times a day). 

     

    We are still finalizing the exact details of the project, and are getting servers built-out now to support it.  We’ll be publishing more details later this month.  This has been something the team and I have wanted to try for awhile, and we really looking forward to getting it going.

     

    To learn more about Atlas, obviously check out the Atlas site.  I also posted some pointers to great Atlas content here a few weeks ago (including a pointer to a sample of how you can use the Atlas Client Libraries with PHP).

     

    Hope this helps,

     

    Scott

     

    P.S. There is also now a dedicated forum for the Atlas Control Toolkit here.

     

    P.P.S. Shawn has a good post walking through how to use the CascadingDropDownList control here.

  • Source Code for the Built-in ASP.NET 2.0 Providers Now Available for Download

    Today we released the source code for the built-in ASP.NET 2.0 Membership, Role Management, Site Navigation, Session State, Profile, Web Events, and Web Part Personalization providers (basically all of the built-in providers that ship in the .NET 2.0 Framework Redist).  You can download them here, and learn more about the ASP.NET 2.0 Provider Model from this site here.

  • Credit Card Payment Processing with ASP.NET

    Rick Strahl has published a excellent (and very comprehensive) new article on techniques to perform credit-card payment processing with ASP.NET.  He also includes full source code examples (for both ASP.NET 1.1 and ASP.NET 2.0). You can check it out here.

  • Don’t run production ASP.NET Applications with debug=”true” enabled

    One of the things you want to avoid when deploying an ASP.NET application into production is to accidentally (or deliberately) leave the <compilation debug=”true”/> switch on within the application’s web.config file.

     

    Doing so causes a number of non-optimal things to happen including:

     

    1) The compilation of ASP.NET pages takes longer (since some batch optimizations are disabled)

    2) Code can execute slower (since some additional debug paths are enabled)

    3) Much more memory is used within the application at runtime

    4) Scripts and images downloaded from the WebResources.axd handler are not cached

     

    This last point is particularly important, since it means that all client-javascript libraries and static images that are deployed via WebResources.axd will be continually downloaded by clients on each page view request and not cached locally within the browser.  This can slow down the user experience quite a bit for things like Atlas, controls like TreeView/Menu/Validators, and any other third-party control or custom code that deploys client resources.  Note that the reason why these resources are not cached when debug is set to true is so that developers don’t have to continually flush their browser cache and restart it every-time they make a change to a resource handler (our assumption is that when you have debug=true set you are in active development on your site).

     

    When <compilation debug=”false”/> is set, the WebResource.axd handler will automatically set a long cache policy on resources retrieved via it – so that the resource is only downloaded once to the client and cached there forever (it will also be cached on any intermediate proxy servers).  If you have Atlas installed for your application, it will also automatically compress the content from the WebResources.axd handler for you when <compilation debug=”false”/> is set – reducing the size of any client-script javascript library or static resource for you (and not requiring you to write any custom code or configure anything within IIS to get it).

     

    What about binaries compiled with debug symbols?

     

    One scenario that several people find very useful is to compile/pre-compile an application or associated class libraries with debug symbols so that more detailed stack trace and line error messages can be retrieved from it when errors occur. 

     

    The good news is that you can do this without having the have the <compilation debug=”true”/> switch enabled in production.  Specifically, you can use either a web deployment project or a web application project to pre-compile the code for your site with debug symbols, and then change the <compilation debug=”true”/> switch to false right before you deploy the application on the server. 

     

    The debug symbols and metadata in the compiled assemblies will increase the memory footprint of the application, but this can sometimes be an ok trade-off for more detailed error messages.

     

    The <deployment retail=”true”/> Switch in Maching.config

     

    If you are a server administrator and want to ensure that no one accidentally deploys an ASP.NET application in production with the <compilation debug=”true”/> switch enabled within the application’s web.config file, one trick you can use with ASP.NET V2.0 is to take advantage of the <deployment> section within your machine.config file.

     

    Specifically, by setting this within your machine.config file:

     

    <configuration>

        <system.web>

              <deployment retail=”true”/>

        </system.web>

    </configuration>

     

    You will disable the <compilation debug=”true”/> switch, disable the ability to output trace output in a page, and turn off the ability to show detailed error messages remotely.  Note that these last two items are security best practices you really want to follow (otherwise hackers can learn a lot more about the internals of your application than you should show them).

     

    Setting this switch to true is probably a best practice that any company with formal production servers should follow to ensure that an application always runs with the best possible performance and no security information leakages.  There isn’t a ton of documentation on this switch – but you can learn a little more about it here.

     

    Hope this helps,

     

    Scott

     

    Updated: Tess has a great follow-up post with more details about what happens when debug="true" is enabled.  You can read it here.

  • App_Offline.htm and working around the "IE Friendly Errors" feature

    I posted the slides+demos from my ASP.NET 2.0 Tips and Tricks talk online last week from the ASP.NET Connections Conference in Orlando.  One of the new features I talked about was the "App_Offline.htm" feature in ASP.NET 2.0, which provides a super convenient way to bring down an ASP.NET application while you make changes to it (for example: updating a lot of content or making big changes to the site where you want to ensure that no users are accessing the application until all changes are done).

  • Atlas Running against PHP

    One of the demos that got people (especially ones not currently using Microsoft technology) excited at the MIX conference a few weeks ago was a demo that Shanku did showing the Atlas Client-Script Libraries working within a PHP web app.  The Atlas architecture easily allows this, and Atlas can be integrated into any existing server framework environment.