I maintain an Classic ASP intranet site. I've developed a new page in ASP.NET that has a link to it from the old site. I would like to use the INCLUDE from the intranet which puts a header with menus on each page. I get a compile error when I run the new page in the debugger. The INCLUDE file contains nested INCLUDE files. The error says it can't find the nested includes. It's looking for them in the C:\xxxxxx when the actual physical path is on the d:\ drive.
Apparently it's resolving the INCLUDE VIRTUAL for the top level include, because it's looking for the nested includes.
Why does it resolve the first include, finding it on the D:\ drive, but is looking for the nested includes on the C:\ drive?
here's the code for the top level include
< !--#include virtual="/includes/page2header.asp"-->
here's the code for the nested includes
< !-- #INCLUDE virtual="/inc/menustyles.txt" -->
< !-- #INCLUDE virtual="/inc/Config.asp" -->
The site is running on IIS 7.5.
The site is located on the server on the default website in a virtual directory in the path
D:\inetpub\wwwroot
The compiler is looking for the nested includes in this path with this error,
Could not find a part of the path 'C:\inetpub\wwwroot\inc\menustyles.txt'
Include files don't work in the same way in ASP.NET as they do in classic ASP. When you use the Include directive, it results in the file content being rendered as plain text in the ASP.NET page. You will have to take an ASP.NET route to solve your problem. Typically, User Controls are used to render snippets of reusable HTML.
See my article on this topic for more information: http://www.mikesdotnetting.com/Article/144/Classic-ASP-Include-Files-in-ASP.NET
The problem I was having here is I was running the debugger on my development machine, and it's virtual directory IS on the C:\ drive for this site, and the first level virtual file did exist in the path where the compiler was looking for it, and the nested files did not exist. The problem was solved when I copied the nested files into place on the development machine.
However, that raised a new problem. The nested files contain server side script, Classic ASP VBScript, and it just won't run in my ASP.NET page. This problem brings this effort to a dead end, unless someone can recommend how to solve this new problem.
Thanks, Bren
Related
I have no idea about asp, but I had to do some modifications in a web site, an easy modification. So I downloaded all files from server and I did all the modifications in Visual Studio 2013. Then I tested each page in the local host and it was perfect.
When I uploaded the files, I created a folder called "development", to tested it before I changed in the real site, so, my real site is for example "www.realsite.com" and my new folder is inside, with all the file, so I write in my url "www.realsite.com/development" and it shows the page, but not the one I had modified, but the real site. I want to know if there is a config file to change the path of the development site to see the changes I make and not the real site, because if I click in the development site a menu, it sends me to the page in the real site.
I hope you can help me with this,
Thank you!
PS: Do you know what is the meaning of "~/" in for example : src="~/folder/folder/xxxx.xx"
This is because the URLs in the project are using absolute paths, all pointing to the root. If they were using relative paths, moving the project to a folder and running it from there would work just file.
The difference:
... <-- absolute, note the leading slash
... <-- relative, no leading slash
Well, it depends on what kind of changes you are referring to, what kind of ASP.net site (or application).
The ~/ in ASP.Net means "path from application root". A subfolder (the new folder you created) in an existing application is just that, a folder. It is not "another application root". So if the existing code refers to "its root", e.g. where it uses ~/, it's probably not what you would expect..
Again, not enough info, but if you experience more unexpected behavior, it will probably be because of this (application scope).
Ref: ASP.NET Web Project Paths
ASP.NET includes the Web application root operator (~), which you can use when specifying a path in server controls. ASP.NET resolves the ~ operator to the root of the current application.
Hth...
I saw a similar question to this, but mine is slightly different:
I'm get intermittent results with #include files working on an IIS 7.5 server (R2008 V2). My includes are only working if they are in the same folder as the current .asp page, or in a subfolder of the current page. This is inconvenient, as I'd like to keep them all in a /lib subfolder, off of the main page.
My configuration: I have a folder named DCN, sitting right below the wwwroot folder. There are several files in a /lib folder within the DCN folder, so the absolute path is c:\inetpub\wwwroot\dcn\lib\my_include_file.asp. If I open an ASP page in the DCN folder, I can pull include files from the /lib subfolder. However, if I open an ASP page from the DCN/trouble folder (such as "DCN\Trouble\Search.asp"), and the search.asp page has a line that says:
<!--#include file="../lib/my_include_file.asp"-->
the include fails, and I get a 500 error.
I've also tried:
<!--#include file="/lib/my_include_file.asp"-->
with the same results. Same with:
<!--#include file="/DCN/lib/my_include_file.asp"-->
I changed the slashes to backslashes, with the same results. I even went so far as to try:
<!--#include file="c:\inetpub\wwwroot\dcn\lib\my_include_file.asp"-->
(out of sheer desparation), but am still getting the same results.
If I create a subfolder in the dcn\trouble folder, I can include files from it, but obviously, this is not ideal.
Any suggestions would be greatly appreciated. I can't help but think this is something trivial. Thanks in advance!
Yots is correct, it sounds like parent paths are turned off. If you can't get these turned on the use virtual paths instead:
Based on your question where you state that the include files are in /DCN/lib then do the following:
<!-- #include virtual="/DCN/lib/my_include_file.asp -->
When using virtual paths you must specify the full virtual path to the file i.e. from the root of the site. This isn't ideal if you're building your application in a subfolder on your development machine where you're using XP and then deploying into the root of a production machine. That said IIS7 on Vista or Windows 7 permits the creation of multiple sites now **.
When using a path type of File="...", filename must be on a relative path to the folder containing the #include. For example:
The directive <!-- #include file="my_include.asp" --> will include my_include.asp from the same folder.
The directive <!-- #include file="lib/my_include.asp" --> will include my_include.asp from the folder lib below the current folder where the script is running.
The directive <!-- #include file="../my_include.asp" --> will include my_include.asp from the folder lib above the current folder (the parent folder) where the script is running.
The directive <!-- #include file="../lib/my_include.asp" --> will include my_include.asp from the folder lib that is a child of the parent folder (or the current folder's sibling).
The last two examples won't work if parent paths are not enabled.
** I am aware there are hacks to enable multiple IIS sites in XP's IIS5.1.
I think your problem is that parent paths are disabled by default in IIS.
You have two options:
Using Virtual Paths
Enabling ASP Parent Paths on IIS
For details read this article from the IIS Website
http://learn.iis.net/page.aspx/566/classic-asp-parent-paths-are-disabled-by-default/
What about a #include virtual? if it reads:
#include virtual="\mysite\include\file.inc
it should find the file.inc in the include folder under mysite? I have enabled and disabled parent paths and tried about a million things. I still receive an asp 0126 error for the file not found. I can swtich it to include file and then it finds it, but then the file.inc has a bunch of other includes and it then cant find them no matter how i change it to include file or virtual. It works in IIS 6, but not IIS 7 that i am moving this site to. It is a classic asp page with mostly everything done in include files
I have mysite in the Default Web site\dept_Sites\mysite location.
I have a classic ASP style #include from a ASP.NET file as:
(!-- #include file= "../../maininc.aspxinc" --)
(Guess it is actually an IIS server-side include?)
It is some strange caching going on. It seems like the original file is cached so that changes in maininc.aspxinc has no effect.
IIS6
Expiration headers off as far as i can see
Asp.NET 3.5 (plain, not Web Form).
What is going on? What can i do? Should a dynamic type be different?
(I know that in ASP.NET this would normally be a control :-)
Consider using a Web Server control instead of an #include. See http://msdn.microsoft.com/en-us/library/3207d0e3.aspx
There isn't any strange caching going on but there is compilation going on. A page is only compiled once when it is first accessed and the resulting assembly is stored in temporary folder. Subsquent requests for the same page are simply passed to the HttpHandler in the assembly.
If you modify the page then ASP.NET detects that the existing assembly no longer matches and rebuilds. I strongly suspect the #includes are not taken into account in this mechanism.
You would be better off with one of:-
a UserControl (an file with then .ascx extension) if the include represents a set of HTML controls.
Use a master page if the include is for common navigation markup for use by many pages
A source code file (.vb or .cs) in the App_Code if you want to include some common classes.
A separate library project that builds a dll for the bin folder.
In Classic ASP, Server.MapPath() doesn't always work properly in the Application_OnStart event within global.asa. I have an ASP page at "\testfolder\test.asp" within a virtual root, I have an XSLT file at "\xsl\transform.xsl". My virtual root is located in "c:\inetpub\wwwroot\testapp\".
I use MapPath within the ASP page to get the full path to the XSLT file. The call is:
sXslPath = Server.MapPath("xsl\transform.xsl")
Some times MapPath returns "c:\inetpub\wwwroot\testapp\xsl\transform.xsl" as expected, other times it incorrectly returns "c:\inetpub\wwwroot\testapp\testfolder\xsl\transform.xsl". The incorrect path obviously causes serious problems.
I am answering my own question here:
This problem occurs because when called in Application_OnStart, MapPath incorrectly includes the context of the page that caused the application to startup. If the first ASP page to be run when the application isn't yet started is not in the root of the virtual root then MapPath gets confused and adds the path to the called ASP page to the path it returns.
So for example if the page that started the app was in "c:\inetpub\wwwroot\testapp\folder1\folder2\test.asp" then MapPath would incorrectly add "\folder1\folder2" into the middle of the path and return "c:\inetpub\wwwroot\testapp\folder1\folder2\xsl\transform.xsl"
If your website only has files in the root folder or doesn't use MapPath in global.asa then you will never notice this little oddity. I suspect there are lots of ASP Classic sites out there that fail to startup properly sometimes because of this, but their owners just do a quick iisreset, not knowing what quite went wrong.
The result of this is that you can't reliably use MapPath in global.asa if you have a website that has ASP files anywhere other than just the root folder.
If it is a one-off website then the easiest solution is to just hard code any paths you use in global.asa.
If you sell a product to other people based on ASP Classic then hard coding the paths is not an option. You either have to move all usage of MapPath out of the application startup or deal with the issue by writing paths into your ASP files as part of the installer.
alternatively use
sXslPath = Server.MapPath("\xsl\transform.xsl")
which will then map the path from the root directory
naturally if you are developing on iis in a OS that is not a server, root will be the default website, you would have to remember to change on deployment...
I'm using a pre-compiled ASP.NET 2.0 site (i.e., copied to the server using the "Build->Publish Web Site" feature in Visual Studio 2005). I catch and log all errors which are usually quite detailed, but lately I've been getting the following error with no other information:
Could not load the assembly
'App-Web-rp2eml-j'. Make sure that it
is compiled before accessing the page.
Now, that 'App-Web-rp2eml-j' file should be a dll in my bin folder which was created for the pre-compiled site. My main question is, how do I tell what aspx page is looking for that dll? I've tried re-publishing the site, and even completely wiping out the site and re-publishing, but the problem does not go away.
When Googling the problem, most answers about this error message center around making sure IIS is set up to use ASP.NET 2.0 instead of 1.1. This is not my problem.
NOTE 1: The site all seems to work, but obviously there is (at least) one page that is broken which I cannot find.
NOTE 2: The file name above should have underscores instead of dashes, but SO's markup is changing the text between the underscores to italics.
Does the mentioned dll exist in your bin directory? You italicized that portion so I suspect that it doesn't. That could mean that the error is referring to a dll in the Temporary files folder.
This problem can occur if one or more of the dlls in the ASP.NET Temporary files folder are corrupted. Sometimes ASP.NET does not refresh files here if there are no changes in the dll residing in the virtual directory. It happens every once in a while on my server.
My solution is as follows:
Stop IIS services on the server for a minute or so.
Navigate to the ASP.NET Temporary files folder (usually located at "%windir%\Microsoft.NET\Framework\\Temporary ASP.NET Files\MyApplicationName") and clear all files within the folder.
Publish and upload my site to the configured virtual directory.
Restart IIS and other services.
This simple 4-step process has worked very well for me in the past and may be worth a try for you.
To answer your basic question, however, there are two ways to "reverse engineer" a dll:
Load it up in ILDASM and check the contained classes.
Use Reflector to save all the class files contained within the dll to a folder.
However, I doubt if this will solve your problem because each dll could contain many class files and you would not have a clue as to "which ASPX page is looking for that dll".
Maybe you can catch more detailed information on the error with the Global.asax event Application_OnError, so you can watch the stack Trace.