Seems like I'm always having problems debugging javascript on my development machine so today I decided to try and get to the bottom of the issue. (...well, that and I have nothing to do)
I've gone through all the usual recommendations on the web.... turn off "Disable javascript debugging" on IE; turn on script debugging in visual studio; turn on script debugging in IIS 7.0. All are required but still didnt seem to allow the debugger to break into the script.
As it turns out, my problem only showed when I used the Page.RegisterStartupScript method... loading my scripts via the code-behind. Reverting back to the original html include statements fixed everything. Not sure what was going on here... I did a little bit more investigation but nothing conclusive.
Before (Mainpage.cs):
public void OnInit()
{
string js = ReadResourceString("includescript.js");
ClientScript.RegisterStartupScript(typeof(Page), "UIScriptHelper", js);
}
After (Mainpage.aspx):
...
<head>
<script type="text/javascript" src="includescript.js"/>
/head>
Tuesday, October 23, 2007
Thursday, October 18, 2007
useDefaultWebProxy causing problems when calling the WCF service
Problem:
When my web application was running we would occassionally get timeouts when the client tried to contact the service. Resetting IIS would solve the problem, but obviously that is not a desired solution.
Solution:
Set useDefaultWebProxy=false from httpTransport element of the app.config or web.config. For some reason, when this setting was set to true the client would have problems sending requests that were executed rapidly in succession. This would cause a problem in the UI when two independent users sent requests near the same time.
When my web application was running we would occassionally get timeouts when the client tried to contact the service. Resetting IIS would solve the problem, but obviously that is not a desired solution.
Solution:
Set useDefaultWebProxy=false from httpTransport element of the app.config or web.config. For some reason, when this setting was set to true the client would have problems sending requests that were executed rapidly in succession. This would cause a problem in the UI when two independent users sent requests near the same time.
Tuesday, April 3, 2007
Using Partials to extend the functionality of a DataTable
I've just discovered a really slick way to access data that is related to the row you are working with in a DataTable.
Previously, if I was working with data with one table (lets say Employees) and I wanted to find all the orders with a particular employee, I would go about it something like this:
EmployeesTableAdapter eta = new EmployeesTableAdapter();
EmployeesDataTable edt = pta.GetEmployee();
foreach (EmployeesRow er in edt)
{
if(er.Name == "George")
{
//do our work with the orders data
}
}
The cool thing about the code generated is that the class information is created as partial classes. With the use of partial classes, we can extend the partial class in our own code and as such, extend the functionality that is available for a particular row.
public partial class SuppliersRow
{
public EmployeesDataTable GetEmployeesOrders()
{
OrdersTableAdapter ota = new OrdersTableAdapter();
return ota.GetOrdersByEmployeeID(this.EmployeeID);
}
}
With the functionality extended, we can have the row we are working with be responsible for retrieving the data associated with that row.
foreach (EmployeesRow er in edt)
{
if(er.Name == "George")
{
//do our work with the orders data
}
}
Previously, if I was working with data with one table (lets say Employees) and I wanted to find all the orders with a particular employee, I would go about it something like this:
EmployeesTableAdapter eta = new EmployeesTableAdapter();
EmployeesDataTable edt = pta.GetEmployee();
foreach (EmployeesRow er in edt)
{
if(er.Name == "George")
{
//do our work with the orders data
}
}
The cool thing about the code generated is that the class information is created as partial classes. With the use of partial classes, we can extend the partial class in our own code and as such, extend the functionality that is available for a particular row.
public partial class SuppliersRow
{
public EmployeesDataTable GetEmployeesOrders()
{
OrdersTableAdapter ota = new OrdersTableAdapter();
return ota.GetOrdersByEmployeeID(this.EmployeeID);
}
}
With the functionality extended, we can have the row we are working with be responsible for retrieving the data associated with that row.
foreach (EmployeesRow er in edt)
{
if(er.Name == "George")
{
//do our work with the orders data
}
}
Monday, February 12, 2007
Debug timeout with IIS 7.0 and App pools
I've been having problems debugging my web applications for the past month or so after I upgraded to vista.
Problem:
When my application was broken into the debugger, after ~90 seconds, the debugger would stop working and I would have to restart it.
Looking into the eventlog, I found the following notices:
A process serving application pool ''failed to respond to a ping. The process id was '5472'.
Source of the Problem:
IIS has a setting for application pools that allows it to monitor the health of the process. When the process doesnt respond to a ping request (as in debug mode), IIS kills the process and therefore kills the debug session.
Solution:
1. Open IIS
2. Open the Advanced Settings for the application pool you are running under.
3. Find the setting "Ping Enabled" under "Process Model"
4. Change this to False.
Note: you could alternatively increase the Ping Maximum Response Time to a higher value.
Problem:
When my application was broken into the debugger, after ~90 seconds, the debugger would stop working and I would have to restart it.
Looking into the eventlog, I found the following notices:
A process serving application pool ''failed to respond to a ping. The process id was '5472'.
Source of the Problem:
IIS has a setting for application pools that allows it to monitor the health of the process. When the process doesnt respond to a ping request (as in debug mode), IIS kills the process and therefore kills the debug session.
Solution:
1. Open IIS
2. Open the Advanced Settings for the application pool you are running under.
3. Find the setting "Ping Enabled" under "Process Model"
4. Change this to False.
Note: you could alternatively increase the Ping Maximum Response Time to a higher value.
Subscribe to:
Posts (Atom)
