I will shortly be going live with a new .net web application. It will be deployed to a load balanced environment over 5 servers.
Before go live there is a holding site on all the 5 servers to which the domain is currently pointing -> www.website.com
Prior to go live, I would like to deploy the new site to 5 servers and for the holding site to remain and for it to be what the public sees.
And when the time comes, I can put the new site live with a flick of a switch. I also want the new site to be on the servers so that I can test it prior to go live.
I am running in IIS7.
This is common practice I presume so what is the easiest way doing that above and achieve installing the new site on the servers will not affecting the holding site. The new site be accessible to me but the holding site be viewed by the general public. Any suggestions as to how this can be achieved?
You can create more than one website in IIS. I would create a new website on each machine with a temporary host header and then change it to the site URL when you want to go live. The load balancer may affect your decision on whether to deploy to another site using a host header, port, or some other identifier.
Related
Looking for a design solution.
We are currently migrating our old site installed in Windows Server IIS to Cloud-based Azure App service or Azure Service fabric.
We have multiple clients but one of the requirement is to move clients one by one.
I.e They want us to use the same DNS, but based on brands it should route to the new or old site.
so for example, we have 2 brands
Brand 1 - moved to a new site
Brand 2 - still using the old site.
So we when the request comes
For www.Mysite.com/brand1 then it should call Site hosted in Azure.
For www.Mysite.com/brand2 it should call old site hosted in windows
server IIS.
Is this feasible? If yes what are the options I have?
I saw options to Redirect a Domain by modifying .htaccess file.
Currently looking for options to finalize the design approach i.e moving all client at once or moving one by one. But later is preferred.
It is possible to use an Azure Function to handle the redirect. I have done something similar in order to create our own short urls for text messages. Before redirecting you can inspect the original url to determine where to redirect too.
Check out this link
Most likely a good business case for having an azure application gateway as its made for redirecting traffic based on the route requested. the gateway would need to be register under the domain name you want visible and you would then configure the routing rules on the app gateway resource. your azure resource and your on prem resource would be considered your backend pools
www.Mysite.com/brand1 -> point to my new cloud server pool
www.Mysite.com/brand2-> point to my existing app server pool
Linking the azure docs on this.
https://learn.microsoft.com/en-us/azure/application-gateway/overview
I maintain a website written in ASP.NET MVC 5, and hosted in Azure. It's a legacy app that is a real nightmare to maintain, and so I've been asked to start migrating to a new codebase and the ASP.NET Core framework.
Our goals are:
Migrate one page at a time
Don't lose the "F5 debugging" experience in Visual Studio
My initial thought was to use a virtual application/directory, which is supported both in Azure and in IIS Express. The idea is to point, for example, the /Shop page to the new website by using a virtual path. Then when we're ready, move the /Team page and so on. I would add a virtual path for each migrated endpoint until the migration is complete.
To accomplish this I created a new ASP.NET Core project, and I've been trying to edit my applicationhost.config file and trying to start multiple projects from Visual Studio, without luck.
I tried configuring two sites with the same port binding, two apps within a <site> tag and also two virtual directories within an <application>, but I always end up with errors. Either I can't start debugging (Can't connect to IIS Express or The object invoked has disconnected from its clients messages) or I get a 502 error.
I don't even know if this is going to work in Azure, but I know we can't go down this path without proper development experience.
Am I missing some other, better solution? If this is a good solution, is there any way to make this work in Visual Studio?
I would consider creating multiple new websites in Azure, one for each section. Then, as I start working with Shop, for example, I'd leave an almost-empty controller in the original solution, redirecting to your new Sales web site. Using this approach, you can efficiently work with one smaller code base at a time and in the future scale the individual pieces of your site as needed. Please note, that you can host multiple sites within the same app service environment (thus not incurring a lot of extra cost by separating into multiple processes).
Best of luck :-)
-- background --
I have a customer intranet (ASP.NET / VB) thats instantiating an asp.net session checking various things in the dblogin process. The Intranet has various sub-systems.
The marketing sub-system requires an app_role to be assigned to the Intranet user for them to view the section.
I need to create a new booking form for this section but the code appears to use a generic form which is use throughout the site in various other sections. So its not a good idea to ammend what is currently there.
-- My plan --
Create a new application in C# / ASP.NET and also in IIS. (rather than a new site, create an app within the Intranet site in IIS)
Will I be able to check for the session thats currenting set in the cookie?
If the session is open then the user is able to see the Intranet and I assume I will need to do some checks for the app_role too.
I am simply going to put the URL for the app in the menu for marketing and then do another check just incase someone gives the URL to someone who doesnt have access to the menu.
--My Question--
Will i be able to check and use the cookie thats been instantiated by another application?
No - Sessions (session cookies) are application specific. You can try sharing sessions between applications via SQL and see if that works. As for membership/roles, see this.
Still, unsure why building a separate (web) app (which introduces the issue) is the way to go. If your plan is to introduce another form then why can't this be done in the existing intranet app?
Is there any way to specify a permanent port for ASP.NET Configuration site (Web Site Administration Tool)?
I need to add a link to the ASP.NET Configuration site, but I can't due to the port changing each time it starts.
Its the port for ASP.NET Development server
http://msdn.microsoft.com/en-us/library/ms178109.aspx
I'm not sure that you can.
The Web Site Administration Tool isn't really meant to be "linked" to as such, it's a fairly powerful, unsecured application, that's only really meant to be run by a developer/admin.
The "Considerations" section of the documentation explain why:
The following sections provide some considerations for working with the Web Site Administration Tool.
Restarting the Application When Saving
Most changes to configuration settings that you make in the Web Site Administration Tool take effect immediately. This requires the Web site to which the change applies to be restarted. Because this will cause currently active sessions in the Web site to be lost, you should make configuration changes to a staged or development version of the Web site before publishing these changes to the production server.
Saving Your Settings
Most changes to configuration settings that you make in the Web Site Administration Tool take effect immediately. For settings for which the Web Site Administration Tool interface has a dedicated Save button, leaving the Web Site Administration Tool idle or allowing the Web Site Administration Tool to time out before you click Save will cause your configuration settings changes to be lost.
Time Out
As a security measure, the Web Site Administration Tool times out after a period of inactivity. Any settings that did not take effect immediately and were not saved will be lost. If the Web Site Administration Tool has timed out, close your browser, and then reopen the Web Site Administration Tool in a new window.
The Web Site Administration Tool manages only some of the configuration settings that are available to the Web site. Many other settings require direct modification of configuration files either manually, by using the MMC Snap-In for ASP.NET, or programmatically, by using the ASP.NET Configuration API.
From that you can see that this isn't something that's intended to be kept around.
That said, with a little bit of hacking around, you could probably shoot yourself in the foot achieve what you're after:
If you right click on the ASP.NET Development server task tray item for the admin tool, and select "Show Details", you can see that the virtual directory that the tool runs under is mapped to (something like):
C:\Windows\Microsoft.NET\Framework\v4.0.30319\asp.netwebadminfiles\
If you were to create (and secure) a virtual directory on your application mapped to that path, you might well be able to get this all up and running as you want.
As pseudocoder points out in his comment below, while going down the Virtual Directory route does "work", there are some limitations to the tool that, coupled with the security issues mean that you probably wouldn't want to use it going forward.
If you were to stick with the Development Server option, the tool won't respond to non-local requests, and once you've deployed the site to a proper web server (IIS) for users to access the Admin site won't be running anyway.
It would probably be better if you could explain why you want to use this permanently so we can advise you on some better options - for example the Membership, Profile and Role providers both provide nice APIs for managing user details that can be easily built into a custom admin area.
Tricky one, however I think to get this working correctly, you're going to have to spend some time doing something, and it's probably better for you in the long run to spend that time doing the right thing rather than hacking in the wrong option.
The Development server can be started from a command line, using a commands along the lines of:
call "C:\Program Files\Microsoft Visual Studio 9.0\vc\vcvarsall.bat"
"C:\Program Files\Common Files\Microsoft Shared\DevServer\9.0\WebDev.WebServer.exe" /port:3900 /path:"PATHSITE" /vpath:"PathSite"
The first line sets up the CMD instance to use the variables and path settings needed to run most of the Dev tooling
You'll want to change the path to the DevServer as appropriate for your environment (mine's in \10.0\ for example, and has a 2.0 and 4.0 version).
Armed with this information, you could do something along the lines of:
Add a link to your site to a page called /StartAdmin.aspx or similar.
In that page, you would then need to have the logic to:
Check through the running processes for the instance of the DevServer that was previously used to host the Admin site.
Close that process down.
Spool up another instance of the DevServer with a known port, pointing to the path for the WebAdmin Site.
Redirect the user to this new site.
All of which is possible, but it's not trivial, and you'll find you'll need to be doing odd things with the process your starting, and you'll need to be very careful you don't shut down the instance of the DevServer that's actually running your site by mistake.
However, this would probably take as long as it would to knock up a quick set of user admin screens, and you'd learn something more useful along the way*
* Which isn't to say that learning how to start and leave running a process isn't useful, it's more to say that I'm guessing its not what you're supposed to be learning at the moment, and you should probably be focusing on that ;)
if
i have two IIS servers 5v on one network running winxp each hosting a separate site,
the navigation between the sites is related by using response.redirect("~/site2") when button is clicked on site1.
will this create any sort of chance of errors, like
you are connected to server1 which does not have this page!! or will the other IIS server read the browsers request and display the page?
it should but asking as i would like to know the downside of having two webservers on a single network.
If you literally use response.redirect("~/site2") then it will not navigate from one site to another. ~/site2 will be interpreted as, site2 folder in the current web application. You will need to use the absolute URL e.g. response.redirect("http://xpmachine2/site2")