Jack @ ASP.NET

The aspnet.config file is a little known config file which is supported by ASP.NET 2.0 and greater.  Generally it lives in the root of the framework folder, for example:

C:\Windows\Microsoft.NET\Framework64\v4.0.30319\aspnet.config

C:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet.config

C:\Windows\Microsoft.NET\Framework64\v2.0.50727\aspnet.config

C:\Windows\Microsoft.NET\Framework\v2.0.50727\aspnet.config

This config file is further leveraged in ASP.NET 4.0 for concurrency and threading.  For example, you can set maxConcurrentRequestsPerCPU, maxConcurrentThreadsPerCPU and requestQueueLimit, in addition to the previous runtime settings.

In Windows Server 2008 R2 (IIS 7.5) support was added to allow different settings per application pool.  Where previously the settings had to be applied to the whole framework version, now they can be specific to each app pool.  It does this by allowing you to create a custom aspnet.config file per app pool.  You can save them wherever you want on disk and IIS will pick them up when the app pool starts.

Note that the framework aspnet.config file is still used so only differences per app pool need to be set here.

Here’s an example of what the file can contain:

<?xml version="1.0" encoding="UTF-8" ?>

<configuration>

    <runtime>

        <legacyUnhandledExceptionPolicy enabled="false" />

        <legacyImpersonationPolicy enabled="true"/>

        <alwaysFlowImpersonationPolicy enabled="false"/>

        <SymbolReadingPolicy enabled="1" />

        <shadowCopyVerifyByTimestamp enabled="true"/>

    </runtime>

    <startup useLegacyV2RuntimeActivationPolicy="true" />

  <system.web>

    <applicationPool

        maxConcurrentRequestsPerCPU="5000"

        maxConcurrentThreadsPerCPU="0"

        requestQueueLimit="5000" />

  </system.web>

</configuration>

Internationalization involves Globalization and Localization. And the globalization is the process of designing applications that support different cultures. While localization is the process of customizing an application for a given culture.

The format for the culture name is "<languagecode2>-<country/regioncode2>", where <languagecode2> is the language code and <country/regioncode2> is the subculture code. Examples include es-CL for Spanish (Chile) and en-US for English (United States).

ASP.NET keeps track of two culture values, the Culture and UICulture. The culture value determines the results of culture-dependent functions, such as the date, number, and currency formatting. The UICulture determines which resources are to be loaded for the page by the ResourceManager. The ResourceManager simply looks up culture-specific resources that is determined by CurrentUICulture. Every thread in .NET has CurrentCulture and CurrentUICulture objects. So ASP.NET inspects these values when rendering culture-dependent functions. For example, if current thread’s culture (CurrentCulture) is set to "en-US" (English, United States), DateTime.Now.ToLongDateString() shows "Saturday, January 08, 2011", but if CurrentCulture is set to "es-CL" (Spanish, Chile) the result will be "sábado, 08 de enero de 2011".

NuGet is a free, open source, package manager that makes it easy for you to find, install, and use open source libraries in your projects. It works with all .NET project types (including ASP.NET Web Forms, ASP.NET MVC, WPF, WinForms, Silverlight, and Class Libraries).

NuGet enables developers who maintain open source projects (for example, .NET projects like Moq, NHibernate, Ninject, StructureMap, NUnit, Windsor, Raven, Elmah, etc) to package up their libraries and register them with an online gallery/catalog that is searchable.  The client-side NuGet tools – which include full Visual Studio integration – make it trivial for any .NET developer who wants to use one of these libraries to easily find and install it within the project they are working on.

NuGet handles dependency management between libraries (for example: library1 depends on library2). It also makes it easy to update (and optionally remove) libraries from your projects later. It supports updating web.config files (if a package needs configuration settings). It also allows packages to add PowerShell scripts to a project (for example: scaffold commands). Importantly, NuGet is transparent and clean – and does not install anything at the system level. Instead it is focused on making it easy to manage libraries you use with your projects.

Let’s take ELMAH as an example. It’s a fine error logging utility which has no dependencies on other libraries, but is still a challenge to integrate into a project. These are the steps it takes:

1. Find ELMAH
2. Download the correct zip package.
3. “Unblock” the package.
4. Verify its hash against the one provided by the hosting environment.
5. Unzip the package contents into a specific location in the solution.
6. Add an assembly reference to the assembly.
7. Update web.config with the correct settings which a developer needs to search for.

1. Browser caching

In part 1, we looked at how it was possible to set an expiration header to any static file such as JavaScript and CSS files, so the browser would cache them for a long time and thereby optimize both for bandwidth and the number of requested files going from server to browser.

The problem with setting a browser cache expiration date of i.e. a JavaScript file to a year in the future becomes clear when you change the file before it expires in your visitor’s browsers. They simply won’t see the changes until they either clear their cache or hits F5 manually.

2. Bundle multiple files

Another common website performance issue is that there are many JavaScript and CSS files included on a page. This scenario results in the browser have to download a lot of extra files and that all slows down the performance of a website. The solution to this is also very simple when you’ve first completed the above steps to register the HTTP handler in web.config and called the BundleHelper.InsertFile method when inserting JavaScript and CSS files.

3. HTTP compression

You’ve always been able to perform HTTP compression in ASP.NET by using third-party libraries or own custom built ones. With IIS 7 you can now throw that away and utilize the build-in compression available from the web.config. Add the following line to enable HTTP compression:

<urlCompression doDynamicCompression=”true” doStaticCompression=”true” dynamicCompressionBeforeCache=”true”/>

By default, only text based content types are compressed.

4. Cache static files

To speed up the load time for the visitors, it is crucial that everything that can be cached by the browser IS cached by the browser. That includes static files such as images, stylesheets and script files. By letting the browser cache all these files means it doesn’t need to request them again for the duration of the cache period. That saves you and your visitors a lot of bandwidth and makes the page load faster. A well primed browser cache also triggers the load and DOMContentLoaded event sooner.

It’s worth noticing that the output caching respects file changes and therefore refreshes ever time changes are made to the JavaScript and CSS files tunnelled through this code.

Some members of the C# community were discussing optional parameters and the implications for future versions when optional parameter values change.  In short, you need to realize that changing the value of optional parameters in a public API is a change that is observable at client code. The ramifications vary greatly, from “no big” to “stop the world”. I’ll give a brief explanation of how the feature works, and what you need to watch for and how to separate reasonable caution from irrational fear from using a feature.

While most modern programming languages provide some way of declaring optional function parameters, C# doesn’t provide a way of directly doing so, despite the fact that VB.NET and .NET’s attribute system both support this functionality. This is a subject of some debate currently in the C# community. The C# development team’s position seems to boil down to the following: When provided, this feature is usually nothing more than dressing up method overloading with a little syntactic sugar.

When you get right down to it, their position makes some sense. A function with an optional parameter is in reality two different functions: one that assumes some default behavior if the optional parameter is omitted, and another that performs more specific behavior based on the value of the optional parameter if provided. But that doesn’t change the fact that using overloaded methods to provide optional parameter support feels a little clunky. It works, but you always wind up writing more code, and you pollute your object interface with the extra method signatures required to support all of your optional parameters. Let’s look at some alternatives.

Can BlogEngine.NET be installed within an existing website?

Yes. Install it in its own folder and configure the directory it resides in as an application in IIS.

Some hosting providers may not allow the level of trust used in BlogEngine.NET by default. If you receive an error similar to:

• “Parser Error Message: It is an error to use a section registered as allowDefinition=’MachineToApplication’ beyond application level.”,

You can try one of the following to resolve the issue:

• Comment out the “trust” line in web.config
• Ask your hosting provider if they can configure the directory where BlogEngine.NET is installed as a virtual directory.
• Ask your hosting provider to verify that the directory has been configured as an application in IIS.

How do I update the “About the Author” section of the blog?

In the default Standard theme, edit the content of this section by clicking “edit” in on the side bar of your blog.

An alternative way to display About the Author information is to create a ‘Page’ in the control panel. The Title of the Page can be About the Author. Enter information about the author in the WYSIWYG editor. Once the page has been created, you can add a link to the About page on your blog. This can be achieved by adding a Page List widget, or by adding a TextBox widget with a hyperlink to the About page, or by editing your theme file (site.master) and adding a hyperlink to the About page.

Is BlogEngine.NET open source and completely free?

Yes. BlogEngine.NET is built by passionate developers who have too much spare time, just to make an open source blog engine to give away absolutely free.

Is my mother able to use it?

Yes. We have gone to great lengths to make BlogEngine.NET as easy as possible to use &ndash; both from an end user as well as a developer or theme designer’s point of view.

What are the demands for the web server?

The only thing needed to run BlogEngine.NET is a web server that support ASP.NET 2.0 and write permissions on the App_Data folder.

What database is it running on?

None. BlogEngine.NET uses XML to store all posts, pages etc. by default. However, if you prefer to use a database, BlogEngine.NET includes a “DbBlogProvider” that allows you to store data in databases which support standard SQL — MS SQL Server, MySql, SQLite and Vista DB among many others. Configuration changes necessary to store data in a SQL Server database can be found. If there isn’t a data provider already available, you can easily write your own provider. We have enginereed our framework to make this very easy and simple to do.

How can I switch where data is stored (XML to Database or vice versa)?

If you’re just starting off with BlogEngine.NET, all of your data will be stored in XML files in your App_Data folder. Some web hosts such as GoDaddy who have an automatic BlogEngine.NET setup option, might setup your blog so data is stored in a database instead. If your blog is new, you don’t yet have any data, and you want to switch from XML storage to Database storage