This project is read-only.

Difference between this and web.config

Jul 22, 2011 at 2:02 PM

What is the difference between setting compilation in the web.config, and compiling using this tool?

Is it that the web.config method is for MVC views only, and this is for declarative MVC helpers (i.e. App_Code helpers) only?

Jul 22, 2011 at 5:55 PM

What web.config setting are you referring to? This tool allows you to precompile your view inside your regular assembly, and there is nothing like it that you can do with web.config.

Jul 22, 2011 at 6:12 PM

Please excuse me, I meant the project file eg "MySolution.csproj"

There is a line "<MvcBuildViews>false</MvcBuildViews>" which can be set to true to compile your views.

Jul 22, 2011 at 6:19 PM
Edited Jul 22, 2011 at 6:20 PM

Ah, that setting. That may sound similar, but is actually completely different. All <MvcBuildViews> does is attempt to build your views at design time to make sure they don't have parse/syntax errors. But then the result is discarded, and your views are still built at runtime as if you didn't use that setting. Also, <MvcBuildViews> can slow down your build significantly, which is why it's not on by default, and many people avoid it.

On the other hand, when you use RazorGenerator, your views become just regular code that gets compiled as part of your assembly. As a result, no more compilation is needed at runtime. Also, it has almost no effect on the build time.

Hopefully this clarifies things :)

Jul 22, 2011 at 6:30 PM
Edited Jul 22, 2011 at 6:31 PM

Ha! So I finally understand! It does not get compiled at all into the assembly... wow! That is surprising. Actually a violation of "Least Surprise Principle".

So if this tool now does compilation of both declarative helpers and regular views, does that mean that it supercedes Chris van de Steeg's "Razor Single File Generator"? We were using that for a while but seems there is musch overlap now in this version.

Jul 22, 2011 at 6:39 PM

Agreed that this is confusing. Maybe it should have been called <MvcVerifyViews> instead of <MvcBuildViews>?

And yes, it does cover those same scenarios as Chris's tool (which was a spin off of an early version of this tool) and more now, so you should only need one tool. You can read through my post where I discussed some of this.

Jul 22, 2011 at 6:53 PM

I missed that post. Brilliant work.

To use just the one tool now is much preferable.