I have inherited an .NET app that is hosted on IIS. Previously it would have been its own site within IIS. Now in my Dev environment I have to run it under Default WebSite (in Production it will still run as its own site.
So in Dev I was having problems loading scripts and css files - so I right click Default Web Site in Dev and Add Application - call the new App - MyApp and point to the physical location on disk.
So previously style sheets would have been loaded:
href="/css/folder/mystylesheet.css"
and js files:
src="/jslib/jquery-1.9.1.js"
which worked fine when the application is hosted as its own site within IIS and which still needs to happen in Production (just not in my dev) So in dev I need to change the css and js as below:
href="~/css/folder/mystylesheet.css" (note ~ added)
src="./jslib/jquery-1.9.1.js" (note . added)
and now the js and css files for MyApp under Default website are loaded. However is there something simple I can do in IIS or webconfig to switch this behaviour on/off easily in Dev/Production rather than editing all the places where scripts and css files are loaded - as I know at some point a file will get checked into Production with the path incorrect
The other problem is there is numerous links throughout the site that are all relative so were /Link/Page.aspx which now break in MyApp hosted under Default Website
EDIT
Looking at the answer below from this question
In ASP.NET, many times you will need to use a tilde (~) to get the application's root directory, so your paths would look like ~/stylesheets/main.css
When you specify a path that starts with / you are indicating the server root so if you have you site in a virtual directory, it will not be taken into account, but if the site is hosted as the default site, the path will qualify:
Example: server named foo.net with site hosted in a virtual directory named app /stylesheet will translate to foo.net/stylesheet not foo.net/app/stylesheet
All my paths start with / (i.e going to server root) - what I need to figure out is there something I could add to web.config that for Dev would let me specify The Virtual Application MyApp needs to be taken into account (just for Dev - this could then be removed in Web Transform for Production web.config file
The short answer is no, there is not one single place where you can deal with the site's location. That's because there are many possible outcomes that you might want, including:
site served from IIS root folder and accessed at root of domain (or not)
site served from IIS subfolder and accessed at same path (or not)
IIS rewrite rules (inbound and outbound), which adds layers of mapping between public and private paths
sites mapping to subdomains, DNS wildcard mapping (where requests are distinguished by hostname), etc
sites mapping to child applications, inheriting or not inheriting rewrite rules (and other configuration)
all of the above
At the same time, there are many places where you interface with paths:
internal physical paths, usually for disk access, and usually requiring mapping of virtual path
internal virtual paths
internal ASP.NET paths, like virtual paths except that they can be app-relative (using ~), which IIS doesn't always recognize
public-facing paths
all of the above can be relative or absolute
So yeah, it's a mess.
For your case, the simplest thing is probably to make the development environment mirror the production environment. Unless you're moving the live site, delegating all the path references to a configuration-aware function is probably more trouble than it's worth.
The ~ is added to make the path relative to root directory. One suggestion is to move the folder up a few levels.or down a few levels to make sure your project is in the correct directory. Hope this works
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.
Using FileZilla, I can access folders that are outside my web directory. How can I do the same with Dreamweaver so that I can edit the files and automatically save/upload all through Dreamweaver? I currently can only access the web directory.
I know how to include them with PHP, but I would like Dreamweaver to find/access them.
Thank you!
You would have to set the Site Definition (both local and remote) paths to look one level higher than you currently have it. So if the local path is
My Documents/Web Sites/This Site
you would change it to
My Documents/Web Sites/
and if the remote is:
/user/home/domain.com/
change to
/user/home/
The problem you are going to run into is that Dreamweaver doesn't work well when set like this. It assumes the Remote path is the public web root and will create all sorts of files and folders there automatically and DW expects those to be in the public root. Also, things like setting paths to includes and images automatically will start to not work as all paths will start outside of the public web root.
Best to leave it as it is and use an external FTP program to handle the files outside of the web site.
We've bumped up against this situation previously where the desire was to have the PHP include files be moved outside the public HTML directory. JCL1178's answer is absolutely conceptually correct.
The actual implementation was to duplicate the site (under "Manage Sites") and essentially create a separate site for the "includes" directory that would go one level up. So the "Root Directory" setting was normal (in our case "public_html/" in the main site and we removed "public_html/" from the Root Directory setting in the "includes" site, effectively causing the path to go one level up.
Definitely not an ideal situation/workflow, to say the least, as you'll end up with two site definitions for one site (which can cause other issues); but Dreamweaver is what it is. We were working on a project offsite that did not allow for anything other than Dreamweaver to be used, so this is what we came up with to comply.
As an added note: we were only able to implement this solution because the webhosting plan allowed us to get to the root. If you're on a webhosting plan that is strictly limited to the public directory, the whole thing will be DOA.
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.
I know that there at least two approaches to leverage the web.config file:
using the configSource attribute which was introduced in .NET 2.0 - here is a good blog entry about it.
The file attribute of the appSettings tag which lets you point to an external file with a relative path. Described in the MSDN documentation on the appSettings element.
Now, my problem is that both approaches work well only for physical paths. But I need to address a config file which is in a virtual directory.
Which other method could I use to put my config resources in a virtual directory?
Note: I want to do it this way, because I have multiple instances of my web application on the same server (and that on many servers). To keep deployment easy and clean, I want to keep one directory for all the files (aspx, ascx, images, css, js etc.) and point the web apps in IIS for different customers (=domains, https etc.) to this single directory. In every IIS web I would have a virtual directory called "custom" which points to a different folder for each web.
Update: I'd like to point out that this virtual directory "custom" is not suited to contain an inherited web.config - that web.config would be valid only for the custom folder which doesn't contain aspx/ascx files.
I have the same scenario and after reading you post I realised that asp.net won't let you do this for various security reasons.
Therefore I turned to the OS to find an equivalent to the Linux soft link function which in turn led me to the Junction utility from sysinternals. This can create a directory that is actually any other directory on that volume and asp.net can't tell the difference and so happy loads the config sections that are not actually in a subdirectory of you website. Works for me :)
Virtual Directories can be set as applications, and you can just place another web.config there.
It will inherit any changes from the parent config, and you can add custom settings in it.
I was looking to do the same thing but it did not work, so I decided to do the opposite, as you know the web.config can be inherited, so I pointed IIS to a folder containing the client config (connection string, file path etc) files and the website files i put them on a virtual directory with the rest of the webconfig (where it load dll and other application files needed)
So basically i can use the website files to multple clients and the clients with their own Database connection string and other specific client settings.
I have a website that is deployed between 3 different environments - Dev, Stage, and Prod. For Stage and Prod, the site can resolve local paths to images with just the base url to the file, such as /SiteImages/banner.png. However, on the Dev server I have to hard code the full URL of the image path for the image to be resolved, such as http://server/folder/SiteImages/banner.png. Is there a setting I can flip to make the Dev server behave in the same manner as the other 2? I am using IIS 6.0 on a Win 2003 server.
There are usually three kinds of URIs that you can code in a website as far as I know.
Absolute: http://yoursite.com/somehing.jpg
This url includes the http:// and is
the full path to a resouce.
Root Relative:
/something/something.jpg
(In ASP.net
server-side only, you would use
'~/something/something.jpg')
This path is relative to the root of
your site.
File relative:
../something/something.jpg
This path
starts at the location of the file
that includes the URI. In this case,
it just back one directory (..) and
then goes back into the something
directory to look for something.jpg
What does the URL to the dev home page look like? Is it something like http://server/mydevsite/? If so, it sounds like you need to set up a virtual host.
Edit Just to clarify the above, say your prod and stage sites can be simply referenced as http://stagesite/ and http://prodsite/, if you use a path such as /images/myimage.jpg it assumes that the images folder are sitting in the root. In those two instances, no problem, images will display correctly. However, let's say your dev server is like the example I listed above. If your images are references as /images/myimage.jpg, instead of the server looking at http://server/mydevsite/images/myimage.jpg, it will instead look at http://server/images/myimage.jpg. If no images folder with the requested image exist in that server's root, you'll get an error.