2

I am using ASP.NET MVC3, .NET4, Razor, C#, EF4.1, MS SQL2008(dev), SQL Azure(test,live).

I am deploying my web application to "Standard" Azure Websites. My process is:

1) Publish to local IIS folder, no precompilation options selected:

  • Project C# code is compiled as Project dll and put into "bin" folder.

  • Views stay as source *.cshtml files

2) FTP changed files to deployment server using Beyond Compare,so

  • Project DLL gets copied

  • Source *.cs files (Controllers, helpers, Models) get copied.

  • Changed source *.cshtml Views getting copied

With the initial call to the deployment server, the response is slow, due to JIT compilation. I suspect this is due to:

a) Views being compiled. Major factor as opposed to project dll??

b) Project DLL already precompiled so no issue here ??? Is this correct.

I try to keep the application pool in memory via pingback services either external monitor sites(Uptime Robot) or MS's "always on" service which is the same. But one can still get app pool refreshes and thus slow downs. It seems to me that everything should be precompiled for deployment so that if dropped from memory then rerunning will be quick.

My question(s)

1) Is my understanding correct about what is precompiled and what is not?

2) What should I do now to maximise precompilation and minimise these app pool refresh penalties, and thus keep performance at it peak ie no start of day warm ups etc. My initial impression is to precompile the Views. I did try editing the Project XML file, and this setting specifically:

    <MvcBuildViews>true</MvcBuildViews>

However when I try to publish using the above setting I get an error:

obj\release\aspnetcompilemerge\source\web.config(45): error ASPCONFIG: It is an error to use a section registered as allowDefinition='MachineToApplication' beyond application level. This error can be caused by a virtual directory not being configured as an application in IIS.

EDIT

Having done a little more research it seems that I need to focus on precompiling the Views for wich 2 main tools exist:

a) RazorSingleFile
b) RazorGenerator

Apparently 

<MvcBuildViews>true</MvcBuildViews>

just compiles rather than precompiles. Not sure of the difference. So it is recommended to use one of the tools above.

EDIT2

My main MVC project dll is 890k-ish in size. Is this large? Would the size cause more drop out from memory?

Erik Philips
  • 53,428
  • 11
  • 128
  • 150
SamJolly
  • 6,347
  • 13
  • 59
  • 125

2 Answers2

1

There is a serious rabbit hole when building views. There is some known bug that this particular error happens. The only known if is to use the <BaseIntermediateOutputPath>. This path needs to exist, and not be within the project path (I think). I usually use:

<MvcBuildViews>true</MvcBuildViews>
<BaseIntermediateOutputPath>..\..\tempMVC</BaseIntermediateOutputPath>

The Aspnet Compiler Build Task in Visual Studio 2010 ASP.Net MVC 2 Projects

I am 95% sure that: You can't pre-compile MVC views (cshtml, etc) for deployment (with any default version of Visual Studio, there may be add-ons). There are two separate issues here.

First, <MvcBuildViews> is only a buildtime strongly-typed checker when set to true. Meaning that if you build a view against a specific @model that the compiler will check the view during a build to make sure aren't using the model incorrectly (like trying to use a property on the model that doesn't exist).

Secondly, the notion of pre-compiling a view into an assembly is a process that exists for Webforms because there is a code in-front and code behind that can be combined. Views aren't tied to logic in this way so the compiler hasn't been designed to take MVC Views into account.

Community
  • 1
  • 1
Erik Philips
  • 53,428
  • 11
  • 128
  • 150
  • Thanks for this. Will try. Is there a difference between this and Razorgenerator's output in terms of compiled views and speed at runtime. – SamJolly Apr 28 '14 at 11:27
  • Also added EDIT2, to do with project dll size. Basically is 890K too big? – SamJolly Apr 28 '14 at 11:27
  • Updated per your comments. 890K is tiny and I say tiny because EntityFramework is 5056k. – Erik Philips Apr 28 '14 at 18:57
  • Thanks for feedback. Did not understand comment about "You can't pre-compile MVC views (cshtml, etc) for deployment". Is this not what RazorGenerater or RazorSingleFile does? – SamJolly Apr 28 '14 at 22:47
  • RazorGenerator and RazorSingleFile are add-ons. I'm saying, out of the box Visual Studio cannot pre-compile views. – Erik Philips Apr 28 '14 at 22:54
  • Thanks for this. Ok yes they are add-ons. I am also experimenting with VS2012's publish tool and selecting the precompile options, setting the updateable option to non updateable which apparently will then ensure all views are compiled to dlls. The signs are positive except I have a error which prevents the job completing which is the subject of another SO question. – SamJolly Apr 29 '14 at 01:08
  • If you do succeed in compiling views without using an add-on, I would like to you to answer your own question and accept it (as I'd like to know the answer, and I'm sure it would help others as well.) – Erik Philips Apr 30 '14 at 21:45
  • thanks for this. See below. It is the standard VS approach. Not sure if RazorGenerator is doing more? – SamJolly May 01 '14 at 01:52
1

OK, my solution was to publish the application.

Then I selected:

Precompile during Publishing

I then clicked on "configure" and then unchecked:

Allow precompiled site to be updateable

I then selected:

Do not merge, create a seperate assembly for each page or control.

This enabled the precompilation of the views, and put them in the bin folder, in the form of:

_orders.cshtml.4deb95a2.compiled

I understand this to be p-code and so will still need a binary compilation on first load on the deployment server. The project dll is worse since it is bigger.

By the way I did encounter quite a few assembly references issues that were caused by old excluded code files. I thought if they were excluded that was good enough, but no..... In the end I just deleted them all and the precompilation completed successfully.

Doing this forced me to fixed quite a few hidden razor errors which would have come out at runtime as opposed to compile time.

SamJolly
  • 6,347
  • 13
  • 59
  • 125