My site has been moved to a new location, and now i have to change thousands of physical paths of sub-sites.
The old location was:
D:\blabla\MySite
And the new location is:
\\Server\MySharedFolder\MySite
Now i need to replace the string "D:\" with "\Server\MySharedFolder\" in the physical path of thousands of sub-sites in IIS.
What is the most recommended way to do so?
Related
I'm developing a new website that will have the same domain name as the current old one, but a different host. The new one doesn't have DNS nameservers pointed to it yet, but I edited the hosts file on my computer to be able to access it. Is there a way I can now still access the old current one on the same computer, since it would help me with development, without changing the hosts file everytime?
Thanks :)
You can check the old site by using the temporary URL
http://server_ip/~cpanelusername/
but many of host block ip preview. You also can use archive.org. You can save the old site before starting new.
For this type scenario, I use a subdomain to built a new site.
www.mysite.com >> www.dev.mysite.com
If possible, it can be helpful to set up an alias and then create an A record for that alias that points to the new site. This allows you to reach the new site via a different name but it will still look at all the files and database(s) as it would normally.
This is helpful for when you want to test the new site before it goes live without having to comment and uncomment the hosts file continuously.
One thing to watch out for is that any URLs that are the full URL such as example.com/whatever instead of /whatever won't work. However, as it is generally bad practise to do the full URL in case the domain ever changes; this can be a good way of finding and corrected any.
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
I have a web application with a page. The page has a functionality to upload a file.
I have deployed the application on two different servers in IIS7. Both these hosting have a virtual directory pointing to the same physical directory.
Here I am unable to save the posted file in the virtual directory using Server.MapPath.
Is there any sophisticated technique to handle such situation to achieve this functionality?
Well I'd suggest you 2 scenarios:
Share a folder/resource beetween those servers (assuming that
those servers are in the same LAN), then create app key in the
web.config and this key will contain the path of your shared
resource something like //Server/Folder, use this value instead of server.mappath at the time you
save the file in the server
If you have a load balancer share a folder of your main node and
then use the that path in your secondary node something like
//server/folder that route will save the image in the main node, then
set up a replication rule from your main node and the secondary the
configuration of this rule could vary depending on your needs it
could be an update to the seconday node every 5 minutes for example.
you may create a virtual directory but the purpose for this will be only for displaying the images.
that worked for for me some time ago, it's not a fancy solution but it does the job.
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.
I have a big solution that contains a lot of .aspx file, basically it's a big sln file for my whole server
I wanted to add a website in my IIS server that contains inside a child directory within the root site folder, for example:
my-tools.com physical path is D:/MyWeb <-- Working well
I added a secondary sites, with no relation to the upper site called mysite which is like that:
mysite.my-tools.com which its path it D:/MyWeb/MySite/
If I try to reach mysite.my-tools.com/M_Index.aspx file it give me an error tells me it's not found, however, when I try to view a .jps file from the same directory (e.g mysite.my-tools.com/test.jpg) it returns just find.
it's important to tell that all the pages share the same solution, what do I do here and why it is not working? can anyone tell me?
thanks a lot
having the folder separated like you do is a step in the right direction. next step is to configure IIS to point to that separate folder. then you would need to create a DNS entry for your sub-domain at your DNS host. "subdomain.domain.com". You would be creating a new site, so you could use the same IP address, as long as you add the proper host headers for each site.