I was wondering if Razor views could be compiled, like WebForm based views?
Does it even make sense to compile Razor views and why would somebody want to do that?
Edit:
Here is a blog post on this topic as well:
How to Detect Errors of Our ASP.NET MVC Views on Compile Time
To make your views to be compiled, do the following;
Unload your project by right
clicking the project on the solution
explorer in VS and clicking unload
project
right click the project which has
been converted to unavailable
project and click "Edit
your_project_name.csproj" (that
would be .vbproj if your
project is VB project)
see the following code;
<!--There some lines of code here and I deleted them to get to the point quickly-->
<TargetFrameworkVersion>v4.0</TargetFrameworkVersion>
<MvcBuildViews>false</MvcBuildViews>
change the MvcBuildViews tag value from false to true
after that save it and reload your
project.
after you build your solution to compile it, you will see that your view will be compiled too.
NOTE: to test it, break some code in one of your view on purpose and try to build. you will see that you'll get an error message.
The MvcBuildViews check is excellent but it adds a 5-10 second penalty for building your web app if it's complex enough. It doesn't cache the compilation output so it does a full compilation of all your views every time.
I found a nice compromise by following the above advice and adding a Condition attribute:
<MvcBuildViews Condition=" '$(Configuration)' == 'Release' ">true</MvcBuildViews>
We'd expect ReSharper to flag up any errors in the views anyway and the developer can always build in the release configuration as a test - we have a "preflight" script that developers run so they can easily make sure that package targets work and so on - and if all that fails, the build server will catch it.
Perhaps this trick is obvious but I've only really started learning about msbuild properly as opposed to writing Powershell scripts for these tasks. I hope this is helpful to someone.
Yes, you can. Take a look at the following post: Compile your asp.net mvc Razor views into a seperate dll
It's a "step-by-step" guide on how to compile your razor views into a separate dll. I don't know if that's what you aim to do but it'll definitely get you in the right direction.
Yes, it's possible. In fact, the best example I can think of would be email templating engines. If you compile and cache the template, then you can quickly rip off emails without having to go through the parsing all over again.
That's a good example of using Razor outside of MVC as well.
Related
I have a MVC5 project that is currently set on the "Release Configuration" and it works 100%. However, as soon as I switch the project configuration from Release to Debug, then everything goes wrong... even if I switch it back to Release mode, everything is still broken. Only way I can get the project working again is to restore from a backup.
Here are what is happening.
Firstly, when running the project, I get the following error:
BC30451: 'ViewData' is not declared. It may be inaccessible due to its
protection level.
If I open any view in the project with Visual Studio 2013, I can see that all sorts of things are marked as errors like ViewData, Html, Url, etc.
When referring to #Html or #ViewData in the view, it normally refers to the .Html and .ViewData properties of the view's base class (WebViewPage). However, if I start typing "#Html." in any of the views, I can see in the autocomplete that it is referring to the System.Web.Webpages.Html namespace instead of the WebViewPage.Html property. It is as-if the view isn't inheriting from the System.Web.Mvc.WebViewPage class.
Any guidance as to where I can start looking to get this fixed or why this is happening?
Edit:
So since nobody responded, I went through the long way. I created a brand new MVC5 project, added all the packages via Nuget and then simply copied all my files over from the old project to the new one and now it works.
Does anybody have any idea what the heck could be causing this? I don't want to go through all this trouble again in the future if the project again suddenly decides to stop working.
Ok, I think I've found part of the cause here. Thing is, since the original code is valid (it compiles correctly and intellisense picks it up) and the code used to work and then all of a sudden, one day after compiling, it just stops working.
Anyway, in the view, when specifying the ModelType, if you don't use the full name, this error can occur or occurs eventually.
For example, using:
#ModelType Models.SomeNamespace.SomeClass
will cause the error (even though the Root Namespace for the project is "MyProject") and it can be fixed by simply specifying the full namespace and class name.
#ModelType MyProject.Models.SomeNamespace.SomeClass
It's possible that a debug assembly is locked. Can close Visual Studio, search and delete for all bin folders in the solution directory. Then open and rebuild.
The other options is to go into the MVC project properties and compare the two build configurations. Are you targeting a different .NET framework between Release and Debug? 32 bit vs 64 bit? etc?
Looks like some MVC assemblies are corrupted.
Have you checked your referenced assemblies for some errors?
Try also cleaning all the .NET internal cache. More in this stackoverflow topic: Could not load file or assembly ... The parameter is incorrect
In my case imported ViewModel class name was incorrect, correcting it fixed the issue.
This question has probably been asked before but my search failed to turn anything up. Is there an easy way to find out whether a view/partial is not being used in an MVC project? Currently I'm searching for the individual view name across the entire solution but wondering whether there's a tool out there that would make this job easier? I'm ideally looking for something that would provide a visual indication within Visual Studio if a view/partial is not being used.
I'm basically cleaning up an existing codebase and want to rip out any views that are not being used any more.
When I want to see if a view is used, I move it out of my project and enable view compilation. If a view is referenced from somewhere else it usually breaks.
enable view compilation by manually editing your mvc csproj file and setting the following
<PropertyGroup>
<MvcBuildViews>true</MvcBuildViews>
</PropertyGroup>
I've just discovered this property in MVC projects, but I'm having a hard time determining if it has any real effect. The following makes me believe this property has almost no real effect out of the box:
It does an in-place compilation of the site (AFAICT), and leaves the site "updateable" so that the markup files are not affected. This is important for in-place compilation so the sources aren't wiped out.
Because it's in a WAP project, all the code files will be compiled into the project's output assembly anyways (unless they're in App_Code, but that's just odd).
So the sources in the project were already compiled, and the markup files aren't affected. What is the actual impact of using MvcBuildViews?
When <MvcBuildViews> is set to true, building the web project results in errors if the views contain any server-side code issues. Note that this includes C# errors (compile-time / type-safety / etc.), but not JavaScript errors, as those are intrinsically non-compiled.
This feature works for Razor and WebForms views, but it seems to have no effect when the Spark view engine is being used.
For performance reasons an MVC app should have compilation debug='false' set in its web.config.
What benefits does having it set to 'true' during development give? I know that it 'inserts debugging symbols into the compiled page' but what is that for?
Check out this quite interesting link (very old, but still pertaining), which tries to explain in more detail the workings of either compilation mode, or, at least contrast between them well.
In an attempt to directly answer your question regarding what debugging symbols are used for - these give extra information about the compiled code and allow for interrogation of the executing code-base when a debugger is attached; allowing you to step through the source, for instance, as the binary can now be mapped back to it's location in the source file, variable names etc.
This is used for the code that is compiled on the fly (such as aspx and ascx pages) and will instruct the compiler how to compile the files.
Rest of the files such as models, global.asax, etc will be compiled to bin folder.
I want to take a look at my views with reflextor, I have set my project to compile views
<MvcBuildViews>true</MvcBuildViews>
But when opening the DLL for my application in reflextor I do not see the views...
I see the controllers and models but no views...
Have I not compiled the views correctly? or is there more to it?
Thanks,
If you want a fully compiled ASP.NET MVC project with your views compiled, you can either run aspnet_compiler.exe against your web app.
That's the hard way. The easy way is to install the Web Deployment Project add-in to Visual Studio. Then you can add a web deployment project and set it to fully compile your web application.
http://www.microsoft.com/downloads/details.aspx?FamilyId=0AA30AE8-C73B-4BDD-BB1B-FE697256C459&displaylang=en
It's really easy to use and gets you full compilation.
Is there any chance the views are just being compiled in order to provide you with compile time checking but not actually being included in the assembled output?
It seems like the main goal of this feature could be just to help catch compile time errors quicker not necessarily to speed up the processing of the page or anything.
Views are not compiled in DLL, they are copied as is to the output. Attribute that you use is only compile time check for them.