Couple limitations of razorgenerator msbuild targets

Jan 14, 2012 at 12:37 AM

Hey, just started using the razorgenerator msbuild targets and see a couple places to improve the functionality:

  1. There's no built-in way to conditionally precompile.  e.g. we have one project that we build against both MVC2 and MVC3 to support migrating from one to the other, so we need to not precompile the razor views when building the mvc2 version.  I was able to solve this with a condition on the import but might be nice to have a conditional property within the targets.  
    <Import Condition="'$(MvcVer)' == '$(CurrentMvcVersion)'" Project="$(BuildToolsDir)\RazorGenerator.MsBuild.1.3.1\tools\RazorGenerator.targets" />
    
  2. There are no inputs and outputs defined for the target, which means that the compilation will happen again even if none of the cshtml files has changed.  Support for incremental builds would be very nice, especially for projects that have lots of views.  The stock asp.net mvc view precompilation has this same issue.  But this would be easy to solve in the targets file by adding something like: 
    <Target Name="PrecompileRazorFiles" 
    Inputs="@(RazorSrcFiles)"
    Outputs="@(FilesGenerated)"
    Returns="@(FilesGenerated)">
    
  3. One other possible issue that I've seen with the asp.net view compilation is that the list of views to build is pulled from the filesystem via the pattern **\*.cshtml but if you have excluded a view from your csproj it would still get precompiled and end up in your assembly (or cause a build failure if there is some error in it).  Not sure if there is an easy way to pull the list of views out of the csproj instead so you can ignore excluded files.
Coordinator
Jan 14, 2012 at 12:52 AM

1) Would addressing #3 by allowing a specific list of views to precompile suffice? To sepcifically address 3, we should be able to look at Content ItemGroup in the csproj file to determine the views rather than using a directory scan.

2) We recently made some tweaks to the MsBuild task to not recompile views if the view files hadn't changed since the last time the generated files were created. Were there alternate heuristics you were considering for the input file? Wouldn't addressing #3 also address this scenario if you did have alternate methods for determining what needed to be precompiled?

Jan 17, 2012 at 4:16 PM
pranavkm wrote:

1) Would addressing #3 by allowing a specific list of views to precompile suffice? To sepcifically address 3, we should be able to look at Content ItemGroup in the csproj file to determine the views rather than using a directory scan.

2) We recently made some tweaks to the MsBuild task to not recompile views if the view files hadn't changed since the last time the generated files were created. Were there alternate heuristics you were considering for the input file? Wouldn't addressing #3 also address this scenario if you did have alternate methods for determining what needed to be precompiled?

The specific list of views, especially just by filtering *.cshtml out of the existing Content ItemGroup would be perfect.

I did not test this to see if unchanged files caused a recompile but did not see that the msbuild-way of doing this (defining inputs and outputs for the build target) was implemented so was not aware there was custom code inside the generator task to do this.  As long as this capability is there, that is perfect.  But you may save yourself some coding if you can just use what msbuild already provides.

Thanks for the quick response!

Coordinator
Feb 6, 2012 at 12:07 AM
This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.