The 50 seconds it takes EF to complete it's first query (as compared to milliseconds for the same or similar queries when it's warm) is making my MVC website look bad. I really need to get pre-compiled views working.
I have tried the power tools but when I run 'Generate Views' the VS12 output window shows
System.NullReferenceException: Object reference not set to an instance of an object.
at Microsoft.DbContextPackage.Utilities.EdmxUtility.GetMappingCollectionEF6(Assembly ef6Assembly, String& containerName)
at Microsoft.DbContextPackage.Handlers.OptimizeContextHandler.OptimizeEdmx(String inputPath)
The T4 templates that can generate views seem to be for code first only.
How can I get power tools working or is there another way to pre-generate the Views?
Related
Using XMLProvider from the FSharp.Data package like:
type internal MyProvider = XmlProvider<Sample = "C:\test.xml">
The test.xml file contains a total of 151,838 lines which makes up 15 types.
Working in the same project as the type declaration MyProvider is a pain, as it seems the XmlProvider is triggered everytime I hit CTRL+SPACE (Edit.CompleteWord) - and therefore regenerates all the models, which can take up to 10sec.
Is there any known work around, or setting to cache the generated models from XmlProvider?
I'm afraid F# Data does not currently have any caching mechanism for the inferred schema. It sounds like something that should not be too hard to add - if anyone is interested in contributing, please open an issue on GitHub to start the discussion!
My recommendation for the time being would be to try to simplify the sample XML, so that it is shorter and contains just a few representative records of all the different kinds.
Is there a way to get a trace of what cshtml files are being used to construct a particular page load? For instance:
/Views/Shared/_LayoutUser.cshtml
/Views/Shared/_UserNavigation.cshtml
/Views/Shared/_BannerSelector.cshtml
RenderBody - /Views/Users/Index.cshtml
/Views/Users/DisplayTemplate/User.cshtml
Anything else used to construct view
/Views/Shared/_UserFooter.cshtml
Try Glimpse. It works much like Firebug does, except for MVC. It shows the execution tree of your views/partials/layout in a tree that looks pretty much the same as you described, including their execution times. It's very extensible as well, and there are plugins to trace Entity Framework, and JavaScript, etc.
anybody knows which ones works faster ?
The Embedded Resources of the Input Builders are servered through the WebFormView engine. When your application is set to debug=false in your webconfig the view engine caches the view, so it is only loaded from the assembly once. The real reason why the input builders would be a little bit slower is that they use a master page to reduce the HTML you maintain. The Editor Templates will produce an input for example. The equvilent Input Builder will produce a label, input, and the html 'chrome" around the two so that you can specify it once and have it applied to every form that uses the input builder. The input builders are really for applying a convention for how your forms markup is built and it does it in a way that gives you control but also keeps your html fragments "DRY" (dont repeat yourself).
Like everything there are tradeoffs. For the input builders, you trade off some runtime performance for developer productivity. At the end of the day if you needed to have a super performant form on a public website, your best option would be to server a static html file that posts to an MVC Action.
Your answer depends on where you load your views pages from.
Templated Helpers have a slight edge because without any view overrides they are manipulating strings behind the scenes to produce html output.
Input Builders load views through embedded resources or through the traditional file system which will always be slightly slower than hardcoded string manipulation.
The code for both is similar and do basically do the same amount of reflection and metadata processing. Without any file or resource loading complications they both run at < 1 ms.
With customized template sourcing via embedded resources or file system calls your performance loss will be the same for both.
Recently I created a spike of a view engine, in which views are plain classes, and the content is created by using funny using-scope blocks.
The code together with a simple sample site is available at http://code.google.com/p/sharp-view-engine/
Here I'd like to hear your opinions regarding such an idea. Is it completely weird or maybe someone likes it?
I would actually not like that.
I can agree with DSLs (such as a Parser-Combinator or for generating XML Nodes in a data-context), but in this case I think that too much is being put in code that. And, in the end, this just complicates boundaries and leads to hard-to-maintain code. (You can already do the same, but with more verbosity just using the "standard" Web Controls. You can always use {subblock} in C# to limit a variables scope.)
The approach I prefer to use is templates with bindings (but no "code in templates"). That makes it easy for the "designer" (hopefully not me, or the next person to come along and) edit the layout of the view how they see fit. However, the core logic (the available controls and bindings) are kept in the code -- uncluttered. (Another advantage with the templates is that if they externally housed they do not require a recompile for every little change.)
Simplicity and maintainability are like ... zen.
This is an interesting idea taken to the extreme I'd say. At my shop we're using html conventions for pretty much everything except our layout. The only real html we have in the project is our Spark master page. For generating the content itself we use a convention engine that that spits out a semantic html model. (We're using the HtmlTags library from FubuMVC to build the semantic model.)
An example convention for rendering a multiline text box looks like:
public static HtmlTag Build(ElementRequest req)
{
return Tags.TextArea
.Rows(6)
.Id(req.ElementId)
.Attr("name", req.ElementId)
.Text(req.StringValue());
}
These conventions get triggered from reflecting on the view model (or we can manually call them from a helper method). The output is rendered (via ToString()) into the content section of our master page. We're joking that pretty soon we won't even need a view engine.
ps here's how we handle nesting. (Your using blocks look cluttered!)
return Tags.Div.Nest(
Tags.Button("save").AddClass("positive"),
Tags.Span.Text(" or "),
Tags.Anchor.Text("cancel").AddClass("negative")
);
Nest() is an extension method that simply takes a params array of HtmlTag and appends them to the parent's children collection.
I had a working solution using ASP.NET MVC Preview 3 (was upgraded from a Preview 2 solution) that uses an untyped ViewMasterPage like so:
public partial class Home : ViewMasterPage
On Home.Master there is a display statement like this:
<%= ((GenericViewData)ViewData["Generic"]).Skin %>
However, a developer on the team just changed the assembly references to Preview 4.
Following this, the code will no longer populate ViewData with indexed values like the above.
Instead, ViewData["Generic"] is null.
As per this question, ViewData.Eval("Generic") works, and ViewData.Model is also populated correctly.
However, the reason this solution isn't using typed pages etc. is because it is kind of a legacy solution. As such, it is impractical to go through this fairly large solution and update all .aspx pages (especially as the compiler doesn't detect this sort of stuff).
I have tried reverting the assemblies by removing the reference and then adding a reference to the Preview 3 assembly in the 'bin' folder of the project. This did not change anything. I have even tried reverting the Project file to an earlier version and that still did not seem to fix the problem.
I have other solutions using the same technique that continue to work.
Is there anything you can suggest as to why this has suddenly stopped working and how I might go about fixing it (any hint in the right direction would be appreciated)?
We made that change because we wanted a bit of symmetry with the [] indexer. The Eval() method uses reflection and looks into the model to retrieve values. The indexer only looks at items directly added to the dictionary.
I've decided to replace all instances of ViewData["blah"] with ViewData.Eval("blah").
However, I'd like to know the cause of this change if possible because:
If it happens on my other projects it'd be nice to be able to fix.
It would be nice to leave the deployed working code and not overwrite with these changes.
It would be nice to know that nothing else has changed that I haven't noticed.
How are you setting the viewdata? This works for me:
Controller:
ViewData["CategoryName"] = a.Name;
View:
<%= ViewData["CategoryName"] %>
BTW, I am on Preview 5 now. But this has worked on 3 and 4...
Re: Ricky
I am just passing an object when I call the View() method from the Controller.
I've also noticed that on my deployed server where nothing has been updated, ViewData.Eval fails and ViewData["index"] works.
On my development server ViewData["index"] fails and ViewData.Eval works...
Yeah, so whatever you pass into the View is accessible in the View as ViewData.Model. But that will be just a good old object if you don't do the strongly typed Views...