I'd like a different web.config when deployed on AppHarbor vs deployed to a local network machine.
In particular, I'd like to turn on Windows Authentication so I can get the current Windows username when on a Windows network but still allow Anonymous users to connect when on AppHarbor.
(Best solution I can think of use AppHarbor Configuration Setting, configure AppHarbor to allow writing to files, then rewrite the web.config on Application_Start. Ugly.)
No need to re-invent the wheel, AppHarbor team has figured this out.
I think Custom web.config transforms and merges is what you're looking for.
Related
We've moving a legacy application from 2003 to 2012R2.
As part of this we're using a legacy deployment script which deploys the site code, including its web.config file.
In prepping the servers I wrote powershell scripts to set up as much as possible of the previous manual config. This included new-webhandler calls to add web handlers.
These are over written by the deploy.
What is the best practise for managing the conflict between occasional deployments and ongoing support?
We are planning to convert our website which is running on single server to a web farm with two servers on Windows 2008 R2. I am afraid I haven't found lot of documentation on how to achieve this. Can any one please point me to the proper documentation for this. The one document I found is
http://www.datasprings.com/resources/articles-information/creating-a-webfarm-for-your-dotnetnuke-site
This one explains using single UNC share as file server but we are looking into to use every server in the web farm as file server (i.e. have dotnetnuke folder on all the server's local drive) since UNC share becomes single point of failure. So my questions are:
Can we do DNN web farm with multiple file servers, if so, how?
And also, how does the modules updates should be done? Does it need to be done on all the servers separately or does the DNN has any inbuilt mechanism for this or do we need to use DFS replication between the servers?
Also, we use heavy caching. Since we have to use file caching in the DNN CE web farms, how does the caching works with multiple file servers?
Also, please let me know any points or gotcha that I need be aware of. Any help is greatly appreciated.
The recommended way or doing a web farm for DNN is to use a single UNC share. Even with the paid editions of DNN that is the recommended approach.
Is it possible to do it any other way, yes, but there is nothing build into DNN to help you do so.
If you want to use multiple file servers you start running into issues with file based caching, module installations, etc.
Using UNC Share is best and easy to setup method to run DNN portal on webfarm. If you use single UNC share from all servers then possibly you do not get cache issue.
I had setup webfarm of DNN portal which was running on 4 web servers and 5th one was being used as file sever (UNC share) and DNN Database server and it was working quite well.
One more thing you should consider is that - Sessions.
DNN itself do not make use of Session and session variables. But if you are using your own modules or third party modules using session then it will be good to implement Session State Server.
When creating a "web app" it is common to use a wildcard domain and have each client or instance of the web app on its own sub domain. Windows Azure does this themselves, for example "yourwebsite.windowsazure.net". For some unknown reason, wildcard subdomain support seems to not be there for Windows Azure Websites. I'm very frustrated with this fact, so much so as to abandon Windows Azure all together.
Is there a work around to not having to manually enter every domain name individually that you want authorized? Is there an API for this? I have a particularly hairy requirement in that I have over 100,000 sub domains I would need to do this for before I could even consider moving to Azure.
Please look deeply into this issue if you attempt to answer it as I have already and saw no other option other than manually entering through the portal.
I suspect that you're right, and that Windows Azure Web Sites don't support this. You could, however, use a Cloud Service with a web role.
Quick question. I'm currently moving a asp.net MVC web application to the Windows Azure platform. Everything is working out okay apart from one thing.
In the application at the moment, we make use of FTP accounts for each user to import large quantities of files to our database.
I understand FTP on Azure is not as straightforward.
I've googled and found this article: Ftp on Azure
This seems to be what I need except obviously we'll need to be able to add new users with their own separate FTP account. Does anyone know of an easy workaround for this?
Thanks in advance
Did you consider running a (FTP) service that's not IIS based, and you could add users programatically? Also, how are you going to solve data sync issues when the role recycles or when you upgrade it? Make sure to backup to blob on a somewhat regular basis!
Personally, I'd mount a VHD drive (Azure Drive) which is actually hosted on blob storage, and have my FTP server point to that drive. However, make sure you only have one instance of the server (problem #1) unless you don't need higher than 99,9% reliability you can solve this by running a single instance. Step 2 is I'd implement user management in relation to that program.
It's not straightforward, and I'd advise against it though. But I understand that sometimes you have to do this. I would solve it like I described above.
I need to migrate an ASP.NET application to Azure. The application needs database access and access to temporary files and also using out-proc COM objects. Turns out there's "Full IIS" mode that offers some rather vaguely phrased advantages (from here):
However there are a number of useful capabilities that only exist in IIS, including support for multiple sites or virtual applications and activation of WCF services over non-HTTP transports through Windows Activation Services.
Now obviously using Full IIS forces me to deal with the ASP.NET part and role part working in different processes and that's a big deal so I need to know whether I need Full IIS mode in the first place.
How do I decide if I need Full IIS mode? Is there a full checklist?
I think your default answer should be use Full IIS in Windows Azure capabilities. The hosted web core offering is really there for backwards compatibility as it was the original model prior to 1.3 SDK. Full IIS is the default and you must explicitly opt to go back to HWC.
The reasons that most people wanted full IIS were around a few, but important limitations:
Better support for IIS extensions (e.g. Smooth Streaming, Web Farm, ARR, etc.). HWC did not always support the modules and combined with a missing admin permission, made it really hard if not impossible to use all the modules that folks wanted to use.
Support for multiple web sites, vdirs, and application pools. HWC is a single app pool (the hosting process) and no way to support multiple web sites. There was a serious concern about needing to dedicate 1 entire role to a single web site. With Full IIS, you can have multiple sites and use host headers to get more bang for buck out of web role (especially with small web sites)
Support for standard tooling - Web Deploy, AppCmd, etc. don't work really well (if at all) with HWC. Anything that modified the applicationHost.config usually had issues with HWC.
WAS support. This allows you to use WCF with IIS as a host in non-HTTP transports.
In general, with Full IIS you have parity with what you do on-premises so it makes it much easier to configure and setup.
Regarding the RoleEntryPoint/HWC process model versus the RoleEntryPoint and separate Full IIS process, I am not sure that is really an issue. There were a few quirks perhaps initially, but what concerns you the most about this?