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...
Related
Existing ASP.NET (MVC and webforms hybrid) website displays translated content. The language is based on a cookie that stores the user's preference. There is no change in the URL when the user changes the setting. The content is reloaded in the preferred language. For SEO, the locale should be included in the URL ( support.google.com/webmasters/answer/182192?hl=en).
I've tried the following:
1) Use URL Rewrite Module: (http://www.iis.net/learn/extensions/url-rewrite-module/setting-http-request-headers-and-iis-server-variables)
Issues:
- All hyperlinks and redirects still point to the old URL without the locale.
- Complex outbound rules required based on the folder structure and usage (mixture of absolute paths and relative paths e.g. ../, ~/, /).
- Also need to disable static compression as per documentation
- Performance considerations due to large size of Html.
- Postback results in runtime exceptions due to issue in the relative path rewrite.
- Paths defined in script files (ajax loading etc) are a huge challenge
- Base tag does not work as expected, because the Rewrite Module seems to append ../ (http://www.iis.net/learn/extensions/url-rewrite-module/url-rewriting-for-aspnet-web-forms#Using_tilda)
2) IIS 7.5 Virtual Directory: Create Virtual Directory for each language and point it to the root. i.e. www.example.com is the root and www.example.com/fr-ca/ is a virtual directory mapped back to the root
Issues:
- Runtime exception in config file saying that the virtual directory needs to be converted to application
- Converting it to application gives 500.19 error due to duplicate entries in the web config (since the virtual directory is pointing back to the root)
- I tried moving the root to another subdirectory (i.e. have a physical directory for each language) to avoid web config conflicts, but that is resulting in some sort of "kernel" error. Also, this would mean changing the physical structure of the application, and also address routing issues
3) Using sub-domains:
I have also considered using sub-domains and hosting the application independently for each language, but this has a lot of drawbacks, including having to address scalability, single sign on, cookies, domain specific stuff like analytics etc.
So what is the least painful way to include a language sub-directory in the URL, and make all links relative to that sub-directory?
Note: The site contains a mixture of absolute paths and relative paths e.g. (../, ~/, /) sometimes used in conjunction with ResolveClientUrl, ResolveUrl
In the end, we went with option 2, with the below steps:
Create a new folder, deploy a copy of the application to the new folder. The new folder should be in a different directory from the root application.
Create a new virtual application* (not virtual directory) under the root application; 1 for each new language, pointing to the new folder. (If the need arises in the future, any of the virtual applications can point a different folder customized for that specific language)
In the new folder, remove the modules and handlers sections in the system.webServer section of the web.config file (they will be inherited from the parent web.config)
If you are using SQL session state, you will need to specify a custom Application Name in the web.config, and modify TempGetAppID stored procedure so that the Application Name is the same across all the virtual applications. See the following (http://blogs.msdn.com/b/toddca/archive/2007/01/25/sharing-asp-net-session-state-across-applications.aspx)
Hopefully, all the links are resolved on the server side using Url.Content (MVC) or ResolveUrl (webforms). If not, they need to be fixed. Any paths specified in javascript would not automatically resolve to the virtual application either (they would still be resolved to root application)
Test the heck out of it. Each and every link. (A tool like ScreamingFrog may help to make sure that no 404s are returned, methinks. But it wouldn't solve HTTP POST)
Note that depending on custom error handling, and any existing URL rewrite rules, the steps maybe different.
Summary: option 1 (URL Rewrite) is totally impractical. Option 2 (sub-directory) is the most practical solution, however it is not quite as straightforward as it should've been.
Doing a project between multiple people, and a few components (web app, services app and some others). We will be storing some information inside the Content folder of the web app so it can be accessed directly from the web server with an href, however other components outside of the web app need to access this folder as well, and since we are sharing the project between multiple people using an absolute path is not an option. What options do we have?
EDIT: Trying to explain it a little better.
What i have exactly is, a web project, a "data project" which is just a dll, a "logic" project which is another dll and a services project which is an exe/service.
Both the web project and service project consumes the methods from the logic, and the logic from the data project. Being the last one the responsable for storing data (in a database) and also in the file system.
This "filesystem" path should be configurable, and we are aiming to put it into the content folder of the web project so multimedia files can be accessed directly rather than doing a byte stream.
Now in the web.config(config file of the web app), and app.config(config file of the services app) i could set the absolute path to web/content (the same for both config files) and the data dll would use it without problems. Now the main problem is that we cannot put an absolute path in the config file because each person works on a different computer with obviously different file paths. So if i could just write something like: ~/project/Web/Content rather than C:/myfolder/stuff/blabla/project/web/content in the config files, with ~ resolving the path to the project, this is what i want! Or maybe better ideas about how to share a folder with these apps without adding absolute paths hardcoded somewhere.
What you want to use is:
Server.MapPath("/Content/filepath.ext");
This will give you the absolute path of a file based on it's position within the website, in this case, from the /Content directory.
For a program external to the website, you have a couple options;
The easiest to implement might be a simple configuration value in the external program which points to the directory. My guess is you've already decided that's not ideal, but it may be the quickest way.
Alternatively, there's a Microsoft .NET assembly which gives you easy access to IIS information (I can't recall its name off the top of my head!). You could use this assembly to find the appropriate website, and retrieve its root directory. I'll see if I can find it and get an example, or maybe someone else will see this and post an answer with that information.
Please check the following method "ResolveClientUrl"
MSDN
Use the ResolveClientUrl method to return a URL string suitable for use by the client to access resources on the Web server, such as image files, links to additional pages, and so on.
http://msdn.microsoft.com/en-us/library/system.web.ui.control.resolveclienturl.aspx
I have just started to work for a new company as a web developer, previous research has led me to find out their site is built in asp.net which isn't a problem, I just dont have any experience in this, all my experience is html, css, php and Js.
Upon gaining access via ftp, I noticed there is no traditional index.bla, so I went to the homepage on their website, and in stead of index, it was default.aspx.
Is this "default.aspx" file the .Net replacement / equivalent of an index file, and does it work in the same way?
Yes. In IIS (the web server) you can specify which files will be shown when a directory (like the root, when accessed through http://www.sitename.tld/) is requested.
You can configure which files will be shown and in what order. Like here (IIS 6):
So when a user requests a directory on that site, IIS will search for "Default.htm", if that isn't found it'll look for "Default.asp" and so on. If none of the default documents are found, you will either see the directory's contents (disabled by default) or an error saying you can't see the directory's contents.
In Apache this is set through the DirectoryIndex directive in httpd.conf.
Yes. index is an arbitrary name that Apache defaults to. The index page can be named anything, and with IIS it is usually default.
I've just create a new ASP.NET Web Application in VS2010, and set it up as an application in IIS7.
Not sure if this is relevant, but the code physically resides in the \myserver\projects\epeui\epe folder (the projects folder is the root of my default web site). The application hangs off the root of this machine's default web site: http://myserver/epe/. And is configured as an application in IIS.
Normally, I used URLs that are relative to the application root, so my CSS files are in /styles/, my images are in /images/ and my JavaScript files are in /scripts/.
Given that the application is configured as such in IIS, to access my logo, I would expect to use /images/mylogo.png, an application-relative URL.
However, this doesn't work for this site; instead I need to use parent paths (../images/mylogo.png) or URLs relative to the default web site (/epe/images/mylogo.png). Neither of these are very good for portability reasons.
I've also tried using the tilde to use URLs that are supposedly relative to the virtual path (i.e. the application root) = ~/images/mylogo.png
I swear I've done this a thousand times before but clearly screwing up somewhere... Any suggestions?
Can someone at least confirm that, for a standard application in IIS, /mypage.html should reference http://myserver/myapp/mypage.html and not http://myserver/mypage.html?
/mypage.html is going to map to the root http://myserver/mypage.html, this is correct behavior
The ~ on a SERVER SIDE control will map to the application root (so <asp:HyperLink NavigateUrl="~/mypage.html"...> will map to http://myserver/myapp/mypage.html
I have, in the past, especially with css and javascript files had to use <%= Request.ApplicationPath %>/myPage.html. Sometimes it's good to define that as a global variable in the global.asax.cs so you can use it all over. Request.ApplicationPath in your instance will be "/myapp"
I've struggled with this a lot too.
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...