1. Select the site from IIS
2. Click "Error pages"
3. Select the error for which you want more details
4. Right click then "Edit feature settings"
5. Select detailed errors
Don't forget to reset after debugging.
Technical Blog
Tuesday, November 9, 2010
IIS 7.0 / 7.5 : How to switch between the 32-bit versions and the 64-bit version of ASP.NET 2.0 on a 64-bit version of Windows
Basically, go into your IIS 7 manager console, find the application pool your app is running in, right-click on it, go to Advanced Settings, and change the Enable 32-bit Applications setting to true.
Now restart IIS.
Now restart IIS.
Tuesday, November 2, 2010
JQuery selector for checked CheckBoxes in a repeater
<div class="checkGroup">
<asp:Repeater ID="list" OnItemDataBound="OnPopulate" runat="server">
<ItemTemplate>
<asp:CheckBox ID="checkBox" runat="server" />
</ItemTemplate>
</asp:Repeater>
</div>
This will return all checked checkbox :
$(".checkGroup INPUT[type='checkbox']:checked")
<asp:Repeater ID="list" OnItemDataBound="OnPopulate" runat="server">
<ItemTemplate>
<asp:CheckBox ID="checkBox" runat="server" />
</ItemTemplate>
</asp:Repeater>
</div>
This will return all checked checkbox :
$(".checkGroup INPUT[type='checkbox']:checked")
Monday, July 5, 2010
Simulate Form Post with HttpRequest
string postData = "Email=test@email.be";
System.Text.ASCIIEncoding encoding = new System.Text.ASCIIEncoding();
byte[] data = encoding.GetBytes(postData);
System.Net.HttpWebRequest request = (System.Net.HttpWebRequest)System.Net.WebRequest.Create("http://www.posturl.com");
request.Method = "POST";
request.ContentType = "application/x-www-form-urlencoded";
request.ContentLength = data.Length;
System.IO.Stream newStream = request.GetRequestStream();
newStream.Write(data, 0, data.Length);
newStream.Close();
System.Text.ASCIIEncoding encoding = new System.Text.ASCIIEncoding();
byte[] data = encoding.GetBytes(postData);
System.Net.HttpWebRequest request = (System.Net.HttpWebRequest)System.Net.WebRequest.Create("http://www.posturl.com");
request.Method = "POST";
request.ContentType = "application/x-www-form-urlencoded";
request.ContentLength = data.Length;
System.IO.Stream newStream = request.GetRequestStream();
newStream.Write(data, 0, data.Length);
newStream.Close();
Tuesday, June 1, 2010
Solve conflict between JQuery and third party plugins
I recently had a problem with JQuery-UI (tabs) and JQuery Tools (scrollable) on a same page.
We can read on the web that this could be solved by generating a custom JQuery Tools script without tabs feature because the problem would be due to the fact that both script contains tabs feature. For me, that didn't solve the problem.
I solve my problem with the following method :
<html>
<head>
/* First include the third party script (example) */
<script type="text/javascript" src="js/jquery.tools.min.js"></script>
/* Then include JQuery and JQuery UI */
<script type="text/javascript" src="js/jquery.min.js"></script>
<script type="text/javascript" src="js/jquery-ui.min.js"></script>
</head>
<body>
<script type="text/javascript">
$.noConflict();
jQuery(document).ready(function($)
{
// Code that uses jQuery's $ can follow here.
...
});
// Code that uses other library's $ can follow here.
$(function()
{
...
});
</script>
</body>
</_html>
We can read on the web that this could be solved by generating a custom JQuery Tools script without tabs feature because the problem would be due to the fact that both script contains tabs feature. For me, that didn't solve the problem.
I solve my problem with the following method :
<html>
<head>
/* First include the third party script (example) */
<script type="text/javascript" src="js/jquery.tools.min.js"></script>
/* Then include JQuery and JQuery UI */
<script type="text/javascript" src="js/jquery.min.js"></script>
<script type="text/javascript" src="js/jquery-ui.min.js"></script>
</head>
<body>
<script type="text/javascript">
$.noConflict();
jQuery(document).ready(function($)
{
// Code that uses jQuery's $ can follow here.
...
});
// Code that uses other library's $ can follow here.
$(function()
{
...
});
</script>
</body>
</_html>
Monday, May 10, 2010
Fix the GroupName bug in FrameWork .NET with RadioButton in a repeater
Javascript method to add (From ASPX page)
function SetUniqueRadioButton(nameregex, current)
{
re = new RegExp(nameregex);
for(i = 0; i < document.forms[0].elements.length; i++)
{
elm = document.forms[0].elements[i]
if (elm.type == 'radio')
{
if (re.test(elm.name))
{
elm.checked = false;
}
}
}
current.checked = true;
}
Event to add to the RadioButton (from Code Behind)
coregValue.Attributes["onclick"] = "SetUniqueRadioButton('repeaterID.*GroupName', this);";
function SetUniqueRadioButton(nameregex, current)
{
re = new RegExp(nameregex);
for(i = 0; i < document.forms[0].elements.length; i++)
{
elm = document.forms[0].elements[i]
if (elm.type == 'radio')
{
if (re.test(elm.name))
{
elm.checked = false;
}
}
}
current.checked = true;
}
Event to add to the RadioButton (from Code Behind)
coregValue.Attributes["onclick"] = "SetUniqueRadioButton('repeaterID.*GroupName', this);";
Monday, May 3, 2010
Increase debugging time with IIS 7
When you are debugging, IIS will not service any other requests until you are done stepping through your code. That includes the "ping" request that IIS sends to itself. Since IIS doesn't hear back from itself, it decides to shut itself down, which promptly terminates your debugging.
The solution is to increase the Ping Maximum Response Time in the application pool settings from its default value of 90 seconds. Set it to something high enough that will give you enough time to debug your code (like maybe 300 seconds).
Microsoft has a long-winded write-up here, or you can just look at the pretty picture.
--
Edit: Others have suggested setting "Ping Enabled" to false. There are several reasons why I prefer to keep it in place, just with a larger interval, but the most important is that you will (most likely) have worker processing pinging enabled on production, and you should strive to develop and debug under a configuration that is as close to production as possible. If you do NOT have ping enabled on production, then by all means disable it locally as well.
The solution is to increase the Ping Maximum Response Time in the application pool settings from its default value of 90 seconds. Set it to something high enough that will give you enough time to debug your code (like maybe 300 seconds).
Microsoft has a long-winded write-up here, or you can just look at the pretty picture.
--
Edit: Others have suggested setting "Ping Enabled" to false. There are several reasons why I prefer to keep it in place, just with a larger interval, but the most important is that you will (most likely) have worker processing pinging enabled on production, and you should strive to develop and debug under a configuration that is as close to production as possible. If you do NOT have ping enabled on production, then by all means disable it locally as well.
Friday, March 12, 2010
Configuring Remote SQL Connections
Enable remote connections for SQL Server 2005 Express or SQL Server 2005 Developer Edition
You must enable remote connections for each instance of SQL Server 2005 that you want to connect to from a remote computer. To do this, follow these steps:
Click Start, point to Programs, point to Microsoft SQL Server 2005, point to Configuration Tools, and then click SQL Server Surface Area Configuration.
On the SQL Server 2005 Surface Area Configuration page, click Surface Area Configuration for Services and Connections.
On the Surface Area Configuration for Services and Connections page, expand Database Engine, click Remote Connections, click Local and remote connections, click the appropriate protocol to enable for your environment, and then click Apply.
Note Click OK when you receive the following message:
Changes to Connection Settings will not take effect until you restart the Database Engine service.
On the Surface Area Configuration for Services and Connections page, expand Database Engine, click Service, click Stop, wait until the MSSQLSERVER service stops, and then click Start to restart the MSSQLSERVER service
Configure a Server to Listen on a Specific TCP Port (SQL Server Configuration Manager)
If enabled, the default instance of the SQL Server Database Engine listens on TCP port 1433. Named instances of the Database Engine and SQL Server Compact 3.5 SP1 are configured for dynamic ports. This means they select an available port when the SQL Server service is started. When you are connecting to a named instance through a firewall, configure the Database Engine to listen on a specific port, so that the appropriate port can be opened in the firewall.
To assign a TCP/IP port number to the SQL Server Database Engine
1. In SQL Server Configuration Manager, in the console pane, expand SQL Server Network Configuration, expand Protocols for, and then double-click TCP/IP.
2. In the TCP/IP Properties dialog box, on the IP Addresses tab, several IP addresses appear in the format IP1, IP2, up to IPAll. One of these is for the IP address of the loopback adapter, 127.0.0.1. Additional IP addresses appear for each IP Address on the computer. Right-click each address, and then click Properties to identify the IP address that you want to configure.
3. If the TCP Dynamic Ports dialog box contains 0, indicating the Database Engine is listening on dynamic ports, delete the 0.
4. In the IPn Properties area box, in the TCP Port box, type the port number you want this IP address to listen on, and then click OK.
5. In the console pane, click SQL Server Services.
6. In the details pane, right-click SQL Server () and then click Restart, to stop and restart SQL Server.
Connecting to SQL Server over the Internet
If your client and server are connected to the Internet, you can use the Internet to connect to an instance of the Microsoft SQL Server Database Engine using SQL Server Management Studio or a client application based on OLE DB, or Open Database Connectivity (ODBC).
To share data over the Internet, you must use the TCP/IP Net-Libraries, and ensure that TCP/IP support is enabled. If the server is registered with Domain Name System (DNS), you can connect using its registered name.
Although an Internet connection is less secure than a Microsoft ISA Server connection, using a firewall or an encrypted connection, as described below, helps keep sensitive data secure.
Using a Firewall System with the SQL Server Database Engine
Many companies use a firewall system to isolate their networks from unauthorized access from the Internet. A firewall can be used to restrict access to your network by forwarding only requests targeted at specific TCP/IP addresses in the local network. Requests for all other network addresses are blocked by the firewall. You can allow Internet applications to access an instance of the SQL Server Database Engine in the local network by configuring the firewall to forward network requests that specify the network address of the instance of the Database Engine.
To work with a firewall, the instance of the Database Engine must listen on the network address that the firewall is configured to forward. A TCP/IP network address for SQL Server Database Engine consists of two parts: an IP address associated with one or more network cards in a computer, and a TCP port address specific to an instance of SQL Server. Default instances of the Database Engine use TCP port 1433 by default. Named instances, however, dynamically assign an unused TCP port number the first time the instance is started. The named instance can also dynamically change its TCP port address on a later startup if the original TCP port number is being used by another application. SQL Server only dynamically changes to an unused TCP port if the port it is currently listening on was itself dynamically selected; if a statically assigned port is in use by another application, SQL Server displays an error and continues to listen on other ports. It is unlikely, however, that another application would use 1433 since that port is a well-known registered address for the SQL Server Database Engine.
When using a named instance of Database Engine with a firewall, use SQL Server Configuration Manager to configure the named instance to listen on a specific TCP port. You must pick a TCP port that is not used by another application running on the same computer or cluster. For a list of well-known ports registered for use by various applications, go to the Internet Assigned Numbers Authority Web site at http://www.iana.org.
The network administrator should configure the firewall to forward communication to SQL Server for the IP address and TCP port that the instance of the Database Engine is listening on (either TCP port 1433 for a default instance, or the TCP port you configured for a named instance). Also, because Microsoft SQL Server uses UDP port 1434 to establish communications links from applications, have the network administrator configure the firewall to forward requests for UDP port 1434 on the same IP address. For more information about UDP port 1434, see SQL Server Browser Service.
For example, consider a computer running one default instance and two named instances of the SQL Server Database Engine. The computer is configured such that the network addresses that the three instances listen on all have the same IP address. The default instance would listen on TCP port 1433, while the other named instances could listen on TCP ports 1434 and 1954, respectively. The network administrator would then configure the firewall to forward network requests for UDP port 1434 and TCP ports 1433, 1434, and 1954 on that IP address.
You must enable remote connections for each instance of SQL Server 2005 that you want to connect to from a remote computer. To do this, follow these steps:
Click Start, point to Programs, point to Microsoft SQL Server 2005, point to Configuration Tools, and then click SQL Server Surface Area Configuration.
On the SQL Server 2005 Surface Area Configuration page, click Surface Area Configuration for Services and Connections.
On the Surface Area Configuration for Services and Connections page, expand Database Engine, click Remote Connections, click Local and remote connections, click the appropriate protocol to enable for your environment, and then click Apply.
Note Click OK when you receive the following message:
Changes to Connection Settings will not take effect until you restart the Database Engine service.
On the Surface Area Configuration for Services and Connections page, expand Database Engine, click Service, click Stop, wait until the MSSQLSERVER service stops, and then click Start to restart the MSSQLSERVER service
Configure a Server to Listen on a Specific TCP Port (SQL Server Configuration Manager)
If enabled, the default instance of the SQL Server Database Engine listens on TCP port 1433. Named instances of the Database Engine and SQL Server Compact 3.5 SP1 are configured for dynamic ports. This means they select an available port when the SQL Server service is started. When you are connecting to a named instance through a firewall, configure the Database Engine to listen on a specific port, so that the appropriate port can be opened in the firewall.
To assign a TCP/IP port number to the SQL Server Database Engine
1. In SQL Server Configuration Manager, in the console pane, expand SQL Server Network Configuration, expand Protocols for
2. In the TCP/IP Properties dialog box, on the IP Addresses tab, several IP addresses appear in the format IP1, IP2, up to IPAll. One of these is for the IP address of the loopback adapter, 127.0.0.1. Additional IP addresses appear for each IP Address on the computer. Right-click each address, and then click Properties to identify the IP address that you want to configure.
3. If the TCP Dynamic Ports dialog box contains 0, indicating the Database Engine is listening on dynamic ports, delete the 0.
4. In the IPn Properties area box, in the TCP Port box, type the port number you want this IP address to listen on, and then click OK.
5. In the console pane, click SQL Server Services.
6. In the details pane, right-click SQL Server (
Connecting to SQL Server over the Internet
If your client and server are connected to the Internet, you can use the Internet to connect to an instance of the Microsoft SQL Server Database Engine using SQL Server Management Studio or a client application based on OLE DB, or Open Database Connectivity (ODBC).
To share data over the Internet, you must use the TCP/IP Net-Libraries, and ensure that TCP/IP support is enabled. If the server is registered with Domain Name System (DNS), you can connect using its registered name.
Although an Internet connection is less secure than a Microsoft ISA Server connection, using a firewall or an encrypted connection, as described below, helps keep sensitive data secure.
Using a Firewall System with the SQL Server Database Engine
Many companies use a firewall system to isolate their networks from unauthorized access from the Internet. A firewall can be used to restrict access to your network by forwarding only requests targeted at specific TCP/IP addresses in the local network. Requests for all other network addresses are blocked by the firewall. You can allow Internet applications to access an instance of the SQL Server Database Engine in the local network by configuring the firewall to forward network requests that specify the network address of the instance of the Database Engine.
To work with a firewall, the instance of the Database Engine must listen on the network address that the firewall is configured to forward. A TCP/IP network address for SQL Server Database Engine consists of two parts: an IP address associated with one or more network cards in a computer, and a TCP port address specific to an instance of SQL Server. Default instances of the Database Engine use TCP port 1433 by default. Named instances, however, dynamically assign an unused TCP port number the first time the instance is started. The named instance can also dynamically change its TCP port address on a later startup if the original TCP port number is being used by another application. SQL Server only dynamically changes to an unused TCP port if the port it is currently listening on was itself dynamically selected; if a statically assigned port is in use by another application, SQL Server displays an error and continues to listen on other ports. It is unlikely, however, that another application would use 1433 since that port is a well-known registered address for the SQL Server Database Engine.
When using a named instance of Database Engine with a firewall, use SQL Server Configuration Manager to configure the named instance to listen on a specific TCP port. You must pick a TCP port that is not used by another application running on the same computer or cluster. For a list of well-known ports registered for use by various applications, go to the Internet Assigned Numbers Authority Web site at http://www.iana.org.
The network administrator should configure the firewall to forward communication to SQL Server for the IP address and TCP port that the instance of the Database Engine is listening on (either TCP port 1433 for a default instance, or the TCP port you configured for a named instance). Also, because Microsoft SQL Server uses UDP port 1434 to establish communications links from applications, have the network administrator configure the firewall to forward requests for UDP port 1434 on the same IP address. For more information about UDP port 1434, see SQL Server Browser Service.
For example, consider a computer running one default instance and two named instances of the SQL Server Database Engine. The computer is configured such that the network addresses that the three instances listen on all have the same IP address. The default instance would listen on TCP port 1433, while the other named instances could listen on TCP ports 1434 and 1954, respectively. The network administrator would then configure the firewall to forward network requests for UDP port 1434 and TCP ports 1433, 1434, and 1954 on that IP address.
Subscribe to:
Posts (Atom)