I want to ship pre-compiled views. I've seen a few questions regarding specifying
Changing the following in the csproj
<MvcBuildViews>true</MvcBuildViews>.
and
and modifying the web.config (since i am using entityframework)
<compilation debug="true" targetFramework="4.0">
<buildProviders>
<remove extension=".edmx"/>
</buildProviders>
</compilation>
it now takes longer to compile which i was expecting however im not sure if it is working correctly
can i presume i am right in saying that if configured correctly it should actually build the views into the binary rather than just doing a precompilation validation?
if true then should i prevent the webdeployment from shipping the cshtmls? will the presence of them onsite cause a recompile?
if so this should result in a faster start time for deployed mvc applications? as they don't need to compile the views?
should I add false to the csproj as well? i saw an article which suggested i should change it from true to false, but it isn't present in my csproj.
Cheers
Tim
can i presume i am right in saying that if configured correctly it should actually build the views into the binary rather than just doing
a precompilation validation?
No.
if true then should i prevent the webdeployment from shipping the
cshtmls? will the presence of them onsite cause a recompile?
No, cshtml files must be present when you ship.
if so this should result in a faster start time for deployed mvc
applications? as they don't need to compile the views?
No, in Release mode there's an optimization made by Razor which automatically will cache the location of views and once it parses them it doesn't reparse on subsequent requests.
So, the moral of the story is that you could enable the MvcBuildViews option in Release mode so that your build server could detect any potential errors during the continuous integration build of the project. In Debug mode I keep it disabled because it slows down building.
RazorGenerator seemed to be the only option to my original question which was to ship compiled views as binaries.
Related
I am having really some strange issue for js,images & css files related to caching.
I am using IIS 8.5 & asp.net MVC for my application, to overcome cache issue after each production release i have added version in web config and i use it mention below way. (for some common files i m using bundling)
web.config
<add key="Config.Version" value="1.0.0.0.65" />
<clientCache cacheControlCustom="public" cacheControlMode="UseMaxAge" cacheControlMaxAge="365.00:00:00" />
some.cshtml
<script src="#Url.Content("~/Scripts/somefolder/some.js?v=" + Config.Version)" type="text/javascript"></script>
I have also enabled dynamic compression in IIS.
I wants to make sure after each Release /Publish of the application, The end user /client side update files should be loaded instated of older one.
(Here issue is that even though sever has latest updated files some time client needs to hard refresh(ctrl + F5) or similar techniques ).
My main question how can i make sure each time everyone gets the latest file version.
Note: I also don't want to compromise with cache to get performance.
Can anyone show me best practice or general guideline for this ?
Adding a query string param is enough to invalidate all client-side caching. Based on the HTTP spec, the query string is part of the URL and any change makes it a completely different URL. A browser that didn't reload the CSS/scripts would be broken. I know of no major browser that wouldn't reload, though.
One thing to consider, however, is that the HTML page itself may be getting cached. If the client is just loading the old HTML, then the old reference to the CSS/scripts is the same and are also loaded from cache. Make sure you're not allowing HTML documents to be cached if you want to ensure that the user always gets the latest version.
Let's say I want to completely disable Glimpse.
Glimpse now registers itself using the assembly activation method. So even if I comment out all the glimpse stuff in web.config, it will still try to load.
I prefer to manually register Glimpse in Application_Start, if I need it.
Is there any way to override the default behavior to allow me to register it manually? (Which means I can disable it completely if I need to.)
Glimpse has been built around the philosophy to have it run with the least amount of additional config or code for users to add or write themselves. Granted this comes with the additional drawback that if you want to disable it completely, that changes from your side will be required and some changes are easier than others.
I answered a similar SO Question Why is Glimpse still running indicating why commenting Glimpse specific config inside web.config is not enough for assemblies using the PreApplicationStartMethodAttribute.
In short, you'll need to make sure that the Glimpse.EF* and the Glimpse.Ado assemblies are not deployed in addition to commenting your web.config. Not deploying these assemblies and commenting out those config sections can be automated one way or the other (web.config transformations, custom build tasks...)
I've been developing a MVC5 web application for several months. I've published to each of 3 servers used for development, testing and the intended public server. Everything has been tested by a team of a dozen beta testers and a decision was made to go live with the web app this weekend.
Prior to publishing the web app to the live (public) host I modified the web.config to disable debug mode for the public site. After publishing, all kinds of problems cropped up related to missing CSS and JS resources.
After reading a lot of articles regarding Bundles and 404 errors, I found one that hinted to add the following to Web.config:
<modules runAllManagedModulesForAllRequests="true">
<remove name="BundleModule" />
<add name="BundleModule" type="System.Web.Optimization.BundleModule" />
</modules>
This resolved the 404 issues for the StyleBundle and ScriptBundle configurations, but now I have 404 errors for images that previously worked fine. I'm not sure of the best way to resolve these. I don't want to relocate the images and I don't want to edit the CSS since these are distribution files (jQueryUI, ThemeRoller, DataTables, etc). I want to leave their distribution folder structure and original source files (CSS and JS) unmodified.
An example of the problem.
DataTables distribution is in my ~/Scripts folder:
/Scripts/DataTables-1.10.2/
/Scripts/DataTables-1.10.2/media/css
/Scripts/DataTables-1.10.2/media/images
/Scripts/DataTables-1.10.2/media/js
Bundles configuration:
bundles.Add(new ScriptBundle("~/bundles/DataTables").Include(
"~/Scripts/DataTables-1.10.2/media/js/jquery.dataTables.js"));
bundles.Add(new StyleBundle("~/bundles/DataTables.css").Include(
"~/Scripts/DataTables-1.10.2/media/css/jquery.dataTables.css"));
jquery.dataTables.css contains references to ../images/someimage.png and with Web.config debug mode enabled this works flawlessly. Now that debug mode has been disabled and Bundles are minifying/combining, I am getting 404 errors:
http://example.com/GenericError.htm?aspxerrorpath=/images/someimage.png"
It seems as though the image URL is now assumed to be relative to /Bundles/ - though I'm not positive.
There must be an additional configuration I'm missing. Can someone point me in the right direction?
EDIT
Raphael's comments on this question and his URL to another similar SO question did not help to resolve this problem. Sean's recommendation of BundleTransformer seems like it might work but I don't find any documentation on how to install this package.
See my answer at:
CSS/JS bundle in single file in mvc when publish with release option
It deals with this exact issue and the options you have to resolve it.
"The issue is that, by default, asp.net mvc DOES NOT bundle the css and js files in debug mode. But our css and js files ARE getting bundled in the debug mode."
For some reason, all the css and js files are being bundled in debug mode. It started few days ago. We have a large team with several developers and its hard to find out what changed in the last few days because there are several changes submitted to the repository. However I didn't find any significant changes in the BundleConfig and Global.asax.cs.
When the application is running in debug mode, BundleTable.EnableOptimizations returns a false.
To my understanding when debug is set to true then bundling does not happen.
<compilation debug="true" targetFramework="4.5">
So far I haven't found a single occurrence of this issue on Google. Is this a very unique problem?
Ideally instead of a workaround I would like to fix it. Finding the cause is the actual problem here. Any pointers on where I should start looking for the fix would be appreciated. Thank you.
Edit: My question is similar to but not exactly the same as ASP.NET MVC 4 app with bundling and minification, why is minification enabled in debug mode?
Someone please remove the "This question may already have an answer here:" tag.
In my case the bundle paths are already starting with a "~"
Template:
#Styles.Render("~/Content/css")
#Scripts.Render("~/bundles/js")
Bundle Config:
bundles.Add(new Bundle("~/Content/css").Include("~/Content/*.css"));
bundles.Add(new Bundle("~/bundles/js").Include("~/Scripts/myproj.*"));
Try adding this in your global Application_Start()
BundleTable.EnableOptimizations = false;
So...
protected void Application_Start()
{
AreaRegistration.RegisterAllAreas();
WebApiConfig.Register(GlobalConfiguration.Configuration);
FilterConfig.RegisterGlobalFilters(GlobalFilters.Filters);
RouteConfig.RegisterRoutes(RouteTable.Routes);
BundleConfig.RegisterBundles(BundleTable.Bundles);
AuthConfig.RegisterAuth();
BundleTable.EnableOptimizations = false;
}
For me the issue was in the web.config "debug" was set to false.
<configuration>
<system.web>
<compilation debug="false" targetFramework="4.0" />
Try troubleshooting outside of MVC specifically.
Does this problem now transcend your entire team or just your machine? If it's the entire team at least you know the change happened somewhere in the commit cycle.
Have you rebuilt the solution? Cleaned properly? Are you running IIS, IIS Express, or Cassini? Are you absolutely certain that the site/build you're running in the debugger is not in release mode? You may be debugging a specific build that isn't being modified through the build pipeline (failed builds definitely fall under this category).
I'm using VS 2010 and MVC 4 and by default in debug mode, I see absolutely no bundling. I don't have to explicitly set anything. If you're seeing differently, something obviously has to account for it as this isn't normal behavior.
I have a feeling your best approach is the hardest: unwind your commits. Make a copy of your working directory and revert to sometime before this happened. Verify the problem does not occur in this build, don't just assume. Now checkout a commit half way between that point in time and now. Test again. If the build is still good, cut the time in half and repeat. Once you've hit the issue, you know the commit it was introduced in is somewhere between your last "good" commit and the one you're currently testing. This technique greatly simplifies isolating a problem to a specific commit. I almost never go one commit at a time unless I'm completely unsure of the code or I already have a good indication of where it might be.
In my case I had used
#Scripts.Render("/Bundles/scriptname")
When I replaced it with
#Scripts.Render("~/Bundles/scriptname")
it worked. The '~' made all the difference.
I'm trying to get an ASP.NET MVC 3 site running on IIS 6.0.
Currently when I request a page from the server it gives the following error:
Parser Error Message: This method cannot be called during the application's pre-start initialization stage.
on this line:
<add name="MyMembershipProvider" type="NS.MyMembershipProvider" connectionStringName="MyDatabase" applicationName="/MySite"/>
I'm completely stumped and don't have much of a clue about the ASP.NET application lifecycle, let alone the differences between 6.0 and 7.0. Reading through the MSDN pages on it hasn't seemed to help much.
Does anyone have any insight or any good links for investigation? :)
Add this in your web.config (in the appSettings section):
<add key="enableSimpleMembership" value="false"/>
<add key="autoFormsAuthentication" value="false"/>
EDIT:
For the ones who ask why, it is a known issue described in the mvc 3 release notes
More details here
After upgrading some of my applications from ASP.NET MVC3 to MVC4 I was getting this error. It was a result of the WebMatrix assemblies (WebMatrix.WebData.dll and WebMatrix.Data.dll). I removed those references and assemblies from the /bin directory and that took care of the issue.
#Ek0nomik is right. We migrated from the MembershipProvider to the new ExtendedMembershipProvider allowing us to take advantage of some of the new functionality offered in the WebMatrix namespace. By default Simple Membership is enabled for some reason so we had to disable it explicitly since we didn't want to go as far as using the SimpleMembershipProvider.
All we had to do was add this to the web.config:
<add key="enableSimpleMembership" value="false"/>
Having Simple Membership enabled caused the Provider initialisation code to execute before the Application_Start handler. Our app structure requires App_Start to be the first thing to execute. Personally I would always expect this but Simple Membership changes this behaviour. Beware.
Well, I just got this error, and it resulted from having accidentally copied a .cshtml into the root of my project. It wasn't even included in the project. Deleted that and the error went away. This was with MVC3 on IIS7. I imagine some of the people getting this problem are in the same boat.
This is caused by any of a number of Reflection calls being made too early in an Application. It just so happens the Web.Config suggestions in other answers prevented one such Reflection call from being made. In my case however:
I'm using Entity Framework, and ran update-database. I got:
This method cannot be called during the application's pre-start initialization phase.
As it turns out we had code that used a library which was recently modified to get all code in all namespaces/projects. Specifically, it called:
System.Web.Compilation.BuildManager.GetReferencedAssemblies()
Kaboom. That caused this obscure error. EF Migrations run in a weirdo zone where the application is half running and half not, meaning the above method can never be called by any code Migrations would call on.