|
|
These blog entries are written by industry experts and leaders. We consider this content to be a good read for any software developer or web technologist.
Browse by Tags
All Tags » Tips and Tricks (RSS)
-
Below is a tip/trick I twittered via my Twitter account earlier today. A number of people seemed interested in – so I thought i'd blog it here too. HTML Navigation Bar in VS 2008 By default, when you are in HTML source-editing mode with VS 2008 and Visual Web Developer 2008 Express edition there is a set of drop-downs that are rendered immediately above the HTML text editor view: 
This set of drop-downs is called the "Navigation Bar", and in the VS 2008 HTML editor they allow you to navigate between functions and methods defined within the HTML. These include both JavaScript client-side functions defined inline within the .aspx/.html file, and server-side methods defined in-line within the .aspx file when in single-file mode (meaning no code-behind file). Disabling the HTML Navigation Bar and Getting back some pixels Personally I don't find the HTML navigation bar super useful – since I tend not to define JavaScript functions inline within the HTML (instead I use more unobtrusive JavaScript techniques and put my JavaScript code in separate files), and I usually use code-behind instead of single-file event handlers for server-side code. If you are like me and also don't find yourself using that particular navigation toolbar much, you'll be happy to know that you can turn it off in VS 2008 and get back about 40-50 pixels that can instead be applied toward your HTML source code view. To-do this, just select the Tools->Options menu item within VS, navigate to the "Text Editor->HTML" node and uncheck the "Navigation Bar" checkbox option: 
Once you do this and press the "ok" button, you'll find that the drop-downs are gone and you have more screen real estate: 
(Note: if there is no immediate change after you hit ok, try closing and then re-opening the HTML/ASP.NET file) Hope this helps, Scott P.S. By default with VS 2010 (starting with Beta2) we are hiding the navigation bar when in HTML mode with the standard web profile – you can then turn it back on via Tools->Options if you find it useful. VS 2010 also has a new optional "code optimized" web profile as well that turns off all toolbars, dropdown and HTML designers. 
|
-
One of the fundamental design goals of Silverlight and WPF is to enable developers to be able to easily encapsulate UI functionality into re-usable controls. You can implement new custom controls by deriving a class from one of the existing Control classes (either a Control base class or from a control like TextBox, Button, etc). Alternatively you can create re-usable User Controls - which make it easy to use a XAML markup file to compose a control's UI (and which makes them super easy to build). In Part 6 of my Digg.com tutorial blog series I showed how to create a new user control using VS 2008's "Add New Item" project item dialog and by then defining UI within it. This approach works great when you know up front that you want to encapsulate UI in a user control. You can also use the same technique with Expression Blend. Taking Existing UI and Encapsulating it as a User Control Sometimes you don't always know you want to encapsulate some UI functionality as a re-usable user control until after you've already started defining it on a parent page or control. For example, we might be working on a form where we want to enable a user to enter shipping and billing information. We might begin by creating some UI to encapsulate the address information. To-do this we could add a <border> control to the page, nest a grid layout panel inside it (with 2 columns and 4 rows), and then place labels and textbox controls within it: 
After carefully laying it all out, we might realize "hey - we are going to use the exact same UI for the billing address as well, maybe we should create a re-usable address user control so that we can avoid repeating ourselves". We could use the "add new item" project template approach to create a blank new user control and then copy/paste the above UI contents into it. An even faster trick that we can use within Blend, though, is to just select the controls we want to encapsulate as a user control in the designer, and then "right click" and choose the "Make Control" menu option: 
When we select the "Make Control" menu item, Blend will prompt us for the name of a new user control to create: 
We'll name it "AddressUserControl" and hit ok. This will cause Blend to create a new user control that contains the content we selected: 
When we do a re-build of the project and go back to the original page, we'll see the same UI as before - except that the address UI is now encapsulated inside the AddressUserControl: 
We could name this first AddressUserControl "ShippingAddress" and then add a second instance of the user control to the page to record the billing address (we'll name this second control instance "BillingAddress"): 
And now if we want to change the look of our addresses, we can do it in a single place and have it apply for both the shipping and billing information. Data Binding Address Objects to our AddressUserControl Now that we have some user controls that encapsulate our Address UI, let's create an Address data model class that we can use to bind them against. We'll define the class like below (taking advantage of the new automatic properties language feature): 
Within the code-behind file of our Page.xaml file we can then instantiate two instances of our Address object - one for the shipping address and one for the billing address (for the purposes of this sample we'll populate them with dummy data). We'll then programmatically bind the Address objects to our AddressUserControls on the page. We'll do that by setting the "DataContext" property on each user control to the appropriate shipping or billing address data model instance: 
Our last step will be to declaratively add {Binding} statements within our AddressUserControl.xaml file that will setup two-way databinding relationships between the "Text" properties of the TextBox controls within the user control and the properties on the Address data model object that we attached to the user control: 
When we press F5 to run the application we'll now get automatic data-binding of the Address data model objects with our AddressUserControls: 
Because we setup the {Binding} declarations to be "Mode=TwoWay", changes users make in the textboxes will automatically get pushed back to the Address data model objects (no code required for this to happen). For example, we could change our original shipping address in the browser to instead go to Disneyland: 
If we wire-up a debugger breakpoint on the "Click" event handler of the "Save" button (and then click the button), we can see how the above TextBox changes are automatically reflected in our "_shippingAddress" data model object: 
We could then implement the SaveBtn_Click event handler to persist the Shipping and Billing Address data model objects however we want - without ever having to manually retrieve or manipulate anything in the UI controls on the page. This clean view/model separation that WPF and Silverlight supports makes it easy to later change the UI of the address user controls without having to update any of our code in the page. It also makes it possible to more easily unit test the functionality (read my last post to learn more about Silverlight Unit Testing). Summary WPF and Silverlight make it easy to encapsulate UI functionality within controls, and the user control mechanism they support provides a really easy way to take advantage of this. Combining user controls with binding enables some nice view/model separation scenarios that allow you to write very clean code when working with data. You can download a completed version of the above sample here if you want to run it on your own machine. To learn even more about Silverlight and WPF, check out my Silverlight Tutorials and Links Page. I also highly recommend Karen Corby's excellent MIX08 talk (which covers User Controls, Custom Controls, Styling, Control Templates and more), which you can watch online for free here. Hope this helps, Scott 
|
-
People often ask me at conferences for PC hardware recommendations. Specifically - "what type of machine do you recommend I get for doing development with Visual Studio?" and/or "your laptop seems really fast, what type is it?" Some of my recommendations on this topic are fairly standard and obvious: Ideally you want to get a duel core or better CPU. I also always recommend getting at least 2GB or more of RAM. The recommendation I make that often seems to take people a little by surprise is to make sure you always get the fastest possible hard-drive when buying a new machine - and where necessary trade off purchasing additional CPU processor speed in favor of investing in a faster disk instead. Why does hard drive speed matter? Multi-core CPUs on machines have gotten fast enough over the past few years that in most common application scenarios you don't usually end up blocking on available processor capacity in your machine. What you are much more likely to block on is the Seek and I/O speed capacity with which your computer accesses your hard drive. If you are using an application that needs to read/write a lot of files, it is not atypical for your CPU processor utilization to be really low - since the application might be spending most of its time just waiting for the disk operations to complete. When you are doing development with Visual Studio you end up reading/writing a lot of files, and spend a large amount of time doing disk I/O activity. Large projects and solutions might have hundreds (or thousands) of source files (including images, css, pages, user controls, etc). When you open a project Visual Studio needs to read and parse all source files in it so as to provide intellisense. When you are enlisted in source control and check out a file you are updating files and timestamps on disk. When you do a compilation of a solution, Visual Studio will check for updated assemblies from multiple disk path locations, write out multiple new assemblies to disk when the compilation is done, as well as persist .pdb debugger symbol files on disk with them (all as separate file save operations). When you attach a debugger to a process (the default behavior when you press F5 to run an application), Visual Studio then needs to search and load the debugger symbols of all assemblies and DLLs for the application so as to setup breakpoints. If you have a slow hard-drive, Visual Studio will end up being blocked as it waits for it to complete these read/write operations - which can really slow down your overall development experience. Some laptop hard drive recommendations The default hard drive speed for most PC laptops is typically 5400rpm - which is a pretty slow drive. If you are getting a new laptop and plan to use Visual Studio on it, I highly recommend making sure you get a 7200rpm drive instead. You will realize a significant performance benefit by doing this. You might assume if you are buying a top of the line laptop that "of course" it won't have a slow drive. Don't assume this! Check out the default configuration of this high-end Thinkpad (which is the brand I use), or the default configuration of the high-end Dell XPS laptop (whose list price starts at $3,343), or the default configuration of the 17" Apple MacBook Pro laptop ($2,799). Notice that by default all three of these premium laptop lines have 5400rpm drives. For an additional $55 (Lenovo), $93 (Dell) or $200 (Apple) you can upgrade the hard drive to be a 7200rpm disk instead. Putting this small amount of extra money in the faster disk can really make a big performance difference and is an absolutely worthwhile investment. Some desktop machine hard drive recommendations Two hard drive performance considerations to consider with desktop configurations: 1) Consider getting a 10,000rpm hard drive. These are lightening fast and can make a big difference over the default 7,200rpm drives that typically come with desktops (Jeff Atwood has a good blog post recommending one of these). 2) Consider buying a second physical hard drive and setup your operating system and OS virtual memory swap file to use one of the physical drives, and then store all your data (images, documents and Visual Studio projects) on the second physical drive. The benefit of an approach like this is that your read/write data operations won't be competing for disk I/O activity with the operating system updating the virtual memory file. Other Visual Studio Performance Recommendations While on the topic of improving Visual Studio performance, you might want to also check out the blog posts and articles below for some good recommendations: One other performance gotcha I've heard about recently is an issue that a few people have reported running into with the Google Toolbar add-in. For some reason this can sometimes cause long delays when attaching the Visual Studio debugger to the browser. If you are seeing long delays with your web application loading, and have the Google Toolbar (or other toolbars) installed, you might want to try uninstalling them to see if that is the cause of the issue. Hope this helps, Scott P.S. For more of my tip/trick posts, please check out my ASP.NET Tips, Tricks and Tutorials page. 
|
-
Earlier this year I blogged about a new language extensibility feature of C# and VB called "Extension Methods". Extension methods allow developers to add new methods to the public contract of an existing CLR type, without having to sub-class it or recompile the original type. In doing so they enable a variety of useful scenarios (including LINQ). They also provide a really convenient way to add a dash of "syntactic sugar" into your code. Over the last few months I've been making a list of cool extension methods that I plan to sit down and implement when I get some free time (not sure when that is... but at least I can still have fun coming up with the ideas!) Two of the scenarios I added to my extension method list were easy methods to automate generating JSON (JavaScript Object Notation) or XML serialization strings for any .NET object. Simple Scenario: The ToJSON() extension method Assume I had a Person object defined like below (note: I'm using the new automatic properties feature to implement it): 
I'd like to then be able to initialize a collection of Person objects and programmatically retrieve a JSON string representation of them by just calling a ToJSON() extension method on it like below: 
This would work just like the built-in ToString() method on the Object class in .NET today - except that it would generate a JSON-format representation of the collection that I could use for AJAX scenarios on the client: 
Note: Clicking on the hour-glass in the debugger above allows us to bring up the Text Visualizer in VS to see a clean version of the JSON serialization: 
This string format could then be used within JavaScript on the client to instantiate an appropriate JavaScript object that represents my collection (note: ASP.NET AJAX has a built-in JavaScript library to support this). Implementing the ToJSON Extension Method Implementing a basic ToJSON() extension method is pretty simple. All I needed to-do was use the JavaScriptSerializer class in the System.Web.Script.Serialization namespace, and define two extension methods like below. One of the methods serializes an object graph any levels deep, the other is an overloaded version that allows you to optionally constrain how deep it recurses (for example: ToJSON(2) would serialize only 2 levels deep in the object graph). 
Note that the ToJSON() extension methods above are defined for type "Object" - which means they can be used with all objects in .NET (not just collections). This means that in addition to calling .ToJSON() on collections like I did above, I could also have called ToJSON() on individual Person objects, as well as any other .NET datatype. To use the extension method, all I need to-do is add a using statement at the top of my program that references the namespace it was defined within: 
VS 2008 then takes care of providing intellisense and compile time support for it to all objects: 
Note: In addition to the JavaScriptSerializer class, .NET 3.5 also now includes a new System.Runtime.Serialization.DataContractJsonSerializer class that you can use for JSON serialization/deserialization. Summary Hopefully the above sample provides a simple example of how you can easily encapsulate useful functionality into extension methods. Overtime I expect that we'll start to see some nice utility libraries come out that provide helpful extension methods like above. I'd be curious to see suggestions for other common scenarios you think should be packaged up into re-usable extension methods (feel free to use the comments of this post to suggest them). We can then figure out how to get a good CodePlex project created that bundles up some of them together into one library to easily use. Hope this helps, Scott P.S. Please check out my Tips/Tricks and Tutorials page to find other useful ASP.NET and .NET posts I've done. 
|
-
One of the questions I get asked fairly regularly is: "how can I can easily change different configuration settings in my web.config file based on whether my application is in a dev, qa, staging or production mode?" The most common scenario for this is one where an application uses different database connection-strings for testing and production purposes. It turns out you can easily automate this configuration process within the Visual Studio build environment (and do so in a way that works both within the IDE, as well as with command-line/automated builds). Below are the high-level steps you take to do this. They work with both VS 2005 and VS 2008. - Use ASP.NET Web Application Projects (which have MSBuild based project files)
- Open the VS Configuration Manager and create new "Dev", "QA", "Staging" build configurations for your project and solution
- Add new "web.config.dev", "web.config.qa", and "web.config.staging" files in your project and customize them to contain the app's mode specific configuration settings
- Add a new "pre-build event" command to your project file that can automatically copy over the web.config file in your project with the appropriate mode specific version each time you build the project (for example: if your solution was in the "Dev" configuration, it would copy the web.config.dev settings to the main web.config file).
Once you follow these steps, you can then just pick the mode your solution is in using the configuration drop-down in the VS standard toolbar: 
The next time you build/run after changing the configuration mode, VS will automatically modify your application's web.config file to pick up and use the web.config settings specific to that build configuration (so if you select QA it will use the QA settings, if you select Deploy it will use the Deploy settings). The benefit with this approach is that it works well in a source control environment (everyone can sync and build locally without having to make any manual changes on their local machines). It also works on a build server - including with scenarios where you are doing automated command-line solution builds. To learn more about the exact steps to set this up, please read the Managing Multiple Configuration File Environments with Pre-Build Events post that Scott Hanselman published earlier tonight. Also check out my ASP.NET Tips, Tricks, and Gotchas page for other ASP.NET Tips/Tricks recommendations. Hope this helps, Scott 
|
-
Over the last year we've seen several people report having performance problems when using F5 to run/debug ASP.NET 2.0 applications using Visual Studio 2005. The problem in theses cases typically wasn't with building the project, but rather that it sometimes took the debugger a really long time to hit the first breakpoint once it attached to the application (45+ seconds and longer sometimes). We recently posted a public hotfix patch that you can download and apply to fix this issue. You can download the hotfix immediately here. You can read more about it in this KB article here. Background on the Issue The particular bug fixed in this hotfix was surprisingly difficult to track down. The slowdown issue occurred when breakpoints were set in multiple source files in the same project that had the same short file names (for example: two default.aspx.cs files) and which were organized in a certain directory structure pattern on disk. The patch fixes this issue and should prevent the debugger from pausing when trying to load the web project's assembly symbols in this case. For Technical Support with this Patch If you have any problems installing the patch or find that you still see issues after you install it, you'll want to contact Microsoft product support for assistance and they'll help debug it further. Calls to Microsoft Product Support are free if they are related to a product bug (either a QFE HotFix request or a product bug you are running into). You can find details on how to contact Microsoft product support on this page (it allows you to lookup the local phone number to use by country). Other Hotfix Patches I've posted in the past about other ASP.NET and VS related hotfix patches that can be publicly downloaded. Here are a few pointers to these posts: More Performance and Tip/Tricks/Tutorial Posts Make sure to check out my Tip/Trick: Optimizing ASP.NET 2.0 Web Project Build Performance with VS 2005 post if you have build performance issues with VS 2005. Please visit and bookmark my ASP.NET 2.0 Tips, Tricks, Recipes, and Gotchas page for a good listing of some of my previous ASP.NET and Visual Studio posts and tutorials. Hope this helps, Scott 
|
-
I've fallen behind on my weekly link-listing series - apologies for the delay. ASP.NET -
.NET DateTime and Number Format String Cheat Sheet: If you are like me, you might have trouble remembering all of the standard format strings you can pass to the String.Format() method and/or the Eval() databinding method in ASP.NET to generate the appropriate string output from a DateTime or Numeric datatype. This PDF cheatsheet is a useful one to download and save to quickly look these format strings up. John has some other really useful .NET PDF cheatsheets he has also created that you might like to download here. -
ASP.NET Photo Handler: Bertrand has posted a cool photo album HttpHandler for ASP.NET that allows you to easily drop images into a web directory and automatically generate a nice photo album of them (complete with EXIF information, stack sorting icons, etc). Might be very useful for people enjoying holidays this summer. Download the code here. - BlogEngine.NET: This is a new open source blog engine for ASP.NET that Mads Kristensen has helped start up, and which I've heard a lot of good things about. You can read about its features here, and download it here.
ASP.NET AJAX Visual Studio -
GhostDoc 2.1.1 Released: GhostDoc is a free add-in for Visual Studio 2005 (and now 2008) that automatically generates default XML documentation comments for code you write in C# or VB. It can automatically re-use existing documentation inherited from base classes or implemented interfaces, or generate initial documentation by deducing comments from the name and type of the member signature. You can learn more about it and download it for free here. Silverlight - Silverlight Tutorials: Michael Schwarz has a great blog where he writes regularly about Silverlight. This tutorials link points to a bunch of great Silverlight content.
IIS 7 -
IIS 7.0 is now running all of Microsoft.com: One of the things we push at Microsoft is to "dogfood" our products on our high volume sites when they enter the beta cycle. As of a few weeks ago, all of the web servers running www.microsoft.com are now running on IIS7 and Windows 2008 Server Beta3. These servers host 500+ virtual roots and 350 ASP.NET applications, and handle 300,000 concurrent connections. IIS7 is going to be an awesome release. -
IIS 7.0 on Server Core: Bill Staples blogs about some of the new IIS7 enhancements that appear with the June CTP of Windows 2008 Server. One of the big features that is now supported is the ability to install IIS7 on "server core" - which is a low footprint installation of Windows 2008 Server that lays down just the minimal footprint needed to boot (meaning no GUI shell). This lowers the resources required on servers, and even more importantly means that servers don't need to be updated if a patch is released for a component not installed on the server (which lowers the downtime of servers). ASP.NET and the .NET Framework aren't supported yet in server core configurations - but will be in the future. Hope this helps, Scott P.S. I'm out on vacation this week, so please excuse delays on email and comment feedback. 
|
-
Scenario You have built an ASP.NET Web Application using Visual Studio 2005, and want to enable customers to automatically install and deploy it on servers via an easy setup program. Specifically, you want to create a standard Windows setup program that will create and configure the application on IIS, copy all of the application’s files to the appropriate location on the server, and ensure that ASP.NET 2.0 is correctly mapped to run the application. You also want the setup program to prompt the customer for the database location that the new application should use, and have the setup program automatically update the web.config file with the database connectionstring settings the customer provided. One solution to consider using is the built-in "Web Setup Project" support that is built-in to Visual Studio 2005. Web Setup Projects can be used to pipe the compilation outputs from VS 2005 Web Application Projects as well as Web Site Projects (when used with VS 2005 Web Deployment Projects), to create encapsulated Windows setup programs. The below walkthrough demonstrates step-by-step how to create and use one. 1) Create a VS 2005 Web Application Project To begin with, we’ll start with an empty instance of Visual Studio and create a new VS 2005 Web Application project (select File->New Project->ASP.NET Web Application). For the purposes of this simple sample we’ll have two pages in the project: 
We’ll add a label to the Default.aspx page and a Page_Load event handler in the code-behind to output the current timestamp on each request. When I press F5 to build and run the application, the project will compile and run as I’d expect (and by default use the built-in VS Web Server): 
2) Add a VS 2005 Web Setup Project to the Solution Now that we have a simple ASP.NET application built, we’ll want to add a VS 2005 Web Setup Project to the solution. Choose the File->Add->New Project menu item to add one into your solution: 
Note that the “Web Setup Project” type shows up under the “Other Project Types->Setup and Deployment” node in the New Project dialog above. Name it whatever you want and hit ok. It will then show up in your solution explorer as a separate project. Our next step will be to configure the web setup project to take the compiled assemblies (\bin directory contents) + content markup (.aspx, .config, etc files) from our Web Application Project and use them as inputs within our setup project. To-do this, right-click on the web setup project node in the solution explorer and choose the “Add->Project Output” context menu item: 
A dialog will then appear allowing us to select which project in the solution, and which of its project contents, we want to add to the setup package: 
For ASP.NET Web Application Projects it is really important that we select both the “Primary Output” (which are the compiled assemblies for the \bin directory) as well as the “Content Files” (which are the .aspx markup files) within this dialog. By default, the web setup project will copy both of these items into the root of the target Web Application Folder that the setup project will create. You can see that it is configured this way by opening up the “File System” view within the web setup project (right click on the web setup project root and choose View->File System): 
This actually isn’t what we want to have happen though – since we really want the assemblies (indicated by the Primary Output node) to be copied into the application’s \bin directory instead (otherwise ASP.NET won’t be able to find them at runtime). To fix this, drag/drop the “Primary Output from MyApplication” node into the \bin directory. Once this is done you should be able to click on the “Web Application Folder” node on the left-hand side and see this: 
And then click on the “bin” folder sub-node and see this: 
We now have a basic web setup project created and configured for our ASP.NET Web Application. Next step is to build and run it. 3) Build and Run the VS 2005 Web Setup Project to the Solution To build the web-setup project we can right-click on the web setup project node within the solution explorer and choose the “Build” option: 
If you open the output window within VS (View->Output menu item), you will see the results of this build operation: 
Our “MyApplicationSetup” project created a new MyApplicationSetup.msi Windows installer file and compressed and packaged the contents of our ASP.NET Web Application (note: in the web setup project properties dialog you can choose whether the compression algorithm used is optimized for size or speed). Very Important: Because setup projects take awhile to build, they are by default marked not to build as part of the solution. What this means is that you need to right-click on them and explicitly do a build in order for them to be recompiled. Be careful to-do this when you make and test changes - otherwise you'll be running the previously compiled version and not the one with your latest code! To test it, we can right-click on the web setup project within the solution explorer and choose the “Install” option to install it (or alternatively launch it outside of VS by running it): 
This will launch a standard Windows installer and walk the user through installing the application on IIS: 
VS 2005’s web setup projects allow you to pick which site to install the application on if multiple sites are configured on IIS (this wasn’t supported with the VS 2003 version). You can optionally specify an application virtual-directory path to use (for example: http://www.myserver.com/myapppath), or you can leave this value blank to install it as the root application on the site (for example: http://www.myserver.com/). Once the installer completes, the application will have been copied to disk and registered with IIS. We can now run the application using the HTTP path we provided during installation like so: 
Once installed the application will also show up in the standard “Add or Remove Programs” utility within the Windows Control Panel: 
You can remove the application either by running uninstall from the control panel utility, or (at development time) by right-clicking on the web setup project node within the VS Solution Explorer and selecting the “Uninstall” menu item. This will cause all installed files to be removed from disk. 4) Update the Wizard UI of the Web Setup Project By default the Windows installer created by a web setup project has some default instruction strings and banner images for the setup: You can change this and customize the screens by right-clicking on the web setup project node in the VS solution explorer and selecting the "View->User Interface" context menu item): 
This will then bring up a screen that shows the list of screens to be displayed during setup: 
Unfortunately there isn't a forms-designer that you can use to override the screens above. However, you can select a screen, and then go to the property grid to customize its text and change the graphics used within the screen: 
You can also create new screens and add them into the setup wizard. Later in this tutorial we'll use this feature to create a custom screen to collect database connection-string information and use it to automate configuring our web.config file to point at the appropriate database. 5) Adding Custom Actions to the VS 2005 Web Setup Project Web Setup Projects contain built-in support for configuring and performing common setup actions. These include editors for adding/changing registry entries (choose View->Register to configure), changing file-type associations (View->File Types), and for validating prerequisite components are already installed (it automatically checks that the .NET Framework 2.0 redist is installed). Setup Projects also allow you to configure a number of common IIS settings declaratively (click on the “Web Application Folder” in the File System view and then look at the property grid to see these): 
But for non-trivial setups you are likely to want to be able to execute your own custom code during setup to customize things. The good news is that web setup projects support this with something called “Custom Actions” – which is code you write that can execute during both install and uninstall operations. To add a custom action you first want to add a new class library project to your solution (File->Add->New Project->Class Library). You then want to add assembly references in this newly created Class Library to the System.Configuration.Install.dll, System.Configuration.dll, System.Diagnostics.dll, and System.Web.dll assemblies. You’ll then want to create a new class for your custom action and have it derive from the “System.Configuration.Install.Installer” base class like so: using System;
using System.Configuration.Install;
using System.ComponentModel;
namespace MyCustomAction
{
[RunInstaller(true)]
public class ScottSetupAction : Installer
{
public override void Install(System.Collections.IDictionary stateSaver)
{
base.Install(stateSaver);
// Todo: Write Your Custom Install Logic Here
}
}
} Notice the custom “RunInstaller(true)” attribute that must be set on the class name. This is important and required (and easy to forget!). You’ll need to add a using statement to the System.ComponentModel namespace to avoid fully qualifying this. Next we’ll need to make sure this Custom Action assembly gets added to our web setup project. To-do this, right-click on the Web Setup Project root node in the solution explorer and select the View->File System menu item to bring up the file-system editor. Right-click on the “bin” sub-folder and choose “Add->Project Output” like we did earlier to get the custom action assembly added to the web setup project: 
In this case we’ll want to select the Custom Action Class Library project instead of our web application one. Pick it from the project drop-down at the top of the dialog and then select the “Primary Output” option as the piece we want to add to the web-setup project (this will cause the Custom Action assembly to get added): 
Lastly, we’ll configure the web-setup project to call our custom action assembly during the install phase of setup. To do this we’ll right-click on the web setup project root node in the solution explorer and choose the “View->Custom Actions” menu item. This will then bring up the Custom Actions Editor. Right-click on the “Install” node and choose “Add Custom Action”: 
Drill into the Web Application Folder and Bin directory and choose the output from our Custom Action we imported: 
The Setup Project will then automatically detect the custom action because of the “RunInstaller” attribute: 
Our custom action class and Install method will now run anytime we run the installation setup program. 6) Useful Custom Action Example: ASP.NET Script Mapping Checker The previous section showed how to create and configure an empty custom action class and install method. Let’s now do something useful with it. Specifically, let’s add code to verify that the right version of ASP.NET is correctly mapped for the application we are creating. Because ASP.NET V1.1 and V2.0 can run side-by-side with each other on the same machine, it is possible to have different parts of a web server configured to run using different versions of ASP.NET. By default, the versions inherit hierarchically – meaning if the root application on a site is configured to still run using ASP.NET V1.1, a newly created application underneath the site root will by default run using V1.1 as well. What we’ll do in the steps below is write some code to ensure that our new application always runs using ASP.NET 2.0. To begin with, we’ll select our custom action within the Custom Action explorer (just like in the previous screenshot above - using the View->Custom Action context menu item). We’ll then go to the property grid and specify a few parameters to pass to our custom action to use: 
Specifically, we’ll pass in the target directory that the application is being installed in, the IIS site map path, and the IIS virtual directory name that the user specified in the setup wizard. This string of values looks like this: /targetdir="[TARGETDIR]\" /targetvdir="[TARGETVDIR]" /targetsite="[TARGETSITE]" We’ll then update our custom action to access these values and do something with them like so: using System;
using System.Configuration;
using System.Configuration.Install;
using System.ComponentModel;
using System.Diagnostics;
using System.IO;
namespace MyCustomAction
{
[RunInstaller(true)]
public class ScottSetupAction : Installer
{
public override void Install(System.Collections.IDictionary stateSaver)
{
base.Install(stateSaver);
// Retrieve configuration settings
string targetSite = Context.Parameters["targetsite"];
string targetVDir = Context.Parameters["targetvdir"];
string targetDirectory = Context.Parameters["targetdir"];
if (targetSite == null)
throw new InstallException("IIS Site Name Not Specified!");
if (targetSite.StartsWith("/LM/"))
targetSite = targetSite.Substring(4);
RegisterScriptMaps(targetSite, targetVDir);
}
void RegisterScriptMaps(string targetSite, string targetVDir)
{
// Calculate Windows path
string sysRoot = System.Environment.GetEnvironmentVariable("SystemRoot");
// Launch aspnet_regiis.exe utility to configure mappings
ProcessStartInfo info = new ProcessStartInfo();
info.FileName = Path.Combine(sysRoot, @"Microsoft.NET\Framework\v2.0.50727\aspnet_regiis.exe");
info.Arguments = string.Format("-s {0}/ROOT/{1}", targetSite, targetVDir);
info.CreateNoWindow = true;
info.UseShellExecute = false;
Process.Start(info);
}
}
} The above code launches the aspnet_regiis.exe utility that ships with ASP.NET within the \Windows\Microsoft.net\framework\v2.0.5.0727\ directory, and passes in the path location information for the site that the web setup installer previously created, along with the “-s” flag – which indicates that the IIS script-maps for that application should be updated to specifically use the ASP.NET 2.0 version, and not inherit the version number from any parent applications. A special thanks to John for figuring this out in his blog post here. Note: If you are using IIS6 or IIS7, you'll probably want to also add some logic into the custom action to ensure that the application pool that the application is being hosted in is also mapped to use ASP.NET 2.0. Either that or you'll want to tell the admin to manually check the application pool settings after the setup is complete. 7) Useful Custom Action Example: Configuring Database Connection String For our next custom action example, let’s add some UI to the setup that allows a user to configure the connection string details of a database the application should use. Right click on the web setup project and open up the user interface screens again: Right click on the "Install" node on the user interface screens page and chose to add a new dialog to the install wizard: 
Chose one of the TextBox screens to use for gathering connection string details from the user: 
Right-click on the TextBox screen node and move it up to be earlier in the wizard (right after we pick the IIS site and application name to use): 
Then click on the TextBox screen and access its property window. Via the property window you can change the text displayed on the screen, as well as control how many textboxes are visible: 
Note in the above property window how I've set the Edit2, Edit3 and Edit4 text boxes to not be visible. Now when we build and run the setup package we'll see this dialog in our wizard steps: 
Now that we have UI to capture the connection-string value entered by a user in the wizard, we want to make sure it is passed to our custom action class. You can do this by right-clicking on the web setup project node and by then choosing the "View->Custom Actions" context menu and then opening the property page window of our custom action: 
We'll want to update the CustomActionData property value and pass in the connection-string of the database to use (we'll pass in the value from the EDITA1 textbox in the user interface screen): /targetdir="[TARGETDIR]\" /db="[EDITA1]" /targetvdir="[TARGETVDIR]" /targetsite="[TARGETSITE]" We can then update our custom action class to retrieve and use this connectionstring value to update the web.config file of the new application to contain the value the user installing the application entered. Below is a method that opens the web.config file for our new application and programmatically updates it with the user entered connection string: void ConfigureDatabase(string targetSite, string targetVDir, string connectionString)
{
// Retrieve "Friendly Site Name" from IIS for TargetSite
DirectoryEntry entry = new DirectoryEntry("IIS://LocalHost/" + targetSite);
string friendlySiteName = entry.Properties["ServerComment"].Value.ToString();
// Open Application's Web.Config
Configuration config = WebConfigurationManager.OpenWebConfiguration("/" + targetVDir, friendlySiteName);
// Add new connection string setting for web.config
ConnectionStringSettings appDatabase = new ConnectionStringSettings();
appDatabase.Name = DATABASE_CONNECTION_KEY;
appDatabase.ConnectionString = connectionString;
config.ConnectionStrings.ConnectionStrings.Clear();
config.ConnectionStrings.ConnectionStrings.Add(appDatabase);
// Persist web.config settings
config.Save();
} And now after we run the setup program our newly installed ASP.NET application's web.config file will have been updated to point to the right database. To learn more about how the ASP.NET configuration APIs can be used to make changes to web.config files, please check out the management API section in the ASP.NET 2.0 Quickstart tutorials. Chris Crowe also has some useful samples that demonstrate how to use the System.DirectoryServices APIs to query IIS settings (I needed them to figure out how to lookup the "friendly name" of the site from IIS to open up the web.config file). You might also want to check out this MSDN documentation sample that demonstrates how to programmatically create a new database (complete with schema and data) with a custom action. You could combine the approach in the MSDN article with the configuration one I used above to completely automate database deployment as part of your setup. Summary Hopefully the above tutorial helps demonstrate how to get started with using the built-in web setup project support within Visual Studio. Click here to download a complete version of the sample I built above. Web setup projects aren't perfect for all scenarios, and I'd primarily recommend them only for cases where you want a packaged GUI setup program (for example: to give to an external customer or to make available as a download on a web-site). If you are instead working on maintaining/managing a site that you have direct access to, I'd probably instead recommend using the "Publish Application" feature available with VS 2005 Web Application Projects (for simple updates), or recommend authoring a PowerShell script to automate updates to the remote server. For an example of a really advanced Powershell script that www.pageflakes.com uses to update their site, check out Omar's article here. One downside with the VS 2005 Web Setup Project support is that you can only build web setup projects from within the IDE - which means you can't completely automate the creation of .MSIs as part of an automated MSBuild process. If this is a showstopper for you, you should consider looking at the WIX setup framework - which does support this scenario. You can find a good set of WIX Tutorials here. If someone wants to publish a blog post that demonstrates how to perform the scenarios I outlined in the blog post above using WIX, let me know and I will definitely link to it (and send you a few .NET books to say thanks!). Hope this helps, Scott P.S. Please check out my ASP.NET Tips, Tricks and Tutorials page for more cool ASP.NET samples and tips/tricks. 
|
-
One of the nice features that Silverlight supports is the ability to go "full screen" and effectively take over the entire screen of a computer (hiding everything else from sight - including the browser frame). This can be very useful when building immersive UI experiences, games, rich video players, etc. For a nice example of this feature in action, make sure to check out the Fox Movies Sample on www.silverlight.net: 
Once the page loads and the movie starts playing, double-click on the video surface in the middle to switch into full-screen mode (note: the screen-shot above is not in full-screen but rather browser mode). You can then hit the escape key to switch back into normal browser viewing. How to Implement Full Screen Mode with Silverlight 1.1 using .NET One of the questions I've seen a few people ask is "how can you implement full screen-mode when building Silverlight applications using .NET?" The good news is that the answer is actually pretty easy: 1) First add an input driven event handler to your application (for example: a mouse down or keyboard event handler). For security reasons Silverlight doesn't allow developers to switch an application into full-screen mode on first application load (you don't want an application to spoof you). So you'll instead need to trigger full-screen mode in response to a user action. 2) Within your input event handler set the BrowserHost.IsFullScreen property to true (note: the BrowserHost class lives within the System.Windows.Interop namespace). This will cause Silverlight to switch into full screen mode. Setting this property to false will return it back to normal browser mode. Simple Full Screen Mode Sample You can download a simple Silverlight full screen-mode sample I put together written in C# here. When you run the sample it will load a super simple Silverlight application within the browser and display a text message prompting you to click it to switch into full-screen mode: 
If you click the "Click for Full Screen" text, the application will switch into full-screen mode - which will hide everything else running on the system and take over the entire screen: 
When you switch into full-screen mode, Silverlight will display a user message blurb that will pop-up on the screen for a few seconds and instruct the user that they can press the escape key to switch back into browser mode. After a few seconds this message will disappear and only your content will be visible. In my sample above I also allow the user to click on the "Click to Return to Browser" text and switch back into browser mode as well. Walkthrough the Simple Full Screen Mode Code The code to implement the above sample is pretty simple. To begin with we can open and edit the root .XAML file for the application, and add a UI element to it that we want to use to trigger the full-screen mode. In the sample above I used a <TextBlock> control that I named "MyMessage". Below is all of the XAML for the entire application: 
The below screen-shot shows the code-behind for the .XAML file above - and contains all of the code for the entire application: 
Within the application's Page_Loaded() event handler above I am wiring up two event handlers: MyMessage_MouseLeftButtonDown - This event handler will execute anytime a user clicks on the TextBlock message control I added into my XAML file. Within this event handler I'm simply toggling the BrowserHost.IsFullScreen property to true or false depending on whether or not it is already in full screen mode. BrowserHost_FullScreenChange - This event handler will execute anytime Silverlight switches between full screen and browser mode. It provides a good place to add logic to update the UI when this happens. In the example above I am changing the text on the TextBlock control. I could also have optionally resized controls and/or moved them around the screen to new coordinate positions. Currently the Silverlight 1.1 Alpha doesn't have layout manager support, so controls won't automatically re-position unless you write code to manage this yourself (don't worry - layout manager controls for Silverlight like in the desktop WPF version are coming). In addition to the IsFullScreen property, BrowserHost class has a number of additional properties and events that are very useful: 
The ActualHeight and ActualWidth properties are particularly useful to lookup the screen dimensions when you switch into full-screen mode - which you can then use when positioning and scaling your UI controls on the page. Summary Supporting full-screen mode within Silverlight applications is pretty easy to enable, and offers the ability to provide a nice, immersive user experience. To learn more about Silverlight, please read my comprehensive Silverlight announcement post as well as visit the www.silverlight.net community site. To watch me walkthrough building a Silverlight application from scratch using .NET and Visual Studio "Orcas", please watch this video here. Hope this helps, Scott 
|
-
SSL enables browsers to communicate with a web-server over a secure channel that prevents eavesdropping, tampering and message forgery. You should always use SSL for login pages where users are entering usernames/passwords, as well as for all other sensitive pages on sites (for example: account pages that show financial or personal information). Configuring SSL on Windows with previous versions of IIS has been a pain. Figuring out how to install and manage a certificate, and then associate it with a web-site, is something I bet most web developers don't know how to enable. The good news is that IIS 7.0 makes it radically easier to configure and enable SSL. IIS 7.0 also now has built-in support for creating "Self Signed Certificates" that enable you to easily create test/personal certificates that you can use to quickly SSL enable a site for development or test purposes. Using IIS 7.0 you can SSL enable an existing web site in under 30 seconds. The below tutorial demonstrates how to-do this. Step 1: Create a New Web Site We'll start by creating a new web-site using the new IIS 7.0 admin tool. This admin tool is a complete re-write of the previous IIS admin tool (and was written entirely in managed code using Windows Forms), and provides a more logical organization of web features. It provides a GUI admin experience for all ASP.NET and IIS settings:  To create a new site on the box, right click on the "Web Sites" node in the left hand tree-view pane and choose the "Add Web Site" context menu option. Enter the appropriate details to create a new web-site: 
One nice feature of IIS7 on Windows Vista is that you can now have an unlimited number of sites on a box (previous versions of IIS on Windows Client only allowed 1 site). The 10 simultaneous request limitation on Windows Client versions of IIS also no longer exists with IIS 7.0. Once we've completed the above steps, we will now have a brand new site running on our IIS web-server. Step 2: Create a new Self Signed Certificate Before binding SSL rules to our new site, we need to first import and setup a security certificate to use with the SSL binding. Certificates are managed in IIS 7.0 by clicking the root machine node in the left-hand tree-view explorer, and then selecting the "Server Certificates" icon in the feature pane on the right: 
This will then list all certificates registered on the machine, and allow you to optionally import and/or create new ones. I could optionally go to a certificate authority like Verisign and purchase a certificate to import using this admin UI. Alternatively, I can create a "self-signed certificate" which is a test certificate that I can use during the development and testing of my site. To-do this, click the "Create Self-Signed Certificate" link on the right-hand side of the admin tool: 
Enter a name to use for the certificate (for example: "test") and hit ok. IIS7 will then automatically create a new self-signed crypto certificate for you and register it on the machine: 
Step 3: Enable HTTPS Bindings for our New Site To SSL enable the web-site we created earlier, select the web-site node in the left-hand tree-view, and the click the "Bindings" link in its "actions" pane on the right-hand side of the screen: 
This will then bring up a dialog that lists all of the binding rules that direct traffic to this site (meaning the host-header/IP address/port combinations for the site): 
To enable SSL for the site, we'll want to click the "Add" button. This will bring up an "add binding" dialog that we can use to add HTTPS protocol support. We can select the self-signed certificate we created earlier from the SSL certificate dropdownlist in the dialog, and in doing so indicate that we want to use that certificate when encrypting content over SSL: 
Click ok, and we now have SSL enabled for our site: 
Step 4: Test out the Site Add a "default.aspx" page to the site, and then try and hit it with the browser by typing https://localhost/default.aspx (note the usage of "https" instead of "http" to indicate that you want to connect over SSL). If you are using IE7, you'll likely see this anti-phishing error message kick in 
Don't panic if this happens - it is just IE being helpful by suggesting that a self-signed certificate on your local machine looks suspicious. Click the "Continue to this website" link to bypass this security warning and proceed to the site. You'll find that your default.aspx page is now running protected via SSL: 
You are all done. :-) Appendix: A Few Last SSL Notes A few last SSL related notes: - The IIS 7.0 admin tool has an "SSL Settings" node that you can select for each site, directory or file that allows you to control whether that particular resource (and by default its children) requires an SSL request in order to execute. This is useful for pages like a login.aspx page, where you want to guarantee that users can only enter their credentials when they are posting via an encrypted channel. If you configure the login.aspx page to require SSL, IIS 7.0 will block browsers from accessing it unless they are doing so over SSL.
- Within an ASP.NET page or handler, you can programmatically check whether the current request is using SSL by checking the Request.IsSecure property (it will return "true" if the incoming browser request is over SSL).
- You can set the "requireSSL" attribute on the <forms> configuration section within web.config files to have ASP.NET's forms-authentication system ensure that forms-authentication cookies are only set and used on SSL enabled pages and URLs. This avoids the risk of a hacker trying to intercept the authentication cookie on a non-SSL secured page, and then trying to use a "replay attack" from a different machine to impersonate a user.
For more information on IIS 7.0, please read my earlier IIS 7.0 overview blog post. Also make sure to check out the www.iis.net website. To read more of my "Tips and Tricks" blog posts, please visit my Tips and Tricks Summary Page. Hope this helps, Scott 
|
-
One of the questions I am often asked is "How can I integrate ASP.NET security with Classic ASP other non-ASP.NET URLs?". Specifically, people want to know if they can integrate ASP.NET's Forms Authentication, Role Based Security, and URL Authorization features with Classic ASP, PHP, JSP, .HTM, .JPG and other non-ASP.NET URLs. The good news is that this is pretty easy with ASP.NET 2.0 and IIS 6.0 today, and will get even easier in the IIS 7.0 timeframe. The below blog post demonstrates how to integrate ASP.NET 2.0's Forms Authentication and Login/Membership features with classic ASP and static .HTML files. For a much more detailed walkthrough of how to achieve this (as well as how to integrate features like ASP.NET role based authorization with classic ASP applications), please read Chapter 6 of Stefan Schackow's excellent ASP.NET 2.0 Security, Membership, and Role Management book. Some Background on IIS 6.0 Wildcard Mappings IIS 6.0 with Windows Server 2003 added support for an ISAPI feature called "wildcard mappings". Wildcard mappings provide a way to configure IIS to cause all requests coming into the server to first be routed to one or more ISAPI extensions for processing. What is cool about wildcard mappings in IIS 6.0 is that after the ISAPI extension that is processing the wildcard extension is finished, it can then cause IIS to pass control of the request to the extension or internal handler within IIS that normally would process the request. ASP.NET 2.0 includes built-in support to take advantage of this wildcard mapping feature. This enables you to run ASP.NET code (or your own custom code) before and after the existing ISAPI extension that processes a non-ASP.NET URL (for example: a .asp, .php or .htm request) executes. We can use this feature to enable a bunch of cool integration features - including using ASP.NET authentication and authorization features to secure all URLs on a web-server. How to Configure an IIS 6.0 Wildcard Mapping For this sample I've created a new IIS application within the IIS 6.0 admin tool called "wildcardtest". It points to a directory that will contain a few files: "default.aspx", "login.aspx", "test.asp" and "test.htm" (these last two files being resources not usually handled by ASP.NET): 
By default when a URL request for a .aspx page comes to the application, the ASP.NET ISAPI will process the request. By default when a URL request for test.asp comes to the application, the classic ASP ISAPI will process the request - and no ASP.NET code will run. When a URL request for test.htm comes to the application, IIS6 will process the request internally - and again no ASP.NET code will ever run. We'll change this by enabling wildcard mappings for this application, and configure ASP.NET to run code before and after all requests to the server. To-do this, right-click on the application within the IIS Admin Tool and select the "properties" context menu item on it. This will bring up the application properties dialog: 
You can then click the "configuration" button to pull up the URL mapping rules for the application: 
Note how the top of this dialog lists the default ISAPI extension mappings (each URL extension is mapped to an ISAPI responsible for processing it). The bottom half of the dialog lists the "wildcard application map" rules. We can add a application wildcard mapping to the ASP.NET ISAPI by clicking the "insert" button, and pointing at the ASP.NET 2.0 ISAPI extension on disk: 
Very, Very Important: Make sure that you uncheck the "Verify this file exists" checkbox. If you don't do this ASP.NET URL resources like WebResource.axd and other URL's handled by ASP.NET that aren't backed by a physical file won't work anymore. This will lead to errors within your pages. Now close out all of the dialogs by clicking "ok" to accept the changes. You've now configured ASP.NET to be able to run code before and after each URL request into the application. Enabling Forms Authentication and Url Authorization for non-ASP.NET resources Once we've completed the above steps to register ASP.NET 2.0 as a wild-card mapping for all URLs into our IIS application, we can then use the standard ASP.NET authentication and authorization techniques to identify users in our application and grant/deny them access to it. For example, we could add a web.config file to our application that enables ASP.NET's forms authentication feature for this application, and sets up two URL Authorization rules that deny "anonymous" users access to both the test.asp and test.htm URLs: <?xml version="1.0"?>
<configuration>
<system.web>
<authentication mode="Forms" />
</system.web>
<location path="test.asp">
<system.web>
<authorization>
<deny users="?"/>
<allow users="*"/>
</authorization>
</system.web>
</location>
<location path="test.htm">
<system.web>
<authorization>
<deny users="?"/>
<allow users="*"/>
</authorization>
</system.web>
</location>
</configuration> Now, when I attempt to access either "test.asp" or "test.htm", the ASP.NET authentication and authorization system will execute first to check whether I'm logged into the application with forms-authentication, and if not redirect me to the login.aspx page within my application for me to login: 
Note how the "ReturnUrl" used by ASP.NET's forms authentication system above has automatically set the "test.asp" url to redirect back to once I'm logged in (this works just like it would for a .aspx page). Once I successfully enter a username/password, I'll then have access to the test.asp page: 
Since the above page is a classic ASP file, I obviously don't have a "User.Identity.Name" property that I can use to identify the logged in user like I would in an ASP.NET page. However, I can retrieve the "AUTH_USER" ServerVariable value within classic ASP to obtain the username (ASP.NET automatically populates this before delegating the processing back to the classic ASP ISAPI). The code to use this from within classic ASP would look like below: <html>
<body>
<h1>Classic ASP Page</h1>
<h3>
You are logged in as:
<u>
<%=Request.ServerVariables("AUTH_USER") %>
</u>
</h3>
</body>
</html> Click here to download a complete sample application that implements the above solution. By default it will use a SQL Express database to store ASP.NET 2.0's Membership and Role Management data. Alternatively, you can create and register a SQL 2000 or SQL 2005 database to store the membership and role management values. This older ASP.NET Security tutorial I did shows how to-do this. How to Learn More about ASP.NET Security I highly recommend buying a copy of Stefan Schackow's excellent ASP.NET 2.0 Security, Membership, and Role Management book. Stefan is a key member of the ASP.NET team, and owned and designed the security features in the ASP.NET 2.0 release. As such, he really, really, really knows what he is writing about. Chapter 6 of his book is titled "Integrating ASP.NET Security with Classic ASP" and contains much more detail about the solution I demonstrated above (as well as how to use role security with it, and pass data back and forth between ASP.NET and classic ASP). 
Click here to learn more about the book and/or buy it online. Other Online ASP.NET Security Resources I've published a number of ASP.NET Tips, Tricks, Recipes and Tutorials in the past that cover ASP.NET 2.0 security. Below is a short-list of them that you might want to review: For more free ASP.NET Tips, Tricks, and Tutorials I've written, please check out my ASP.NET Tips, Tricks and Tutorials listing. Hope this helps, Scott 
|
-
People often ask me for guidance on how they can dynamically "re-write" URLs and/or have the ability to publish cleaner URL end-points within their ASP.NET web applications. This blog post summarizes a few approaches you can take to cleanly map or rewrite URLs with ASP.NET, and have the option to structure the URLs of your application however you want. Why does URL mapping and rewriting matter? The most common scenarios where developers want greater flexibility with URLs are: 1) Handling cases where you want to restructure the pages within your web application, and you want to ensure that people who have bookmarked old URLs don't break when you move pages around. Url-rewriting enables you to transparently forward requests to the new page location without breaking browsers. 2) Improving the search relevancy of pages on your site with search engines like Google, Yahoo and Live. Specifically, URL Rewriting can often make it easier to embed common keywords into the URLs of the pages on your sites, which can often increase the chance of someone clicking your link. Moving from using querystring arguments to instead use fully qualified URL's can also in some cases increase your priority in search engine results. Using techniques that force referring links to use the same case and URL entrypoint (for example: weblogs.asp.net/scottgu instead of weblogs.asp.net/scottgu/default.aspx) can also avoid diluting your pagerank across multiple URLs, and increase your search results. In a world where search engines increasingly drive traffic to sites, extracting any little improvement in your page ranking can yield very good ROI to your business. Increasingly this is driving developers to use URL-Rewriting and other SEO (search engine optimization) techniques to optimize sites (note that SEO is a fast moving space, and the recommendations for increasing your search relevancy evolve monthly). For a list of some good search engine optimization suggestions, I'd recommend reading the SSW Rules to Better Google Rankings, as well as MarketPosition's article on how URLs can affect top search engine ranking. Sample URL Rewriting Scenario For the purpose of this blog post, I'm going to assume we are building a set of e-commerce catalog pages within an application, and that the products are organized by categories (for example: books, videos, CDs, DVDs, etc). Let's assume that we initially have a page called "Products.aspx" that takes a category name as a querystring argument, and filters the products accordingly. The corresponding URLs to this Products.aspx page look like this: http://www.store.com/products.aspx?category=books
http://www.store.com/products.aspx?category=DVDs
http://www.store.com/products.aspx?category=CDs Rather than use a querystring to expose each category, we want to modify the application so that each product category looks like a unique URL to a search engine, and has the category keyword embedded in the actual URL (and not as a querystring argument). We'll spend the rest of this blog post going over 4 different approaches that we could take to achieve this. Approach 1: Use Request.PathInfo Parameters Instead of QueryStrings The first approach I'm going to demonstrate doesn't use Url-Rewriting at all, and instead uses a little-known feature of ASP.NET - the Request.PathInfo property. To help explain the usefulness of this property, consider the below URL scenario for our e-commerce store: http://www.store.com/products.aspx/Books
http://www.store.com/products.aspx/DVDs
http://www.store.com/products.aspx/CDs One thing you'll notice with the above URLs is that they no longer have Querystring values - instead the category parameter value is appended on to the URL as a trailing /param value after the Products.aspx page handler name. An automated search engine crawler will then interpret these URLs as three different URLs, and not as one URL with three different input values (search engines ignore the filename extension and just treat it as another character within the URL). You might wonder how you handle this appended parameter scenario within ASP.NET. The good news is that it is pretty simple. Simply use the Request.PathInfo property, which will return the content immediately following the products.aspx portion of the URL. So for the above URLs, Request.PathInfo would return "/Books", "/DVDs", and "/CDs" (in case you are wondering, the Request.Path property would return "/products.aspx"). You could then easily write a function to retrieve the category like so (the below function strips out the leading slash and returning just "Books", "DVDs" or "CDs"): Function GetCategory() As String
If (Request.PathInfo.Length = 0) Then
Return ""
Else
Return Request.PathInfo.Substring(1)
End If
End Function Sample Download: A sample application that I've built that shows using this technique can be downloaded here. What is nice about this sample and technique is that no server configuration changes are required in order to deploy an ASP.NET application using this approach. It will also work fine in a shared hosting environment. Approach 2: Using an HttpModule to Perform URL Rewriting An alternative approach to the above Request.PathInfo technique would be to take advantage of the HttpContext.RewritePath() method that ASP.NET provides. This method allows a developer to dynamically rewrite the processing path of an incoming URL, and for ASP.NET to then continue executing the request using the newly re-written path. For example, we could choose to expose the following URLs to the public: http://www.store.com/products/Books.aspx
http://www.store.com/products/DVDs.aspx
http://www.store.com/products/CDs.aspx This looks to the outside world like there are three separate pages on the site (and will look great to a search crawler). By using the HttpContext.RewritePath() method we can dynamically re-write the incoming URLs when they first reach the server to instead call a single Products.aspx page that takes the category name as a Querystring or PathInfo parameter instead. For example, we could use an an Application_BeginRequest event in Global.asax like so to do this: void Application_BeginRequest(object sender, EventArgs e) {
string fullOrigionalpath = Request.Url.ToString();
if (fullOrigionalpath.Contains("/Products/Books.aspx")) {
Context.RewritePath("/Products.aspx?Category=Books");
}
else if (fullOrigionalpath.Contains("/Products/DVDs.aspx")) {
Context.RewritePath("/Products.aspx?Category=DVDs");
}
} The downside of manually writing code like above is that it can be tedious and error prone. Rather than do it yourself, I'd recommend using one of the already built HttpModules available on the web for free to perform this work for you. Here a few free ones that you can download and use today: These modules allow you to declaratively express matching rules within your application's web.config file. For example, to use the UrlRewriter.Net module within your application's web.config file to map the above URLs to a single Products.aspx page, we could simply add this web.config file to our application (no code is required): <?xml version="1.0"?>
<configuration>
<configSections>
<section name="rewriter"
requirePermission="false"
type="Intelligencia.UrlRewriter.Configuration.RewriterConfigurationSectionHandler, Intelligencia.UrlRewriter" />
</configSections>
<system.web>
<httpModules>
<add name="UrlRewriter" type="Intelligencia.UrlRewriter.RewriterHttpModule, Intelligencia.UrlRewriter"/>
</httpModules>
</system.web>
<rewriter>
<rewrite url="~/products/books.aspx" to="~/products.aspx?category=books" />
<rewrite url="~/products/CDs.aspx" to="~/products.aspx?category=CDs" />
<rewrite url="~/products/DVDs.aspx" to="~/products.aspx?category=DVDs" />
</rewriter>
</configuration> The HttpModule URL rewriters above also add support for regular expression and URL pattern matching (to avoid you having to hard-code every URL in your web.config file). So instead of hard-coding the category list, you could re-write the rules like below to dynamically pull the category from the URL for any "/products/[category].aspx" combination: <rewriter>
<rewrite url="~/products/(.+).aspx" to="~/products.aspx?category=$1" />
</rewriter>
This makes your code much cleaner and super extensible. Sample Download: A sample application that I've built that shows using this technique with the UrlRewriter.Net module can be downloaded here. What is nice about this sample and technique is that no server configuration changes are required in order to deploy an ASP.NET application using this approach. It will also work fine in a medium trust shared hosting environment (just ftp/xcopy to the remote server and you are good to go - no installation required). Approach 3: Using an HttpModule to Perform Extension-Less URL Rewriting with IIS7 The above HttpModule approach works great for scenarios where the URL you are re-writing has a .aspx extension, or another file extension that is configured to be processed by ASP.NET. When you do this no custom server configuration is required - you can just copy your web application up to a remote server and it will work fine. There are times, though, when you want the URL to re-write to either have a non-ASP.NET file extension (for example: .jpg, .gif, or .htm) or no file-extension at all. For example, we might want to expose these URLs as our public catalog pages (note they have no .aspx extension): http://www.store.com/products/Books
http://www.store.com/products/DVDs
http://www.store.com/products/CDs With IIS5 and IIS6, processing the above URLs using ASP.NET is not super easy. IIS 5/6 makes it hard to perform URL rewriting on these types of URLs within ISAPI Extensions (which is how ASP.NET is implemented). Instead you need to perform the rewriting earlier in the IIS request pipeline using an ISAPI Filter. I'll show how to-do this on IIS5/6 in the Approach 4 section below. The good news, though, is that IIS 7.0 makes handling these types of scenarios super easy. You can now have an HttpModule execute anywhere within the IIS request pipeline - which means you can use the URLRewriter module above to process and rewrite extension-less URLs (or even URLs with a .asp, .php, or .jsp extension). Below is how you would configure this with IIS7: <?xml version="1.0" encoding="UTF-8"?>
<configuration>
<configSections>
<section name="rewriter"
requirePermission="false"
type="Intelligencia.UrlRewriter.Configuration.RewriterConfigurationSectionHandler, Intelligencia.UrlRewriter" />
</configSections>
<system.web>
<httpModules>
<add name="UrlRewriter" type="Intelligencia.UrlRewriter.RewriterHttpModule, Intelligencia.UrlRewriter" />
</httpModules>
</system.web>
<system.webServer>
<modules runAllManagedModulesForAllRequests="true">
<add name="UrlRewriter" type="Intelligencia.UrlRewriter.RewriterHttpModule" />
</modules>
<validation validateIntegratedModeConfiguration="false" />
</system.webServer>
<rewriter>
<rewrite url="~/products/(.+)" to="~/products.aspx?category=$1" />
</rewriter>
</configuration> Note the "runAllManagedModulesForAllRequests" attribute that is set to true on the <modules> section within <system.webServer>. This will ensure that the UrlRewriter.Net module from Intelligencia, which was written before IIS7 shipped, will be called and have a chance to re-write all URL requests to the server (including for folders). What is really cool about the above web.config file is that: 1) It will work on any IIS 7.0 machine. You don't need an administrator to enable anything on the remote host. It will also work in medium trust shared hosting scenarios. 2) Because I've configured the UrlRewriter in both the <httpModules> and IIS7 <modules> section, I can use the same URL Rewriting rules for both the built-in VS web-server (aka Cassini) as well as on IIS7. Both fully support extension-less URLRewriting. This makes testing and development really easy. IIS 7.0 server will ship later this year as part of Windows Longhorn Server, and will support a go-live license with the Beta3 release in a few weeks. Because of all the new hosting features that have been added to IIS7, we expect hosters to start aggressively offering IIS7 accounts relatively quickly - which means you should be able to start to take advantage of the above extension-less rewriting support soon. We'll also be shipping a Microsoft supported URL-Rewriting module in the IIS7 RTM timeframe that will be available for free as well that you'll be able to use on IIS7, and which will provide nice support for advanced re-writing scenarios for all content on your web-server. Sample Download: A sample application that I've built that shows using this extension-less URL technique with IIS7 and the UrlRewriter.Net module can be downloaded here. Approach 4: ISAPIRewrite to enable Extension-less URL Rewriting for IIS5 and IIS6 If you don't want to wait for IIS 7.0 in order to take advantage of extension-less URL Rewriting, then your best best is to use an ISAPI Filter in order to re-write URLs. There are two ISAPI Filter solutions that I'm aware of that you might want to check-out: - Helicon Tech's ISAPI Rewrite: They provide an ISAPI Rewrite full product version for $99 (with 30 day free trial), as well as a ISAPI Rewrite lite edition that is free.
- Ionic's ISAPI Rewrite: This is a free download (both source and binary available)
I actually don't have any first-hand experience using either of the above solutions - although I've heard good things about them. Scott Hanselman and Jeff Atwood recently both wrote up great blog posts about their experiences using them, and also provided some samples of how to configure the rules for them. The rules for Helicon Tech's ISAPI Rewrite use the same syntax as Apache's mod_rewrite. For example (taken from Jeff's blog post): [ISAPI_Rewrite] # fix missing slash on folders # note, this assumes we have no folders with periods! RewriteCond Host: (.*) RewriteRule ([^.?]+[^.?/]) http\://$1$2/ [RP] # remove index pages from URLs RewriteRule (.*)/default.htm$ $1/ [I,RP] RewriteRule (.*)/default.aspx$ $1/ [I,RP] RewriteRule (.*)/index.htm$ $1/ [I,RP] RewriteRule (.*)/index.html$ $1/ [I,RP] # force proper www. prefix on all requests RewriteCond %HTTP_HOST ^test\.com  RewriteRule ^/(.*) http://www.test.com/$1 [RP] # only allow whitelisted referers to hotlink images RewriteCond Referer: (?!http://(?:www\.good\.com|www\.better\.com)).+ RewriteRule .*\.(?:gif|jpg|jpeg|png) /images/block.jpg [I,O] Definitely check out Scott's post and Jeff's post to learn more about these ISAPI modules, and what you can do with them. Note: One downside to using an ISAPI filter is that shared hosting environments typically won't allow you to install this component, and so you'll need either a virtual dedicated hosting server or a dedicated hosting server to use them. But, if you do have a hosting plan that allows you to install the ISAPI, it will provide maximum flexibility on IIS5/6 - and tide you over until IIS7 ships. Handling ASP.NET PostBacks with URL Rewriting One gotcha that people often run into when using ASP.NET and Url-Rewriting has to-do with handling postback scenarios. Specifically, when you place a <form runat="server"> control on a page, ASP.NET will automatically by default output the "action" attribute of the markup to point back to the page it is on. The problem when using URL-Rewriting is that the URL that the <form> control renders is not the original URL of the request (for example: /products/books), but rather the re-written one (for example: /products.aspx?category=books). This means that when you do a postback to the server, the URL will not be your nice clean one. With ASP.NET 1.0 and 1.1, people often resorted to sub-classing the <form> control and created their own control that correctly output the action to use. While this works, it ends up being a little messy - since it means you have to update all of your pages to use this alternate form control, and it can sometimes have problems with the Visual Studio WYSIWYG designer. The good news is that with ASP.NET 2.0, there is a cleaner trick that you can use to rewrite the "action" attribute on the <form> control. Specifically, you can take advantage of the new ASP.NET 2.0 Control Adapter extensibility architecture to customize the rendering of the <form> control, and override its "action" attribute value with a value you provide. This doesn't require you to change any code in your .aspx pages. Instead, just add a .browser file to your /app_browsers folder that registers a Control Adapter class to use to output the new "action" attribute: 
You can see a sample implementation I created that shows how to implement a Form Control Adapter that works with URLRewriting in my sample here. It works for both the Request.PathInfo and UrlRewriter.Net module approaches I used in Approach 1 and 2 above, and uses the Request.RawUrl property to retrieve the original, un-rewritten, URL to render. With the ISAPIRewrite filter in Approach 4 you can retrieve the Request.ServerVariables["HTTP_X_REWRITE_URL"] value that the ISAPI filter uses to save the original URL instead. My FormRewriter class implementation above should work for both standard ASP.NET and ASP.NET AJAX 1.0 pages (let me know if you run into any issues). Handling CSS and Image Reference Correctly One gotcha that people sometime run into when using Url Rewriting for the very first time is that they find that their image and CSS stylesheet references sometimes seem to stop working. This is because they have relative references to these files within their HTML pages - and when you start to re-write URLs within an application you need to be aware that the browser will often be requesting files in different logical hierarchy levels than what is really stored on the server. For example, if our /products.aspx page above had a relative reference to "logo.jpg" in the .aspx page, but was requested via the /products/books.aspx url, then the browser will send a request for /products/logo.jpg instead of /logo.jpg when it renders the page. To reference this file correctly, make sure you root qualify CSS and Image references ("/style.css" instead of "style.css"). For ASP.NET controls, you can also use the ~ syntax to reference files from the root of the application (for example: <asp:image imageurl="~/images/logo.jpg" runat="server"/> Hope this helps, Scott P.S. For more ASP.NET 2.0 Tips and Tricks, please check out my ASP.NET 2.0 Tips, Tricks and Tutorials Page. P.P.S. Special thanks to Scott Hanselman and Michael K. Campbell for testing my Form Control Adapter with their sites. 
|
-
I've finished my whirlwind speaking tour of Europe (Belgium, UK and Netherlands in less than one week), and was fortunate to have had the chance to present to several hundred people along the way. Many thanks to everyone who came out to attend my talks! Here are the first two slide decks + samples from the talks I gave: ASP.NET Tips and Tricks: This talk covered ASP.NET UI, AJAX, Caching and Deployment Tips and Tricks, and Visual Studio 2005 tips/tricks. The samples include updated versions of ASP.NET AJAX that all work with ASP.NET AJAX 1.0. You can download the slides+samples here. You can learn more about the Visual Studio build performance optimization suggestions by reading this past post of mine on improving build performance. You can also find several dozen more ASP.NET and Visual Studio Tips/Tricks of mine on my Tips and Tricks summary page. Building an End-to-end Web Application from scratch using ASP.NET 2.0, ASP.NET AJAX, IIS7 and Visual Studio: This talk walked through building a rich data-driven application from scratch using ASP.NET 2.0, ASP.NET AJAX 1.0, IIS7 and Visual Studio (all of which are now officially shipping products). You can download the deck + completed sample here. This talk demonstrates the following features: IIS7 distributed configuration, Master Pages, Building a DAL using DataSets, Building Data Driven Edit Pages, Building Catalogue Browsing Pages, Site Navigation, Url Rewriting, Site Navigation, CSS Control Adapters, ASP.NET AJAX, ASP.NET AJAX Control Toolkit, Membership/Roles, IIS7 Admin UI, SQL Cache Invalidation, and WebPart portal support. Hope this helps, Scott P.S. I'll be posting more slides+samples from my other talks in the days ahead (including my Orcas and WPF/E talks). 
|
-
-
Last month I posted about the new (free) Database Publishing Wizard that is designed to make it much, much easier to upload and deploy SQL Express and SQL Server databases in a web hoster environment. In my first Database Publishing post, I walked through how you can use the Database Publishing Wizard to automatically generate a .SQL installation file that contains the script necessary to recreate your database schema (tables, views, sprocs, triggers, full-text catalogs, etc) and also populate your database with the same table row contents as your original database. This provides a super easy way to put together a .SQL script that entirely automates replicating your database on another server:  In my previous post I mentioned how hosters often provide an online SQL management tool that you can then use to open and run your newly generate .SQL file, or provide a SQL query tool that allows you to copy/paste the .SQL file's contents into a query execution window to run. Unfortunately, though, not all hosters support tools like this. And even with hosters that do support it you might run into cases where your generated .SQL file is so big that copying/pasting it into a text box isn't really viable (doing a form post of 200MB of content will typically time out!). This blog post walks through an alternative way to deploy your .SQL files in a remote hosting environment, and which does not require your hoster to configure or install anything on the backend. Steps to Deploy a SQL Database to a Remote SQL Server without using an Admin Tool Below are the steps to take to deploy a local database to a remote hoster without requiring or using any admin tool: Step 1: Generate a .SQL File Containing your Schema and Data The first step to remotely deploy your database in a hosted environment is to generate a .SQL file that dumps the schema and content of your database. Follow the steps in my first Database Publishing blog post to learn exactly how to generate a .SQL file for either a SQL Express or SQL Server database. Step 2: FTP up the .SQL File to your Remote Hoster Once you've generated your .SQL file, upload it to your remote hoster using FTP or some other file transfer mechanism. Ideally you should copy this into a protected location where remote users can't easily get access to it (one suggestion: give it a random name and upload it into the /app_data folder which is typically protected by default). The benefit of uploading this file over FTP is that it won't force you to limit the size of the .SQL file. It can be 100s of megabytes in size if necessary. Step 3: Download the RunSQL.aspx Utility Page Visit this page and download the RunSQL.aspx file linked on it. The RunSQL.aspx file is an ASP.NET page that the SQL Server team put together that supports two arguments: 1) The name of a .SQL file, and 2) The connection string of a database. When run the RunSQL.aspx page will open the .SQL file and iterate over each of its statements and execute them against the database (indicated via the connection string). This will provision the database defined within the .SQL file to the remote database target. Step 4: Edit the RunSQL.aspx Utility Page Open and locally edit the RunSQL.aspx file and and configure the name of your .SQL file, as well as provide the connection-string your hoster gave you for the SQL database: 
Replace the <<YOUR_SCRIPTFILE>> marker and associated connection-string markers with the correct values for your hosted configuration. Note that unless you know the fully qualified path of the .SQL file, you'll probably want to use ASP.NET's Server.MapPath(fileName) method to calculate the absolute path of the relative .SQL file path in your web application. For example: // Filename of the T-SQL file you want to run
string fileName = Server.MapPath("personal.SQL");
// Connection string to the server you want to execute against
string connectionString = @"Server=server123;User ID=user123;Password=password123;Initial Catalog=MyDBName123";
// Timeout of batches (in seconds)
int timeout = 600; Step 5: Upload the RunSQL.aspx Utility Page to Your Remote Hoster Once you have finished updating the fileName and connectionString values above, upload the RunSQL.aspx file to your remote hoster (for example: using FTP). For security reasons I recommend giving the file a random file-name when you upload it so that other users can't easily find and run it. Step 6: Hit the RunSQL.aspx Utility Page with a Browser Once uploaded, hit the remote RunSQL.aspx page via your browser. This will cause the page on your remote server to parse the .SQL file, and execute all of its statements. Since the .SQL file contains all of the database schema creation and population statements necessary to recreate your database, once the page finishes running you'll have an identical database deployed at your hoster: 
Step 7: Delete the RunSQL.aspx and .SQL Files Once you've finished running your .SQL script, delete both the RunSQL.aspx page and the .SQL file from your remote hoster server. For security reasons you do not want anyone else to be able to remotely hit the RunSQL.aspx page (since it might recreate your database causing you to lose data). Step 9: Update the Web.Config file of your application to point to the hoster database The only final step remaining then is to update your web.config file's <connectionStrings> section to also point at your remote hoster's database connectionstring value. Once you do this your app should work fine remotely. Hope this helps, Scott P.S. For more of my ASP.NET Tips, Tricks and Recipes, please visit this page. 
|
|
|
|