I currently have an ASP Classic script that runs every 15 minutes (via scheduled task). The task is responsibly for opening up Internet Explorer and loading the create report ASP page. Once the page is done loading, I have Javascript at the bottom of the page responsible for closing the IE window. We often run into issues where the script will hang for whatever reason and not reach the end. Thus, we end up with multiple IE instances at the end of the day. However, generating report in this manner seems very clunky and unnatural. I am using IIS and switching over to .NET.
Would anyone have any alternatives?
Thank you.
Why don't you just call your ASP page using a plain XmlHttpRequest script in vbscript, instead of running Internet Explorer?
Set http = CreateObject("Microsoft.XmlHttp")
http.open "GET", "http://yourserver/yourReportPage.asp", FALSE
http.send ""
Dim content
content = http.ResponseText
set http = nothing
Use this instead of calling IE.
Now, there may be better way to generate the reports, but at least this way you get rid of the scary IE automation.
We use SQL Reporting Services for this very purpose. We used to have a system very similar to yours, but haven't had any problems since migrating to RS.
Does it have to be called through the HTTP interface? That is, can you make a command-line project that does the same thing? If you can, you can easily set up a scheduled task to call the command-line app every 15 minutes.
Something that needs to run on a regular schedule seems like it would be related to a database. If that's the check out SQL Server Agent (presuming SQL Server) and store your results into a table that can be queried quickly from the ASP page.
Related
I don't know ASP, I've just started working for a large corporation and had task with an asp-classic web app dumped in my lap and it doesn't work. No one knows anything about it and apparently I am not allowed to write to IIS log files. So far it would seem that the program is failing because as far as I can tell, the POSTed HTTP parameters, which I can see in IE developer console, being sent in never make it to the server and can not be found in its Request.Form. Does anyone know what to make of that and how I might be able to print out the Response.QueryString where I might have access to it?
Clarifications:
I can see the log files but I can not add my own debugging lines as I am used to with PHP and Apache on Linux. I'm a fish out of water.
Proof the program is failing is that there is a program called ASPXTOASP.ASP which I think turns .Net request parameters into classic parameters is breaking. It gets an index out of bounds exception and I think it's because it is being passed an empty query string. When I tried to write the query string somewhere it never showed up. Where might I be able to write this query string where I can view it?
I am not certain I know enough about all of the components of the web app to organize it into a working version on my desktop for debugging.
I've just used Response.Write and Response.End to write the Request.QueryString to the screen. It's empty. Based on this and the fact that the program immediately preceding the one that breaks is called login.aspx and consists of setting some EVs haing to do with AD authentication I think my issue must be an authentication configuration issue. We are using Active Directory for authentication. Could anyone tell me about any specific settings in IIS that I ask the admins/senior dev to poke at which might fix such an issue?
A couple of ideas to help you debug:
1) If you're debugging this on the live site, you could output all of the Request.Form values into an HTML comment so that your users aren't affected.
<!-- <%
dim key
for each key in Request.Form
Response.Write key & "=" & Request.Form(key) & vbCrLf
next
%> -->
2) If you can debug the web app on your computer using Visual Studio, see this answer for how to debug ASP.
Based on the feedback I've received, the best solution to troubleshoot the application was to try to print the query string to the browser and then stop the program. To do this, I wrote something like this:
Response.Write("Query String: " & Request.QueryString)
Response.End
Ultimately this led me to discover that my parameters had disappeared. The query string is empty. I supposed I'll now need to read Questions about disappearing HTTP parameters.
I have alway tested/debugged my web applications by using f5 to "Start Debugging". Recently (yesterday) I have begun to start without debugging then attach the debugger to the webdev process if I needed to set breakpoints or anything. So far I haven't noticed much of a performance increase when not using the debugger. I am curious about how others save time when running locally. Is it a good idea to only attach the debugger when I need it? Any other options are welcome as well! Thanks!
I don't think you are going to see much of a performance increase. But if you do find yourself frequently attaching to a process manually, you can set up a macro to attach the debugger to whatever process you want to attach to, and then assign the macro to a button or hotkey. I used to do this when debugging old classic asp code, to set up the debugger to attach to IIS.
You can use record macro to create the macro, and then manually edit it if you need to make it more flexible.
Here is a macro I found online you could try as well:
http://weblogs.asp.net/koenv/archive/2008/02/14/quick-attach-and-detach-debugger.aspx
I used to debug like you (i.e. Host the Website in IIS an then attach the debugger) But i've found using Cassini far more productive because of the edit and continue feature, which is an absolute godsend.
iirc webdev == cassini
one other way is to run actual IIS - it's always on, even if you shut down VS, so it may be faster to come up. I am not sure it's actually faster when re-compiling, should be the same or faster. VS2010 supports IIS mode pretty well, plus you get the advantage of being able to test web.config properly, since cassini doesn't support system.webserver portion. We are switching to IIS mode due to url rewriter module, for example.
I have three Silverlight 3 applications in the same solution. In my asp.net hosting project I have a seperate page for all three projects. When I navigate between the pages, the only Silverlight breakpoints that get hit are the ones the initial page I load.
This problem has only started recently. I used to be able to debug between all silverlight projects at the same time. Any ideas? I have deleted the ClientBin folder, I have deleted all files and re-retrieved from source control. Nothing seems to be working.
"The problem has only started recently". What changed? Here are some guesses:-
You upgraded to Windows 7
You installed some more memory
Some other memory guzzling app is no longer running when you are testing.
By default IE8 will run multiple processes at least 2. One for the browser frame and one for the content of the intial tab. As you open more windows and tabs IE may add new processes to the set it is currently using.
When you debug VS will launch an new IE8 session and will attach to the process handling the content of the single tab that is open, (it doesn't bother attaching to the parent frame process). However as you navigate about your application IE8 will start new process that VS won't be attached to. This forces you to open the Attach to Process dialog and do it manually.
You can control this IE8 feature (called BTW LCIE, Loosely Coupled IE) from the Registry.
In the Key HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main add a new DWORD value TabProcGrowth. Set its value to 1. Now IE8 will only ever create 2 processes per session one for the frame and one for all the tab and window contents which is the one the VS will attach to.
This perhaps is a bit draconian if you also use IE8 as your general browser. One option is to leave IE8 for test purposes and use another browser for general browsing. Another option is a variation of the above. Instead of creating TabProcGrowth as a DWORD create it as a string type instead and set is value to "small". In this mode IE8 is much less aggressive in the number of processes it will open. Of course you could create a couple of scripts to create and delete the registry entry.
Note without the registry entry IE8 uses its own hueristics that depends on available memory etc to determine if a new process is warrented or not. This might explain why in the past your debugging worked and that for apparently no reason it stopped working.
Here was the issue:
One of my child windows had a Silverlight that calling a .Net Ria Service. The service call ended in an error.
The next time several I debugged, the debugger did not attach to the child windows. I had to attach to the child windows manually.
I fixed the Ria Service call so that it did not end in an error. And had to manually attach to the child windows in that debugging session. However in subsequent debugging sessions, the debugger automatically attached.
I tried breaking the Ria Service call and I had to manually attache again. What is a little weird is that closing Visual Studio and even rebooting the machine does not make Visual Studio automatically attach again. You have to have a debugging session where the child window make a sucessful call to a Ria Service to fix it.
NOTE:
The RIA error that was breaking my debugger was caused by a misspelled include in the domain query (ie...
return Context.SOME_ENTITY.Include("Misspelled_Association_Property");
) not all RIA exceptions cause this problem.
My scenario has a number of specific cases that I will go over. I don't have all the things handy to test a more general scenario, but I will when I finish my project unless someone does this first.
Here is what I have:
I am using the a LinqToEntitiesDomainService from the July 2009 Preview release of .Net RIA Services.
To complicate things a little more, since my application is using an Oracle backend, I am using DevArt's dotConnect Entities provider as the EntityFramework model for my domain service.
When I get time, I will try this on the Nov 2009 RIA and a standard SQL backend and EF to see if I still have the same issue. If this is the case I will report it to Microsoft as a visual studio bug.
Trying to print an ASP.NET Charting control behind the scenes in my web app. I think it is a permissions issue with the printer as everything is ok up until the point where my code calls:
chart.Printing.Print(false);
bool finished = false;
while (!finished)
{
finished = File.Exists(settings.GetValue("statusfile")); // file which indicates document was printed
System.Threading.Thread.Sleep(1000);
}
At this point the page just freezes (or continues to load endlessly - infinite loop!) Understandably this is happening because I am 100% relying on the document being printed. I do intend to add a timeout, however, at the moment I am just trying to figure out why exactly the document is never being set to the printer!
I have given the account (which the AppPool is running under) permissions to all the relevant folders and even the pdf printer itself...Still nothing.
Am I missing something? Is there any issues with printing on the server side via ASP.NET? I have encountered some issues doing this via WindowsServices in the past not sure if it is a similar problem with ASP.NET websites.
Update
As suggested I updated the AppPool to give myself (admin) permissions and it is the same issue. So by the looks of things the job is never being sent to the printer. I can't seem to figure out why though...
Probably should have mentioned this in my original post....but I am invoking the printer through a referenced DLL, this code is not being called directly from my application (incase it matters). Also this runs fine on my Development machine which is running Windows 7 IIS7.0 where as the server is running Windows 2003 server with IIS6.0.
Update 2
I removed the while loop and just left in the chart.Printing.Print(false) line and turns out the document IS being sent to the printer. So the issue must be with the settings file not getting written which is why the loop never breaks out!
To isolate if this is indeed a permissions issue, you could try running the application using the Visual Studio web development server, which will run under your credentials. Or if that's not an option, temporarily change the IIS app pool so it uses your credentials. If things still do not work, you may have another issue. I'm not sure which charting library you're using (is it the newish Microsoft one?), but maybe Print wants to show a printer dialog.
I have deployed an application written in ASP.NET 2.0 into production and it's experiencing some latency issues. Pages are taking about 4-5 seconds to load. GridView refreshing are taking around the same time to load.
The app runs fine on the develpment box. I did the following investigation on the server
Checked the available memory ... 80% used.
Cheched the processor ... 1%
Checked disk IO from perfmon, less than 15%
The server config is
Windows Server 2003 Sp2
Dual 2.0 GZH
2GB RAM
Running SQL Server 2005 and IIS only
Is there anything else I can troubleshoot? I also checked the event log for errors, it's clean.
EDITED ~ The only difference I just picked up is on the DEV box I am using IE7 and the clients are using IE6 - Could this be an issue?
UPDATE ~ I updated all clients to IE8 and noticed a 30% increase in the performance. I finally found out I left my debug=true in the web.config file. Setting that to flase got the app back to the stable performance... I still can't believe I did that.
First thing I would do is enable tracing. (see: https://web.archive.org/web/20210324184141/http://www.4guysfromrolla.com/webtech/081501-1.shtml)
then add tracing points to your page generation code to give you an idea of how long each part of the page build takes:
System.Diagnostics.Trace.Write(
"Starting Page init",
"TraceCheck");
//Init page
System.Diagnostics.Trace.Write(
"End Page init",
"TraceCheck");
System.Diagnostics.Trace.Write(
"Starting Data Fetch",
"TraceCheck");
//Get Data
System.Diagnostics.Trace.Write(
"End Data Fetch",
"TraceCheck");
etc
this way you can see exactly how long each stage is taking and then target that area.
Double check that you application is not running in debug mode. In your web.config file check that the debug attribute under system.web\compilation is set to false.
Besides making the application run slower and using more system memory you will also experience slow page loading since noting is cached when in debug mode.
Also check your page size. A developer friend of mine once loaded an entire table into viewstate. A 12 megabyte page will slip by when developing on your local machine, but becomes immediately noticeable in production.
Are you running against the same SQL Server as in your tests or a different one?
In order to find out where the time's coming from you could add some trace statements to your page load, and then load the page with tracing turned on. That might help point to the problem.
Also, what are the specs of your development box? The same?
Depending on the version of visual studio you have, Team Developer has a Performance Wizard you might want to investigate.
Also, if you use IE 8, it has a Profiler which will let you see how long the site takes to load in the browser itself. One of the first things to determine is whether the time is client side or server side.
If client side, start looking at what javascript you have and optimize / get rid of it.
If server side, you need to look at all of the performance counters (perfmon). For example, we had an app that crawled on the production servers due to a tremendous amount of JIT going on.
You also need to look at the communication between the web and database server. How long are queries taking? Are the boxes thrashing the disk drives? etc.