The BatchCompiler that is a facade to CSharpCodeProvider (CodeProvider
system in general because of VB support) is very dependent on
system.codedom in app/web config. When no such config is present the
BatchCompiler should at least be doing some funky guess work as to how
the CSharpCodeProvider should be configured (maybe the root cause is
that the BatchCompiler shouldn't have this concern at all, and the
compiler options should be somehow passed down to it, but this is for
another thread). At the moment .NET 3.5 and .NET 4 are the two
relevant compiler versions, but .NET 3.5 is always used in case no
system.codedom section is present. I have a simple commit that does
the 'funky guess work'
http://github.com/maxild/spark/commit/8f857fa260dd4743164f81660bfc87f377e7e01b
I have experienced pain both during automated tests where the test
runners that I use (R#,
TDD.NET and command-line) are running on both
CLR 2 and CLR 4 (even though my project is targeting .NET 3.5), and
during my precompile-views step in my build process.
I am beginning to think that precompiling views is a bit too painful.
Here I am also thinking about describing the batch
(SparkBatchDescriptor, SparkBatchConfigurator). This is another thing
that I sometimes gets wrong in my precompile-workflow because I forget
to include pages and partials.
How do other people compile views during development and deployment?
/Morten