| ASP.NET Web Sites Development |
| The topics cover information that pertains to the application or site as a whole, such as the file structure of an ASP.NET Web site, the lifecycle of an application, ways to create a consistent look (themes) and a consistent layout (master pages) for all of the pages in the site, and how to extend the application with custom modules . The following sections of this topic describe the ASP.NET Web development model that includes the services necessary |
|
| Please fill up the form below and we will submit a proposal for your project. Alternatively, you can send
email to contact@optionm.net with the project
requirements. |
|
|
|
|
|
 |
| Planning an ASP.NET Web Site |
|
|
Before you create a Web site, it is always helpful to plan the site before you begin creating pages and writing code. Planning the site in advance can make it easier to create the overall look of the site and of site navigation.
The size of a Web site can often determine the amount of planning you must do. A small, brochure-type Web site that just provides static information can be a relatively basic site that requires little planning. A Web site that accesses a data store, authenticates users, and that has localization and accessibility constraints can require more planning. Having a plan will save you time in the development and maintenance of the site.
The following topics cover information that pertains to the Web site as a whole, which includes information on the following: |
|
| The type of Web site that you select. |
| How you navigate through the site. |
| Ways to create a consistent look and layout for all the pages in the site. |
| How to access data from a data store. |
|
| Deciding on a Web Site Project Type |
There are two project types you can create in Visual Studio 2008 .The default Web site project model uses a file directory structure to define the contents of a project. In this model, there is no project file, and all files in the directory are part of the project.
In contrast, in a Web application project, only files that are explicitly referenced in the solution's project file are part of the project. These files are displayed in Solution Explorer, and they are the only files that are compiled during a build.
The project file of a Web application project makes some scenarios easier to implement. For instance, you can subdivide one ASP.NET application into multiple Visual Studio projects by referencing files in different project files. You can also easily exclude files from the project.
Use Web application projects when you want to do the following: |
| Migrate large Visual Studio .NET 2003 applications to Visual Studio 2008. |
| Have control over the names of output assemblies. |
| Use standalone classes to reference page classes and user-control classes. |
| Build a Web application by using multiple Web projects. |
| Add pre-build and post-build steps during compilation. |
|
| Accessing Data from a Data Store |
ASP.NET data binding lets you bind components to data sources and to simple properties, collections, expressions, and methods. This provides greater flexibility when you use data from a database or other sources.
If the Web site accesses a data store, you should consider using the data source controls, because they are part of a common data pattern. This data pattern separates the data-access code and business logic code from the Web pages that form the presentation layer of the Web site. A data-access layer consists of methods that are used to access a data store. A business logic layer adds rules to the data access layer, such as restricting access on who can view or change the data. The presentation layer consists of pages that the user accesses to view and modify the data.
You can implement this common data pattern by separating the presentation layer from the data and business logic layers by using the data source model in ASP.NET. By using such controls as the LinqDataSource, ObjectDataSource, and the SqlDataSource controls, you create a data access layer and business logic layer that are separate from the presentation layer.
You should also consider whether the Web site must use in-memory (cached) data. If a significant portion of the application data does not change frequently and is common across sessions or users, you can keep the data in memory on the Web server. This can reduce the number of requests to the database and speed up the user's interactions. You create an in-memory database using the DataSet class. Another useful aspect of the DataSet object is that it enables an application to bring subsets of data from one or more data sources into the application space. The application can then handle the data in-memory, while retaining its relational shape. |
|
| Site Navigation |
As a site grows, and as you move pages around in the site, it can quickly become difficult to manage all the links. ASP.NET site navigation consists of server controls and classes that enable you to provide a consistent way for users to navigate the site. You can store links to all the pages in a central location (typically an XML file). You can render those links in lists or navigation menus on each page by including a SiteMapDataSource control to read site information. You then use a navigation server control such as the TreeView or Menu controls to display site information.
A key part of ASP.NET site navigation is the site map provider. This is a class that is used with a site map data source and exposes navigation information. For example, the default ASP.NET site map provider obtains site map data from an XML file that is named Web.sitemap, and communicates that data to the SiteMapPath Web server control |
|
| Defining a Consistent Web Site Look |
Several features in ASP.NET help you create and maintain a consistent appearance and design for the Web site, such as ASP.NET themes and ASP.NET master pages. These features can be used early in the site-development process to provide a consistent look for the Web site.
ASP.NET themes define the appearance of pages and controls in the Web site. An ASP.NET theme can include skin files, which define property settings for ASP.NET Web server controls., A theme can also include and cascading style sheet files (.css files) and graphics. By applying a theme, you can give the pages in the Web site a consistent appearance. When you create a theme or set of themes for a site early in the development process, you can apply these themes to each new page that you create. ASP.NET master pages let you create a page layout (a master page) that you can apply to selected pages (content pages) in the Web site. Master pages can greatly simplify the task of creating a consistent look for your site. You can also nest master pages. For example, you can use nested master pages to create one master layout for the whole site and another master layout for individual sections of a site. You can also use master pages with themes. |
|
| Adding AJAX Functionality |
| AJAX features in ASP.NET enable you to quickly create Web pages that include a rich user experience with responsive and familiar user interface (UI) elements. It also enables you to refresh a page without a postback. AJAX features include client-script libraries that incorporate cross-browser ECMAScript (JavaScript) and dynamic HTML (DHTML) technologies, and integration with the ASP.NET server-based development platform. By using AJAX features, you can improve the user experience and the efficiency of Web applications. |
|
| Using State Management Features |
HTTP is a stateless protocol. Each request is serviced as it comes; after the request is processed, all the data is discarded. No state is maintained across requests even from the same client. However, for most Web applications, it is useful to maintain state across requests.
ASP.NET provides intrinsic state management functionality that enables you to store information between page requests, such as customer information or the contents of a shopping cart. You can save and manage application-specific, session-specific, page-specific, user-specific, and developer-defined information. ASP.NET has several forms of state management to select from, which includes using cookies, view state, session state, application state and profile properties. This information can be independent of any controls on the page.
When you plan a Web site, you should consider which forms of state management you will need. |
|
| Caching Data for Performance |
Often you can increase the performance of a Web site by storing data in memory that is accessed frequently and that requires significant processing time to create. For example, if your application processes large amounts of data by using complex logic and then returns the data as a report, it is efficient to avoid recreating the report every time that a user requests it. Similarly, if your application includes a page that processes complex data but the page is updated only infrequently, it is inefficient for the server to re-create that page on every request.
The ASP.NET cache is a general-purpose cache facility for Web sites. It provides a simple interface for caching and a more advanced interface that exposes expiration and change dependency services. To help you increase application performance in these situations, ASP.NET provides two caching mechanisms. The first is application caching, which enables you to cache data that you generate, such as a DataSet or a custom report business object. The second is page output caching, which saves the output of page processing and reuses the output instead of re-processing the page when a user requests the page again. If the Web site design takes into consideration caching particular pages, you can create a more efficient Web site. |
|
| Security Infrastructure |
| In addition to the security features of the ..NET Framework, ASP.NET provides a security infrastructure for authenticating and authorizing user access as well as performing other security-related tasks. You can authenticate users by using Windows authentication supplied by IIS. Alternatively, you can manage authentication by using ASP.NET forms authentication and ASP.NET membership. Additionally, you can manage the authorization to access resources of the Web application by using Windows groups or by using a custom role database and ASP.NET roles. You can easily remove, add to, or replace these schemes depending on the needs of your application. |
|
| ASP.NET always runs with a particular Windows identity so that you can secure your application by using Windows capabilities such as NTFS file system Access Control Lists (ACLs) and database permissions. For more information about the identity that ASP.NET runs under, see Configuring ASP.NET Process Identity and ASP.NET Impersonation. |
|
| Other Considerations |
| The topics in this section are topics you should also consider before you begin coding a Web site. By incorporating the information in these topics in your planning, you can save time and make your site compliant to today's Web standards. |
|
| Accessibility |
| Accessibility programming is the process of designing and developing applications that work with a computer's operating system to provide for specific impairments, such as a limited range of motion or blindness. ASP.NET can help you create Web applications that can be accessed by people with disabilities. Accessible Web applications enable people to use assistive technologies, such as screen readers, to work with Web pages. Accessible Web applications have the following advantages: |
| They are usable by the widest possible audience. |
| They involve design principles that frequently benefit all users, not just those with disabilities. |
| They meet the requirements of many institutions that require all Web applications to be accessible. |
By understanding accessibility guidelines and how ASP.NET can help you meet those guidelines, you can create applications that are easier for people that have disabilities to interact with. For more information about accessibility guidelines, see Accessibility Support in ASP.NET.
Most of the time, ASP.NET controls render markup that creates pages that meet accessibility standards. They might also expose properties that you can set to make the pages accessible. However, sometimes ASP.NET controls render output that does not comply with all accessibility standards. |
|
| Globalization and Localization |
| Globalization is the process of designing and developing applications that function for multiple cultures. Localization is the process of customizing your application for a given culture and locale. If you create Web pages that will be read by speakers of different languages, you must enable readers to view the page in their own language. ASP.NET lets you create a page that can obtain content and other data based on the preferred language setting for the browser or the user's explicit choice of language. This content and other data is referred to as resources and such data can be stored in resource files or other sources. In the ASP.NET Web page, you configure controls to get their property values from resources. At run time, the resource expressions are replaced by resources from the appropriate resource file. |
|
| Building Individual Pages and Precompiling |
Building a page or Web site is part of developing a site, and is intended to help you find compile-time errors that might occur anywhere in the site. Although building does compile the pages, it does not produce an assembly that you can deploy.
You can deploy a site without compiling it by copying all the files in the Web site to a production server. When users request pages from the production server, ASP.NET dynamically compiles the site, effectively performing the same steps that the build process does in Visual Studio. (ASP.NET caches the resulting output so that the pages do not have to be recompiled with each request.)
If you want to compile the site into assemblies and other files that you can deploy, you can publish the site. Publishing performs the same compilation steps that building does, but it saves the output into a folder and subfolders that you can in turn deploy to the production server. |
|
|
|
| Click here to submit your project requirements to Option Matrix, India. |
| Back to top |
 |
| ASP.NET Web Site Layout |
|
|
| You can keep your Web site's files in any folder structure that is convenient for your application. To make it easier to work with your application, ASP.NET reserves certain file and folder names that you can use for specific types of content. |
|
| Default Pages |
You can establish default pages for your application, which can make it simpler for users to navigate to your site. The default page is the page that is served when users navigate to your site without specifying a particular page. For example, you can create a page named Default.aspx and keep it in your site's root folder. When users navigate to your site without specifying a particular page (for example, http://www.contoso.com/) you can configure your application so that the Default.aspx page is requested automatically. You can use a default page as the home page for your site, or you can write code in the page to redirect users to other pages.
Note: In Internet Information Services (IIS), default pages are established as properties of your Web site. |
|
| Application Folders |
| ASP.NET recognizes certain folder names that you can use for specific types of content. The table below lists the reserved folder names and the type of files that the folders typically contain. |
|
 |
Note: |
| The content of application folders, except for the App_Themes folder, is not served in response to Web requests, but it can be accessed from application code. |
|
| Folder |
Description |
| App_Browsers |
Contains browser definitions (.browser files) that ASP.NET uses to identify individual browsers and determine their capabilities. |
| App_Code |
| Contains source code for utility classes and business objects (for example, .cs, .vb, and .jsl files) that you want to compile as part of your application. In a dynamically compiled application, ASP.NET compiles the code in the App_Code folder on the initial request to your application. Items in this folder are then recompiled when any changes are detected. |
|
Note: |
| Arbitrary file types can be placed in the App_Code folder to create strongly typed objects. For example, placing Web service files (.wsdl and .xsd files) in the App_Code folder creates strongly typed proxies. |
|
| Code in the App_Code folder is referenced automatically in your application. In addition, the App_Code folder can contain subdirectories of files that need to be compiled at run time.. |
|
| App_Data |
Contains application data files including MDF files, XML files, as well as other data store files. The App_Data folder is used by ASP.NET 2.0 to store an application's local database, which can be used for maintaining membership and role information. |
| App_GlobalResources |
Contains resources (.resx and .resources files) that are compiled into assemblies with global scope. Resources in the App_GlobalResources folder are strongly typed and can be accessed programmatically. For more information. |
| App_LocalResources |
Contains resources (.resx and .resources files) that are associated with a specific page, user control, or master page in an application For more information. |
| App_Themes |
Contains a collection of files (.skin and .css files, as well as image files and generic resources) that define the appearance of ASP.NET Web pages and controls. |
| App_WebReferences |
Contains reference contract files (.wsdl files), schemas (.xsd files), and discovery document files (.disco and .discomap files) defining a Web reference for use in an application. For more information about generating code for XML Web services. |
| Bin |
Contains compiled assemblies (.dll files) for controls, components, or other code that you want to reference in your application. Any classes represented by code in the Bin folder are automatically referenced in your application. For more information. |
|
|
|
| Managing Subfolders |
| Configuration settings for your site are managed in a Web.config file that is located in the site's root folder. If you have files in subfolders, you can maintain separate configuration settings for those files by creating a Web.config file in that folder. |
|
|
|
| Click here to submit your project requirements to Option Matrix, India. |
| Back to top |
 |
| ASP.NET Web Site File Types |
|
|
Web site applications can contain a number of file types, some supported and managed by ASP.NET, and others supported and managed by the IIS server.
Most of the ASP.NET file types can be automatically generated using the Add New Item menu item in Visual Web Developer. File types are mapped to applications using application mappings. For example, if you use double-click a .txt file in Windows Explorer, Notepad will probably open, because in Windows, .txt file types are mapped by default to Notepad.exe. In Web applications, file types are mapped to application extensions in IIS. |
|
| File Types Managed by ASP.NET |
| File types that are managed by ASP.NET are mapped to the Aspnet_isapi.dll in IIS. |
|
| File type |
Location |
Description |
| .asax |
Application root. |
Typically a Global.asax file that contains code that derives from the HttpApplication class. This file represents the application and contains optional methods that run at the start or end of the application lifetime.
For more information, see Global.asax Syntax. |
| .ascx |
Application root or a subdirectory. |
A Web user control file that defines a custom, reusable control. |
| .ashx |
Application root or a subdirectory. |
A generic handler file that contains code that implements the IHttpHandler interface. |
| .asmx |
Application root or a subdirectory. |
An XML Web services file that contains classes and methods that are available to other Web applications by way of SOAP. |
| .aspx |
Application root or a subdirectory. |
An ASP.NET Web forms file (page) that can contain Web controls and presentation and business logic. |
| .axd |
Application root. |
A handler file used to manage Web site administration requests, typically Trace.axd. |
| .browser |
App_Browsers subdirectory. |
A browser definition file used to identify the features of client browsers. |
| .cd |
Application root or a subdirectory. |
A class diagram file. |
| .compile |
Bin subdirectory. |
A precompiled stub file that points to an assembly representing a compiled Web site file. Executable file types (.aspx, ascx, .master, theme files) are precompiled and put in the Bin subdirectory. |
| .config |
Application root or a subdirectory. |
A configuration file (typically Web.config) containing XML elements that represent settings for ASP.NET features. |
| .cs, .jsl, .vb |
App_Code subdirectory, or in the case of a code-behind file for an ASP.NET page, in the same directory as the Web page. |
Class source-code file that is compiled at run time. The class can be an HTTP Module, an HTTP Handler, a code-behind file for an ASP.NET page, or a stand-alone class file containing application logic. |
| .csproj, .vbproj, vjsproj |
Visual Studio project directory. |
A project file for a Visual Studio client-application project. |
| .disco, .vsdisco |
App_WebReferences subdirectory. |
An XML Web services discovery file used to help locate available Web services. |
| .dsdgm, .dsprototype |
Application root or a subdirectory. |
A distributed service diagram (DSD) file that can be added to any Visual Studio solution that provides or consumes Web services to reverse-engineer an architectural view of the Web service interactions. |
| .dll |
Bin subdirectory. |
A compiled class library file (assembly). Note that instead of placing compiled assemblies in the Bin subdirectory, you can put source code for classes in the App_Code subdirectory. |
| .licx, .webinfo |
Application root or a subdirectory. |
A license file. Licensing allows control authors to help protect intellectual property by checking that a user is authorized to use the control. |
| .master |
Application root or subdirectory. |
A master page that defines the layout for other Web pages in the application. |
| .mdb, .ldb |
App_Data subdirectory. |
An Access database file. |
| .mdf |
App_Data subdirectory. |
SQL database file for use with SQL Server Express. |
| .msgx, .svc |
Application root or a subdirectory. |
An Indigo Messaging Framework (MFx) service file. |
| .rem |
Application root or a subdirectory. |
A remoting handler file. |
| .resources, .resx |
App_GlobalResources or App_LocalResources subdirectory. |
A resource file that contains resource strings that refer to images, localizable text, or other data. |
| .sdm, .sdmDocument |
Application root or a subdirectory. |
A system definition model (SDM) file. |
| .sitemap |
Application root. |
A site-map file that contains the structure of the Web site. ASP.NET comes with a default site-map provider that uses site-map files to easily display a navigational control in a Web page. |
| .skin |
App_Themes subdirectory. |
A skin file containing property settings to apply to Web controls for consistent formatting. |
| .sln |
Visual Web Developer project directory. |
A solution file for a Visual Web Developer project. |
| .soap |
Application root or a subdirectory. |
A SOAP extension file. |
|
|
|
| File Types Managed by IIS |
| File types that are managed by ASP.NET are usually mapped to the asp.dll handler in IIS. |
| File type |
Location |
Description |
| .asa |
Application root. |
Typically a Global.asa file that contains optional methods that run at the start or end of the ASP session or application lifetime. |
| .asp |
Application root or a subdirectory. |
An ASP Web page that contains @ directives and script code that uses the ASP built-in objects. |
| .cdx |
App_Data subdirectory. |
A compound index file structure file for Visual FoxPro. |
| .cer |
Application root or a subdirectory. |
A certificate file used to authenticate a Web site. |
| .idc |
Application root or a subdirectory. |
| An Internet Database Connector file mapped to httpodbc.dll. |
|
Note: |
| IDC has been deprecated because it does not provide enough security for data connections. IIS 6.0 will be the last version to include IDC. |
|
|
| .shtm, .shtml, .stm |
Application root or a subdirectory. |
Mapped to ssinc.dll. |
|
|
|
| Static File Types |
IIS serves static files only if their file-name extensions are registered in the MIME types list. This list is stored in the MimeMap IIS metabase property for an application. If a file type is mapped to an application extension, it does not need to be included in the MIME types list unless you want the file to be treated like a static file. Typically, ASP.NET source code file types should not be in the MIME types list because that might allow browsers to view the source code.
The following table lists only a few of the registered file types. |
|
| File type |
Location |
Description |
| .css |
Application root or subdirectory, or App_Themes subdirectory. |
Style sheet files used to determine the formatting of HTML elements. |
| .htm, .html |
Application root or subdirectory. |
Static Web files written in HTML code. |
|
|
|
|
|
|
| Click here to submit your project requirements to Option Matrix, India. |
| Back to top |
 |
| Development Optimization Features |
|
|
| Optimizing ASP.NET 2.0 Web Project Build Performance with VS 2005 |
|
| This post covers how to best optimize the build performance with Visual Studio 2005 when using web projects. If you are experiencing slow builds or want to learn how to speed them up please read on. |
|
 |
|
| Quick Background on VS 2005 Web Site Project and VS 2005 Web Application Project options |
VS 2005 supports two project-model options: VS 2005 Web Site Projects and VS 2005 Web Application Projects.
VS 2005 Web Site Projects were built-in with the initial VS 2005 release, and provide a project-less based model for doing web development that uses that same dynamic compilation system that ASP.NET 2.0 uses at runtime. VS 2005 Web Application Projects were released as a fully supported download earlier this spring, and provide a project model that uses a MSBuild based build system that compiles all code in a project into a single assembly (similar to VS 2003 -- but without many of the limitations that VS 2003 web projects had with regard to FrontPage Server Extensions, IIS dependencies, and other issues
Both the VS 2005 Web Site Project option and the VS 2005 Web Application Project option will continue to be fully supported going forward with future Visual Studio releases. What we've found is that some people love one option, while disliking the other, and vice-versa. From a feature perspective there is no "one best option" to use - it really depends on your personal preferences and team dynamics as to which will work best for you. For example: a lot of enterprise developers love the VS 2005 Web Application option because it provides a lot more build control and team integration support, while a lot of web developers love the VS 2005 Web Site model because of its "just hit save" dynamic model and flexibility.
To migrate from the VS 2005 Web Site Project model to the VS 2005 Web Application Project model, please follow this C# or VB tutorial that walks-through the steps for how to-do so. |
|
| So Which Project Option Builds Faster? |
When doing full builds of projects, the VS 2005 Web Application Project option will compile projects much faster that the VS 2005 Web Site Project option. By "full build" I mean cases where every class and page in a project is being compiled and re-built - either because you selected a "Rebuild" option within your "build" menu, or because you modified code within a dependent class library project or in the /app_code directory and then hit "build" or "ctrl-shift-b" to compile the solution.
There are a few reasons why the VS 2005 Web Application Project ends up being significantly faster than Web Site Projects in these "full rebuild" scenarios. The main reason is that (like VS 2003), the VS 2005 Web Application Project option only compiles your page's code-behind code and other classes within your project. It does not analyze or compile the content/controls/in-line code within your .aspx pages -- which means it does not need to parse those files. On the downside this means that during compilation it will not check for errors in those files (unlike the VS 2005 Web Site Project option which will identify any errors there). On the positive side it makes compilations much faster.
So does this mean that you should always use the VS 2005 Web Application Project option to get the fastest build times with large projects? No -- not necessarily. One nice feature that you can enable with the VS 2005 Web Site Project option is support for doing "on demand compilation". This avoids you having to always re-build an entire project when dependent changes are made -- instead you can just re-build those pages you are working on and do it on-demand. This will lead to significant build performance improvements for your solution, and can give you a very nice workflow when working on very large projects. I would definitely recommend using this option if you want to improve your build performance, while retaining the flexibility of the web-site model.
The below sections provide specific tutorials for both the VS 2005 Web Site Project Model and the VS 2005 Web Application Project Model on optimization techniques -- including the "on demand compilation" build option I described above. |
|
| Specific Tips/Tricks for Optimizing VS 2005 Web Site Project Build Times |
When using the VS 2005 Web Site Project model, you can significantly improve build performance times by following these steps:
1) Verify that you are not suffering from an issue I call "Dueling Assembly References". I describe how to both detect and fix this condition. If you are ever doing a build and see the compilation appear to pause in the "Validating Web Site" phase of compilation (meaning no output occurs in the output window for more than a few seconds), then it is likely that you are running into this problem.
2) Keep the number of files in your /app_code directory small. If you end up having a lot of class files within this directory, I'd recommend you instead add a separate class library project to your VS solution and move these classes within that instead since class library projects compile faster than compiling classes in the /app_code directory. This isn't usually an issue if you just have a small number of files in /app_code, but if you have lots of directories or dozens of files you will be able to get speed improvements by moving these files into a separate class library project and then reference that project from your web-site instead. One other thing to be aware of is that whenever you switch from source to design-view within the VS HTML designer, the designer causes the /app_code directory to be compiled before the designer surface loads. The reason for this is so that you can host controls defined within /app_code in the designer. If you don't have an /app_code directory, or only have a few files defined within it, the page designer will be able to load much quicker (since it doesn't need to perform a big compilation first).
3) Enable the on-demand compilation option for your web-site projects. To enable this, right-click on your web-site project and pull up the project properties page. Click the "Build" tab on the left to pull up its build settings. Within the "Build" tab settings page change the F5 Start Action from "Build Web Site" to either the "Build Page" or "No Build" option. Then make sure to uncheck the "Build Web site as part of solution" checkbox: |
|
 |
|
When you click ok to accept these changes you will be running in an on-demand compilation mode. What this means (when you select the "Build Page" option in the dialog above) is that when you edit a page and then hit F5 (run with debugging) or Ctrl-F5 (run without debugging) the solution will compile all of the class library projects like before, then compile the /app_code directory and Global.asax file, and then instead of re-verifying all pages within the web-site it will only verify the current page you are working on, and any user controls that the page references. With large (and even medium) projects with lots of pages, this can obviously lead to major performance wins. Note that ASP.NET will automatically re-compile any other page or control you access at runtime -- so you will always have an up-to-date and current running application (you don't need to worry about old code running). You can optionally also use the "No Build" option to by-pass page-level validation in the IDE, which obviously speeds up the entire process much further (I'd recommend giving both options a try to see which you prefer).
By deselecting the "Build Web site as part of solution" checkbox, you will find that the Ctrl-Shift-B keystroke (which builds the solution) will continue compiling all class library projects, but will not re-build all pages within your web-site project. You will still get full intellisense support in your pages in this scenario - so you won't lose any design-time support. You will also continue to get warning/error squiggles in code/class when they are open. If you want a way to force a re-build to occur on pages not open, or across all pages within the web-site, you can use the "Build Page" or "Build Web Site" menu options within the "Build" menu of Visual Studio: |
|
 |
|
| This gives you control as to which pages on your site you want to verify (and when) - and can significantly improve build performance. One trick I recommend doing is adding a new shortcut keystroke to your environment to allow you to quickly short-cut the "Build Page" menu option to avoid you having to ever use a mouse/menu for this. You can do this by selecting the Tools->Customize menu item, and then click the "Keyboards" button on the bottom-left of the customize dialog. This will bring up a dialog box that allows you to select the VS Build.BuildPage command and associate it within any keystroke you want: |
|
 |
|
Once you do this, you can type "Ctrl-Shift-P" (or any other keystroke you set) on any page to cause VS to compile any modified class library project (effectively the same thing that Ctrl-Shift-B does), then verify all classes within the /app_code directory, and then re-build just the page or user control (and any referenced master pages or user controls it uses) that you are working on within the project.
Once the above steps are applied, you should find that your build performance and flexibility is much improved - and that you have complete control over builds happen. |
|
| Specific Tips/Tricks for Optimizing VS 2005 Web Application Project Build Times |
If you are using the VS 2005 Web Application project option, here are a few optimizations you might want to consider:
1) If you have a very large project, or are working on an application with many other developers, you might want to consider splitting it up into multiple "sub-web" projects. I wouldn't necessarily recommend this for performance reasons (unless you have thousands and thousands of pages it probably doesn't make a huge difference), but it can sometimes make it easier to help manage a large project
2) Consider adding a VS 2005 Web Deployment project to your solution for deep verification. I mentioned above that one downside of using the VS 2005 Web Application Project option was that it only compiled the code-behind source code of your pages, and didn't do a deeper verification of the actual .aspx markup (so it will miss cases where you have a mis-typed tag in your .aspx markup). This provides the same level of verification support that VS 2003 provided (so you aren't loosing anything from that), but not as deep as the Web Site Project option. One way you can still get this level of verification with VS 2005 Web Application Projects is to optionally add a VS 2005 Web Deployment Project into your solution (web deployment projects work with both web-site and web-application solutions). You can configure this to run only when building "release" or "staging" builds of your solution (to avoid taking a build hit at development time), and use it to provide a deep verification of both your content and source code prior to shipping your app. |
|
| Common Tips/Tricks for Optimizing any VS 2005 Build Time |
Here are a few things I recommend checking anytime you have poor performance when building projects/solutions (note: this list will continue to grow as I hear new ones - so check back in the future):
1) Watch out for Virus Checkers, Spy-Bots, and Search/Indexing Tools
VS hits the file-system a lot, and obviously needs to reparse any file within a project that has changed the next time it compiles. One issue I've seen reported several times are cases where virus scanners, spy-bot detecters, and/or desktop search indexing tools end up monitoring a directory containing a project a little too closely, and continually change the timestamps of these files (they don't alter the contents of the file - but they do change a last touched timestamp that VS also uses). This then causes a pattern of: you make a change, rebuild, and then in the background the virus/search tool goes in and re-searches/re-checks the file and marks it as altered - which then causes VS to have to re-build it again. Check for this if you are seeing build performance issues, and consider disabling the directories you are working on from being scanned by other programs. I've also seen reports of certain Spybot utilities causing extreme slowness with VS debugging - so you might want to verify that you aren't having issues with those either.
2) Turn off AutoToolboxPopulate in the Windows Forms Designer Options
There is an option in VS 2005 that will cause VS to automatically populate the toolbox with any controls you compile as part of your solution. This is a useful feature when developing controls since it updates them when you build, but I've seen a few reports from people who find that it can cause VS to end up taking a long time (almost like a hang) in some circumstances. Note that this applies both to Windows Forms and Web Projects. To disable this option, select the Tools->Options menu item, and then unselect the Windows Forms Designer/General/AutoToolboxPopulate checkbox
3) Examine which 3rd party packages are running in Visual Studio
There are a lot of great 3rd party VS packages that you can plug into Visual Studio. These deliver big productivity wins, and offer tons of features. Occasionally I've seen issues where performance or stability is being affected by them though. This is often true in cases where an older version (or beta) of one of these packages is being used (always keep an eye out for when a manufacturer updates them with bug-fixes). If you are seeing issues with performance or stability, you might want to look at trying a VS configuration where you uninstall any additional packages to see if this makes a difference. If so, you can work with the 3rd party manufacturer to identify the issue. |
|
|
|
|
| Click here to submit your project requirements to Option Matrix, India. |
| Back to top |
| Option Matrix Featured Case Studies |
|
| Option Matrix Whitepapers |
|
|
|
|
| Portal for Multi-location Hospital |
| The client was a healthcare provider (multi-location hospital) for the local resident patients having sleeping disorders. Option Matrix's scope of consulting was for their Seattle, |
|
|
|
| Health Fitness Portal |
| Client was establishing a Health Fitness Center at California established in June 2006 by a team of local Antelope Valley residents. It was offered full complement of new and innovative |
|
|
|
| Sleep Disorders Hospital Application |
| This project was the company service portal of "Client" for patients suffering from sleep disorders. It was information about the company, key personnel, HIPPA privacy, education resources, |
|
|
|
| Batteries Ecommerce Portal |
| The objective was to design an e-commerce website for Client to display their catalog of batteries online and collect orders which was forwarded by e-mail to be serviced by a third |
|
|
|
| Spices & Herbs Ecommerce Website |
| The overall purpose of this project was to develop an intuitive and professional spice and herbal ecommerce web site. This web site was accessed by site visitors, members (retail consumers), |
|
| | | | | | | | |
