OK, So I have recently moved into the world of Web development after spending quite a few years coding in a pretty simple proprietary language, and one of my first jobs is to tweak an old classic ASP page for one of our clients.
I'm using Visual Studio 2008 to try debug some problems I am having, but the page won't load at all. If I browse the site locally using IIS, then everything works without any trouble at all, so I am not sure what I am doing wrong.
Here's the error message I get;
Compiler Error Message: BC30451: Name 'VariableName' is not declared.
The way this is setup, is that file1.asp has an include for file2.asp
<!-- #include file=./includes/file2.asp -->
Then file2.asp has a form post for file3.asp
<FORM METHOD="POST" ACTION="/includes/file3.asp">
Inside file3.asp is where the variable is created.
So, when running this site via IIS, everything works, the variables look to be passed between files without any trouble, but when I try to debug the site using VS2008, I get the BC30451 error code.
Can anyone right my ship? I've been doing a lot of googling and reading of other websites that seem to deal with this issue, but a lot of it is going over my head.
If anyone could please take the time to explain what & why this is happening, as well as providing some kind of solution, or pointing me in the direction of somewhere that may be able to help, it would be more than greatly appreciated.
Cheers,
Pat.
You can debug classic ASP in Visual Studio 2008. The way to do it involves attaching the debugger to the process that is running your ASP pages. Keeping in mind that Classic ASP debugging only works with IIS; it does not work with the VS Development Web Server (Cassini). Also, make sure that you have enabled ASP debugging in IIS:
IIS Home Directory Properties http://img4.imageshack.us/img4/6431/capturert.png
IIS Application Configuration http://img26.imageshack.us/img26/4802/capture2qr.png
Once you have the configuration in IIS as noted above, here is how to attach the debugger:
Open the Classic ASP files in Visual Studio
Set a breakpoint anywhere you want to break in the server-side code
View the page in a web browser (ensures that the host process is running)
In Visual Studio: Debug Menu -> Attach to Process
Locate the IIS ASP worker process (w3wp.exe on IIS6, dllhost.exe on IIS5.1)
Attach to the script code for the host process (see below for example)
Attach Debugger Dialog http://img43.imageshack.us/img43/2218/capturegb.png
At this point, the breakpoint should bind and you should be able to debug the Classic ASP pages. (you may have to refresh the page in the web browser to get the code to execute again once the debugger has been attached)
I've never tried to run classic ASP in VS2008. But it is not a compiled language, and I don't think you can run a debugger on it. When I did ASP, I just did a bunch of Response.Write to debug.
Related
I'm having a bit of problem debugging in VS for our web application, basically all requests are painfully slow, requests that used to take <1s are taking over 15s which as you can imagine makes developing a nightmare!
This is on my newly installed laptop (done it twice recently and the problem is the same both times on both laptops).
I've tried the following without success:
Run without debugging (ctrl+F5)
Run in release mode
Disable diagnostics panel in VS
Disable unused debugging options in VS
Different browsers (Chrome, FF, Edge)
Disable Antivirus
Disable ReSharper/Uninstalled
The solution is a mix of WebForms, MVC, WebAPI, Classic ASP with standard SQL connections (calling stored procs) and Entity Framework.
I have also tried Visual Studio 2017 and I'm getting the same issue there too.
Does anyone have any idea what could be causing it? I've googled and tried several things people have suggested without any success.
It turns out that the issue was down to have the Data Source value of the connection string set to (local), where as on my old laptop I know that in some instances this was set to the computer name.
I'm not sure which connection string was a fault as we have several in a fair few config files (about 20 connection strings in total) and I just changed them all.
However I'm still unsure why there is a noticeable difference in using computer name and (local) in this situation.
Every time I build my solution and try to start debugging, I get this message:
Unable to start debugging on the web server. The web server did not respond on a timely manner. This maybe another debugger is attached to the web server.
If I restart my IIS, I can start debugging but If I build again I have to restart my IIS again. I saw several people having same issue but no one same as mine exactly.
Open your cmd in administrator mode and run cmd
iisreset
The below link contain some useful answers:
Unable to start debugging on the web server. Could not start ASP.NET debugging VS 2010, II7, Win 7 x64
Like this answer:
1)
Try going to IIS and checking to make sure the App Pool you are using
is started. A lot of times, you will produce an error that shuts down
the app pool. You just need to right click and Start and you should be
good to go.
2) And this answer
Turns out that the culprit was the IIS Url Rewrite module. I had
defined a rule that redirected calls to Default.aspx (which was set as
the start page of the web site) to the root of the site so that I
could have a canonical home URL. However, apparently VS had a problem
with this and got confused. This problem did not happen when I was
using Helicon ISAPI_Rewrite so it didn't even occur to me to check.
I ended up creating a whole new web site from scratch and porting
projects/files over little by little into my solution and rebuilding
my web.config until I found this out! Well, at least now I have a
slightly cleaner site using .NET 4.0 (so far, hopefully I won't run
into any walls)--but what a pain!
WkHtmlToXSharp is C# wrapper (using P/Invoke) for the excelent Html to PDF conversion library wkhtmltopdf library. https://github.com/TobiTonner/WkHtmlToXSharp
I have two websites on staging Windows Server 2008 R2 x64 environment
One of them let say web site A version of website and another one web site B.
The WkHtmlToXSharp conversion was working on the A version but when I set up an B version an conversion not working on that version, I am getting an error:
HtmlToPdf conversion failed: Failed loading page http://website/Convert (sometimes it will work just to ignore this error with --load-error-handling ignore)
I was wondering why it is happening and than I pointed A website to look in to the the same folder as B site is looking. And I was surprised that when I am running A conversion working well there, but when I am ruining B I am still getting the same error, but the funny thing is that both of sites pointed to the same source code(folder). I am just wondering why it is happend. Both websites has the similar app pool configurations and Enable 32-bit apps set too true in bot of them. Also i was trying to set the same app pool for both websites and still the same thing taking place, conversion on site A is working but on B site is not.
On my local environment(Windows 7 x64) if I set the same websites conversions working in both cases.
Also I made some changes in code to ignore the errors :
converter.ObjectSettings.Load.LoadErrorHandling = LoadErrorHandlingType.ignore;
but it is does not fix the error, only the difference is that now I am getting empty pdf in case of conversion on B web site.
I just thinking may be it is something in Windows Server which deny to run/keep in memory two copies of WkHtmlToXSharp.dll or wkhtmltopdf or something kind of like that is going on.
Maybe some one have any ideas about that?
See this https://github.com/pruiz/WkHtmlToXSharp/issues/8
The problem with IIS is that it recycles app. pools from time to time,
but during this process any non-managed resources hold by your
application may (as in this case) end up not being appropiatelly
freed. Also, having more than one AppDomain under you'r IIS
application can cause memory corruption, as both AppDomains try to
instantiante a WebKit instance under the same process (ie. same
process memory/space), and that's another no-way.
The best thing you can do is having a Daemon or Service handling
HTML2PDF conversión, and calling it from your web app. using remoting,
WS calls, or any other RPC method. This will also help you de-compose
your application and making things easier to debug.
Hope it helps.
Using Visual Studio 2010 on Window 7 64bit. I'm trying to test a website project (not a web application project) using the built in dev server (cassini). The problem I'm having is that when I make a change, I now have to actually stop debugging, kill cassini, and restart before I can actually see my changes in the browser. I used to be able to edit and refresh. One of my fellow developers here is able to do this just fine with an identical setup (same project/vs version/os - and settings near as I can tell). I'm beginning to suspect some sort of permissions issue. I've been all over google trying to find an answer to no avail. Any ideas?
As it turns out, this was my fault... I had experienced the dreaded "network BIOS command limit has been reached" issue. I found a post that recommended doing a regedit hack "HKLM\Software\Microsoft\ASP.NET\FCNMode = 1", well this basically turns off File Change Notifications. Changing this value to 2, and applying the changes recommended in knowledge base 810886 fixed both problems.
I have a asp.net 3.5 web application which is deployed on server 2003 and IIS 6. After running fine for a few weeks it goes "Down" and by down I mean that when I try and access it the browser looks like it's loading but never actually serves the page. After an IIS reset it loads quickly again.
My question is what are the steps and tools I should use in tracking the root cause?
First point of interest would be the event viewer, second the iis logs. If you still do not find the error then performance counters could help you out there.