Skip to content
This repository has been archived by the owner on Jan 24, 2021. It is now read-only.

Caching Views is not disabled in Debug Mode by default in Nancy 2.0.0-alpha #2432

Open
4 of 8 tasks
8 opened this issue Apr 27, 2016 · 5 comments
Open
4 of 8 tasks

Caching Views is not disabled in Debug Mode by default in Nancy 2.0.0-alpha #2432

8 opened this issue Apr 27, 2016 · 5 comments

Comments

@8
Copy link
Contributor

8 commented Apr 27, 2016

Prerequisites

  • I have written a descriptive issue title
  • I have verified that I am running the latest version of Nancy
  • I have verified if the problem exist in both DEBUG and RELEASE mode
  • I have searched open and closed issues to ensure it has not already been reported

Description

In nancy 2.0.0-alpha caching razor views is not disabled by default anymore as it used to be in debug mode.

Steps to Reproduce

  1. Start nancy in debug mode
  2. Visit an url and let nancy serve a .cshtml view
  3. Modify & Save the .cshtml file
  4. Refresh your browser
  5. Notice that changes are not shown.

System Configuration

  • Nancy version: 2.0.0-alpha
  • Nancy host
    • ASP.NET
    • OWIN
    • Self-Hosted
    • Other:
  • Other Nancy packages and versions:
    • Nancy.Hosting.Aspnet
    • Nancy.ViewEngines.Razor
  • Environment (Operating system, version and so on): Win10, IISExpress
  • .NET Framework version: 4.5
  • Additional information:

Workaround:

Configure nancy yourself to disable the cache in debug mode, for example:

public override void Configure(INancyEnvironment environment)
{
    base.Configure(environment);

#if DEBUG
    environment.Views(runtimeViewUpdates: true);
#endif
}

Take care,
Martin

@jchannon
Copy link
Member

jchannon commented Apr 27, 2016

I wonder if we could use this

public virtual bool IsDebug
in the ViewConfiguration.Default ?

@thecodejunkie
Copy link
Member

If I recall, the DefaultViewConfigurationProvider used to have the behavior of using the IRuntimeEnvironmentInformation but we changed it before we merged the pull-request. I cannot remember why we removed it, but I do know that the IRuntimeEnvironmentInformation interface was discussed in the CoreCLR context because we could no longer check the attributes.

Maybe we could update the DefaultViewConfigurationProvider to make use of #if DEBUG instead. The problem with that is that it would only function inside the debugger (I think) and not when you build and deploy your site in debug mode.

ping @NancyFx/most-valued-minions

@thecodejunkie thecodejunkie added this to the 2.0-beta milestone Apr 27, 2016
@thecodejunkie
Copy link
Member

Actually #if DEBUG would be fine for the DefaultViewConfigurationProvider. If you care either way about the behavior then you would explicitly set it and user set values always take precedence over what the default provider configures

@jchannon
Copy link
Member

Bingo

On Wednesday, 27 April 2016, Andreas Håkansson notifications@github.com
wrote:

Actually #if DEBUG would be fine for the DefaultViewConfigurationProvider.
If you care either way about the behavior then you would explicitly set it
and user set values always take precedence over what the default provider
configures


You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#2432 (comment)

@thecodejunkie thecodejunkie modified the milestones: 2.0-barneyrubble, 2.1 Jul 12, 2016
@thecopy
Copy link
Contributor

thecopy commented Dec 5, 2016

Creating a custom ViewConfigurationProvider with return new ViewConfiguration(true,true); does not work (even though it is being hit if i set a breakpoint). Overriding Configure in bootstrapper and calling environment.Views(runtimeViewUpdates: true); fixes this problem.

2.0-b

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants