Posts

Showing posts from January, 2014

Azure - transforming the csdef file

I adapted this idea from here: http://fabriccontroller.net/blog/posts/apply-xdt-transforms-to-your-servicedefinition-csdef-file/ Basically, we had a situation where we had an app hosted in Azure that was reliant on host headers to switch behavior. Now, host headers are defined within the .csdef as bindings - something like this:     <Site name="Web">         <Bindings>           <Binding name="HttpIn" endpointName="HttpIn" />           <Binding name="HttpIn_CO" endpointName="HttpIn_CO" hostHeader="www.xxx.co.uk" />         </Bindings>       </Site>     </Sites>     <Endpoints>       <InputEndpoint name="HttpIn" protocol="http" port="80" />       <InputEndpoint name="HttpIn_CO" protocol="http" port="82" />     </Endpoints> We also had to deploy this app in more than one country, with bot

ASP.Net ViewEngine caching and how to hack it

In ASP.Net MVC, view engines are responsible for finding your views. You can have as many view engines as you like, and MVC will ask each view engine in turn whether it knows about a particular view. For performance reasons, view engines cache their results for 15 minutes using sliding expiration. When requesting a view, MVC will first ask all registered view engines whether they have already found a view for the current controller context and view name. The first engine to say yes gets to render the view. If no view engine can render the view from its cache, MVC asks each view engine in turn whether it knows how to render the view without using its cache. In an app, some controller actions render different views depending on what the current host is. For example: www.example.co.uk www.example.org Both resolve to the "Home" controller's "Index" action in the same application which always returns View(). However, there are two folders of views: