What is needed to configure a new extension for use in ASP.NET?

Got a question a while back from a customer asking how to enable ASP.NET pages with custom file extensions, so I played around a bit to see how to do it, and here’s what I came up with:

1. Open up the IIS 5.1 or 6 management console, and navigate to the virtual directory (or web site) that you want to configure. Right-click the folder and select Properties.

2. On the Directory (or Web Site) tab, click the Configuration button.

3. On the Mappings tab, click Add, and enter aspnet_isapi.dll (the path is under Windows\Microsoft.net\Framework\<version>\…check the existing mapping for .aspx if you need the exact path) as the Executable, and your desired extension under Extension (I used .foo). Clear the “Check that file exists” box. Click OK (if OK is greyed out, tab around in the textboxes a bit, that usually seems to clear the issue that prevents it from being active). Click OK.

4. In your web.config file (or the main web.config for the machine, if you want this to apply to all sites), add the following HttpHandler mapping (inside the <system.web> tags:

<httpHandlers>

      <add path=”*.foo” verb=”*” type=”System.Web.UI.PageHandlerFactory” validate=”true” />

</httpHandlers>

5. Also in your web.config, add the following Build Provider mapping (goes between the <compilation> tags, you may need to edit the default tag, since in ASP.NET 2.0 it defaults to a self-closing tag):     

<buildProviders>

         <add extension=”.foo” type=”System.Web.Compilation.PageBuildProvider” />

</buildProviders>

The complete <compilation tag should look similar to the following:

<compilation debug=”false” strict=”false” explicit=”true”>

         <buildProviders>

                  <add extension=”.foo” type=”System.Web.Compilation.PageBuildProvider” />

         </buildProviders>

</compilation>

6. Add a new web form to the page (probably easiest to stick with single file pages for this), add controls, etc., and when you’re finished with the page, rename the extension to the one you configured in IIS.

7. Browse with IIS to test.

Create a SQL Connection Stringusing text file

1. On the computer that requires the connection string, create a new file with a file extension of .udl.
   1. To perform this task, you will have to be viewing file extensions. If you are unsure how to do that, seeHow To: View File Name Extensions.
   2. Create a new text file and then rename the three letter file extension .txt to .udl.
      • For example, if you create a file named ConnectionString.txt, just rename it to ConnectionString.udl.
      • The rest of these steps will assume that the file is actually named ConnectionString.udl. If you created another file name with a .udl file extension, that is fine, just substitute the appropriate name as needed in the following instructions.
2. Right-click ConnectionString.udl that you just created and then click Properties.
3. On the Connection tab, fill out the connection properties according to the server, authentication type, and database name that you need. This is typically something you would already know, but if you do not, you may have to contact the database administrator or go look at the database connection properties yourself. If you need help with that, check out the Server Management How To Pages  .
4.  Click Test Connection. Hopefully it will succeed. If not, check the credentials, authentication type, and any firewalls (How to: Configure a Windows Firewall for Database Engine Access  ) between servers.   
5. Click OK.
6. Open the url file and inside you will find the connection string. For example, Provider=SQLOLEDB.1;Integrated Security=SSPI;Persist Security Info=False;InitialCatalog=FIMCertificateManagement;Data Source=FIMDC1 (as shown in the following figure).
7. Remove Provider portion of the string. Using the example above, the connection string for the application would be: Integrated Security=SSPI;Persist Security Info=False;InitialCatalog=FIMCertificateManagement;Data Source=FIMDC1 

Difference between non unicode and unicode in sql server

Non-Unicode	Unicode
(char, varchar, text)	(nchar, nvarchar, ntext)
Stores data in fixed or variable length	Same as non-Unicode
char: data is padded with blanks to fill the field size. For example, if a char(10) field contains 5 characters the system will pad it with 5 blanks	nchar: same as char
varchar: stores actual value and does not pad with blanks	nvarchar: same as varchar
requires 1 byte of storage	requires 2 bytes of storage
char and varchar: can store up to 8000 characters	nchar and nvarchar: can store up to 4000 characters
Best suited for US English: "One problem with data types that use 1 byte to encode each character is that the data type can only represent 256 different characters. This forces multiple encoding specifications (or code pages) for different alphabets such as European alphabets, which are relatively small. It is also impossible to handle systems such as the Japanese Kanji or Korean Hangul alphabets that have thousands of characters."1	Best suited for systems that need to support at least one foreign language: "The Unicode specification defines a single encoding scheme for most characters widely used in businesses around the world. All computers consistently translate the bit patterns in Unicode data into characters using the single Unicode specification. This ensures that the same bit pattern is always converted to the same character on all computers. Data can be freely transferred from one database or computer to another without concern that the receiving system will translate the bit patterns into characters incorrectly.