Commented Issue: RazorGenerator.MsBuild fails to generate when using NuGet package restore and pacakges folder not in source control [87]

January 13, 2013, 9:17 pm

≫ Next: Edited Issue: Bin deploy the 1.0 and 2.0 binaries with the Vsix [83]

≪ Previous: Edited Issue: RazorGenerator.MsBuild fails to generate when using NuGet package restore and pacakges folder not in source control [87]

$

0

0

I think there is a Catch-22 when using Package Restore and the packages folder is not checked in. The initial install of RazorGenerator.MsBuild adds the "..\packages\**\tools\NuGet.import.targets" import to NuGet.targets, but when the packages folder is not checked in, the RazorGenerator NuGet.import.targets file does not yet exist when the build is initiated. Package restore pulls down the RazorGenerator.MsBuild package, which brings in the import targets file, but I think it it is too late in the build process.

This can be reproduced by installing the RazorGenerator.MsBuild package, deleting the packages folder, and then building the solution - view the build output at normal verbosity and verify that the PrecompileRazorFiles target is never invoked.

One potential solution is for the NuGet installation to add the RazorGenerator.targets file directly to the MVC project itself - then package restore is only responsible for pulling down the binaries.
Comments: Adding the contents of RazorGenerator.targets file (presumably that's what you meant) would certainly help, but it does make the update story a lot messier. I'll check if I can get some advice from the MsBuild experts at work and see if we can make the Imports statement trigger in a deferred manner.

---

Edited Issue: Bin deploy the 1.0 and 2.0 binaries with the Vsix [83]

January 13, 2013, 9:18 pm

≫ Next: Commented Issue: Bin deploy the 1.0 and 2.0 binaries with the Vsix [83]

≪ Previous: Commented Issue: RazorGenerator.MsBuild fails to generate when using NuGet package restore and pacakges folder not in source control [87]

$

0

0

We've fixed this in the MsBuild package. But we could do this with the Vsix too. This would mean we could generate Razor files even if you don't have the runtime GACed

Commented Issue: Bin deploy the 1.0 and 2.0 binaries with the Vsix [83]

January 13, 2013, 9:19 pm

≫ Next: Commented Issue: RazorGenerator.MsBuild fails to generate when using NuGet package restore and pacakges folder not in source control [87]

≪ Previous: Edited Issue: Bin deploy the 1.0 and 2.0 binaries with the Vsix [83]

$

0

0

We've fixed this in the MsBuild package. But we could do this with the Vsix too. This would mean we could generate Razor files even if you don't have the runtime GACed
Comments: Fixed in changeset 28b4b44d4abf

Commented Issue: RazorGenerator.MsBuild fails to generate when using NuGet package restore and pacakges folder not in source control [87]

January 23, 2013, 8:15 am

≫ Next: Commented Issue: Using RazorGenerator in a WinRT project [60]

≪ Previous: Commented Issue: Bin deploy the 1.0 and 2.0 binaries with the Vsix [83]

$

0

0

I think there is a Catch-22 when using Package Restore and the packages folder is not checked in. The initial install of RazorGenerator.MsBuild adds the "..\packages\**\tools\NuGet.import.targets" import to NuGet.targets, but when the packages folder is not checked in, the RazorGenerator NuGet.import.targets file does not yet exist when the build is initiated. Package restore pulls down the RazorGenerator.MsBuild package, which brings in the import targets file, but I think it it is too late in the build process.

This can be reproduced by installing the RazorGenerator.MsBuild package, deleting the packages folder, and then building the solution - view the build output at normal verbosity and verify that the PrecompileRazorFiles target is never invoked.

One potential solution is for the NuGet installation to add the RazorGenerator.targets file directly to the MVC project itself - then package restore is only responsible for pulling down the binaries.
Comments: This gets trickier. The RazorGenerator target depends on the msbuild task in the assembly both of which need to be present at the time the target gets loaded. Even if the target ends up in the project, you'll need to have the assembly checked in alongside for it to work which would defeat the purpose of package restore. I haven't followed up with any of the MsBuild experts I guess now's a good time to do that.

Commented Issue: Using RazorGenerator in a WinRT project [60]

January 23, 2013, 9:21 pm

≫ Next: Closed Issue: When deployed: System.Reflection.ReflectionTypeLoadException [77]

≪ Previous: Commented Issue: RazorGenerator.MsBuild fails to generate when using NuGet package restore and pacakges folder not in source control [87]

$

0

0

I am producing some HTML content for the share charm in WinRT. So I need to precompile the cshtml to .cs in my WinRT project. I'm not entirely clear over the entire process that needs to be used here, but as I understand it I need to install
the RazorGenerator visual studio extension. Unfortunately I can only install that into visual studio 2010?

How do I get it installed into visual studio 2011, so that I can select a custom tool of RazorGenerator?

Secondly RazorGenerator.Templating isn't able to be installed in a WinRT project. So I decompiled the class and I can build that class, but there are some changes required in the write function. It should look like this:


public void Write(object value)
{
if (value == null)
return;
#if NETFX_CORE
MethodInfo method = null;

var methods = value.GetType().GetTypeInfo().GetDeclaredMethods("ToString");

if (methods != null)
{
foreach (MethodInfo methodInfo in methods)
{
if (methodInfo.GetParameters().Count() == 1 && methodInfo.GetParameters()[0].ParameterType == typeof (IFormatProvider))
{
method = methodInfo;
}
}
}
#else
MethodInfo method = value.GetType().GetMethod("ToString", new Type[1]
{
typeof (IFormatProvider)
});
#endif
string textToAppend;
if (method == (MethodInfo)null)
textToAppend = value.ToString();
else
textToAppend = (string)method.Invoke(value, new object[1]
{
(object) CultureInfo.InvariantCulture
});
this.WriteLiteral(textToAppend);
}


And then it works fine. Hopefully a WinRT specific version of the nuget project can be built at some point, but in the meantime if I include that class myself, I will be fine. Is just a matter of getting the razor generator functioning. Hope
someone is able to help with that.

Thanks,

Stefan
Comments: Do you think you could send this as a patch file or a pull request?

Closed Issue: When deployed: System.Reflection.ReflectionTypeLoadException [77]

January 23, 2013, 9:28 pm

≫ Next: Commented Issue: System.Web.Mvc.Ajax and System.Web.Mvc.Html are added for WebPages project only [74]

≪ Previous: Commented Issue: Using RazorGenerator in a WinRT project [60]

$

0

0

I have everything working fine with mvc.razor generator. Views from my library project show up fine in my web-site. It is a .net 4.0, MVC4, EF5 project. The app pool is set to .net 4.0 in IIS.

When I deploy to the server, I am getting an exception when it tries to load the PrecompiledMvcEngine type.
Here is the exception (I have attached the full output of error in attachments):
Source Error:

An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.

Stack Trace:


[ReflectionTypeLoadException: Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information.]
System.Reflection.RuntimeModule.GetTypes(RuntimeModule module) +0
System.Reflection.Assembly.GetTypes() +159
RazorGenerator.Mvc.PrecompiledMvcEngine..ctor(Assembly assembly, String baseVirtualPath) +1209
RazorGenerator.Mvc.PrecompiledMvcEngine..ctor(Assembly assembly) +53
HealthJobs.Common.App_Start.RazorGeneratorMvcStart.Start() in E:\UserFiles\sheam\Documents\Visual Studio 2010\Projects\MyProj\Project.Common_vs2010\App_Start\RazorGeneratorMvcStart.cs:11

As you can see this is coming from my common project.


Here are the contents of the bin director:


2012-10-17 09:06 PM <DIR> .
2012-10-17 09:06 PM <DIR> ..
2012-10-10 12:51 AM 105,528 Antlr3.Runtime.dll
2012-10-09 07:05 PM 1,118,296 EntityFramework.dll
2012-10-16 01:26 PM 359,424 MyProj.Common_vs2010.dll
2012-10-16 01:26 PM 112,128 MyProj.Common_vs2010.pdb
2012-10-09 06:46 PM 45,416 Microsoft.Web.Infrastructure.dll
2012-10-17 09:06 PM 29,696 MyProj.dll
2012-10-17 09:06 PM 42,496 MyProj.pdb
2012-10-13 08:04 PM 15,872 Mvc.Mailer.dll
2012-10-09 06:46 PM 374,784 Newtonsoft.Json.dll
2012-10-09 06:56 PM 15,872 RazorGenerator.Mvc.dll
2012-10-09 06:46 PM 180,832 System.Net.Http.dll
2012-10-09 06:46 PM 168,544 System.Net.Http.Formatting.dll
2012-10-09 06:46 PM 16,480 System.Net.Http.WebRequest.dll
2012-10-09 06:46 PM 138,328 System.Web.Helpers.dll
2012-10-09 06:46 PM 323,168 System.Web.Http.dll
2012-10-09 06:46 PM 73,312 System.Web.Http.WebHost.dll
2012-10-09 06:46 PM 506,976 System.Web.Mvc.dll
2012-10-10 12:51 AM 54,912 System.Web.Optimization.dll
2012-10-09 06:46 PM 264,792 System.Web.Razor.dll
2012-10-09 06:46 PM 41,048 System.Web.WebPages.Deployment.dll
2012-10-09 06:46 PM 204,376 System.Web.WebPages.dll
2012-10-09 06:46 PM 39,512 System.Web.WebPages.Razor.dll
2012-10-09 06:56 PM 8,704 WebActivator.dll
2012-10-10 12:51 AM 963,640 WebGrease.dll
24 File(s) 5,204,136 bytes
2 Dir(s) 1,519,661,289,472 bytes free

RazorGenerator.Mvc.dll exists in there, so I am not sure why it can't load the type.

The server is a fresh install if W7 Pro.

Thanks.
~S
Comments: Please reopen if this is still an issue

Commented Issue: System.Web.Mvc.Ajax and System.Web.Mvc.Html are added for WebPages project only [74]

January 23, 2013, 9:32 pm

≫ Next: Closed Issue: System.Web.Mvc.Ajax and System.Web.Mvc.Html are added for WebPages project only [74]

≪ Previous: Closed Issue: When deployed: System.Reflection.ReflectionTypeLoadException [77]

$

0

0

IF your project is not a MVC but just using Razor WebPages (see Umbraco macros) these namespaces are added for nothing causing an exception when compiling.
Make them configurable
Comments: Not seeing this. These are the ones that are added in my test app: using System; using System.Collections.Generic; using System.IO; using System.Linq; using System.Net; using System.Text; using System.Web; using System.Web.Helpers; using System.Web.Security; using System.Web.UI; using System.Web.WebPages; using System.Web.WebPages.Html;

Closed Issue: System.Web.Mvc.Ajax and System.Web.Mvc.Html are added for WebPages project only [74]

January 23, 2013, 9:32 pm

≫ Next: Edited Issue: Removal of SuffixClassNames : bool [66]

≪ Previous: Commented Issue: System.Web.Mvc.Ajax and System.Web.Mvc.Html are added for WebPages project only [74]

$

0

0

IF your project is not a MVC but just using Razor WebPages (see Umbraco macros) these namespaces are added for nothing causing an exception when compiling.
Make them configurable
Comments: Feel free to reopen if this continues to be an issue. Preferably with a sample app

---

Edited Issue: Removal of SuffixClassNames : bool [66]

January 23, 2013, 9:49 pm

≫ Next: Commented Issue: Removal of SuffixClassNames : bool [66]

≪ Previous: Closed Issue: System.Web.Mvc.Ajax and System.Web.Mvc.Html are added for WebPages project only [74]

$

0

0

Hey

I see SuffixClassNames : bool was removed after it was pulled in.

I really need this feature. I tend to not name my views Index, Edit, List etcetera but give them more meaningful names. However these names often clash with my domain entities. I therefor pushed this directive to explicitly (but optionally) suffix the type of view to the generated classname.

Was there any particular reason this feature was stripped ?

Thanks!

Commented Issue: Removal of SuffixClassNames : bool [66]

January 23, 2013, 9:49 pm

≫ Next: Edited Issue: Create public property to expose PrecompiledMvcView _virtualPath [65]

≪ Previous: Edited Issue: Removal of SuffixClassNames : bool [66]

$

0

0

Hey

I see SuffixClassNames : bool was removed after it was pulled in.

I really need this feature. I tend to not name my views Index, Edit, List etcetera but give them more meaningful names. However these names often clash with my domain entities. I therefor pushed this directive to explicitly (but optionally) suffix the type of view to the generated classname.

Was there any particular reason this feature was stripped ?

Thanks!

Comments: Fixed in changeset da5af667e8a8

Edited Issue: Create public property to expose PrecompiledMvcView _virtualPath [65]

January 23, 2013, 9:49 pm

≫ Next: Commented Issue: Create public property to expose PrecompiledMvcView _virtualPath [65]

≪ Previous: Commented Issue: Removal of SuffixClassNames : bool [66]

$

0

0

It would be very help to create public property to expose PrecompiledMvcView _virtualPath with a private set.

We have a custom ViewStartPageExtensions class that provides an extension point for custom layout implementations. The current implementation casts the IView to BuildManagerCompiledView and checks the ViewPath. Unfortunately, casting the IView to PrecompiledMvcView does not provide access to _virtualPath with the needed information.


_ViewStart.cshtml example:

@{
Layout = this.GetLayout("_SiteLayout");
}

Extension:

public static string GetLayout(this ViewStartPage viewStartPage, string layoutName)
{
if (viewStartPage.Context.Request.IsAjaxRequest())
{
return null;
}

if (layoutName.StartsWith("~"))
return layoutName;

return GetViewVirtualPath(viewStartPage.ViewContext, layoutName);
}

private static string GetViewVirtualPath(ViewContext viewContext, string layoutName)
{
var viewResult = ViewEngines.Engines.FindView(viewContext.Controller.ControllerContext, layoutName, string.Empty);

if (viewResult != null)
{
var view = viewResult.View as BuildManagerCompiledView;

if (view != null)
return view.ViewPath;

var precompiledView = viewResult.View as PrecompiledMvcView;

// Proposed public property to expose value of _virtualPath
if (precompiledView != null)
return precompiledView.VirtualPath;
}

return null;
}

Is there a reason the _virtualPath is private? The value is already annotated in the generated.cs PageVirtualPathAttribute but I want to avoid having to write a custom provider to cache this information separately for lookups. Getting the value directly from the ViewEngines would be preferable.

Thanks.

Commented Issue: Create public property to expose PrecompiledMvcView _virtualPath [65]

January 23, 2013, 9:49 pm

≫ Next: Commented Issue: Removal of SuffixClassNames : bool [66]

≪ Previous: Edited Issue: Create public property to expose PrecompiledMvcView _virtualPath [65]

$

0

0

It would be very help to create public property to expose PrecompiledMvcView _virtualPath with a private set.

We have a custom ViewStartPageExtensions class that provides an extension point for custom layout implementations. The current implementation casts the IView to BuildManagerCompiledView and checks the ViewPath. Unfortunately, casting the IView to PrecompiledMvcView does not provide access to _virtualPath with the needed information.


_ViewStart.cshtml example:

@{
Layout = this.GetLayout("_SiteLayout");
}

Extension:

public static string GetLayout(this ViewStartPage viewStartPage, string layoutName)
{
if (viewStartPage.Context.Request.IsAjaxRequest())
{
return null;
}

if (layoutName.StartsWith("~"))
return layoutName;

return GetViewVirtualPath(viewStartPage.ViewContext, layoutName);
}

private static string GetViewVirtualPath(ViewContext viewContext, string layoutName)
{
var viewResult = ViewEngines.Engines.FindView(viewContext.Controller.ControllerContext, layoutName, string.Empty);

if (viewResult != null)
{
var view = viewResult.View as BuildManagerCompiledView;

if (view != null)
return view.ViewPath;

var precompiledView = viewResult.View as PrecompiledMvcView;

// Proposed public property to expose value of _virtualPath
if (precompiledView != null)
return precompiledView.VirtualPath;
}

return null;
}

Is there a reason the _virtualPath is private? The value is already annotated in the generated.cs PageVirtualPathAttribute but I want to avoid having to write a custom provider to cache this information separately for lookups. Getting the value directly from the ViewEngines would be preferable.

Thanks.
Comments: Fixed in changeset 54402c127ed1

Commented Issue: Removal of SuffixClassNames : bool [66]

January 23, 2013, 9:51 pm

≫ Next: Commented Issue: Incorrect namespace for viewmodels [68]

≪ Previous: Commented Issue: Create public property to expose PrecompiledMvcView _virtualPath [65]

$

0

0

Hey

I see SuffixClassNames : bool was removed after it was pulled in.

I really need this feature. I tend to not name my views Index, Edit, List etcetera but give them more meaningful names. However these names often clash with my domain entities. I therefor pushed this directive to explicitly (but optionally) suffix the type of view to the generated classname.

Was there any particular reason this feature was stripped ?

Thanks!

Comments: @Mpdreamz, sorry for taking this long to get to this. I guess the other alternative can live, but your solution should work. I named the directive ClassSuffix but it should behave like your attribute.

Commented Issue: Incorrect namespace for viewmodels [68]

January 23, 2013, 9:52 pm

≫ Next: Closed Issue: Incorrect namespace for viewmodels [68]

≪ Previous: Commented Issue: Removal of SuffixClassNames : bool [66]

$

0

0

I have a few cases where the viewmodel and a view has the same name (in different namespaces) like this:

MyProject.Models.ThankYou <- viewmodel
MyProject.Views.Signup.ThankYou <- razor view

The razor template has the usual "@model ThankYou" in the beginning, and this resolves to MyProject.Models.ThankYou but the generated.cs is

public class ThankYou: MyWebRole.Helpers.WebViewPage<ThankYou>

which means that the <ThankYou> refers to itself, not the viewmodel.

When I specify the full namespace and class it compiles wonderfully.

The quick fix I guess would be to specify the full namespace and class as Razor would interpret it, instead of just class in the generator?
Comments: We really can't do much about the namespace here. The work item @Mpdreamz talks about would also be an alternate workaround for this.

Closed Issue: Incorrect namespace for viewmodels [68]

January 23, 2013, 9:53 pm

≫ Next: Closed Issue: RazorGenerator not finding views in VS2012 [71]

≪ Previous: Commented Issue: Incorrect namespace for viewmodels [68]

$

0

0

I have a few cases where the viewmodel and a view has the same name (in different namespaces) like this:

MyProject.Models.ThankYou <- viewmodel
MyProject.Views.Signup.ThankYou <- razor view

The razor template has the usual "@model ThankYou" in the beginning, and this resolves to MyProject.Models.ThankYou but the generated.cs is

public class ThankYou: MyWebRole.Helpers.WebViewPage<ThankYou>

which means that the <ThankYou> refers to itself, not the viewmodel.

When I specify the full namespace and class it compiles wonderfully.

The quick fix I guess would be to specify the full namespace and class as Razor would interpret it, instead of just class in the generator?
Comments: Feel free to open if you think this still needs addressing. But there are workarounds for this that would work.

---

Closed Issue: RazorGenerator not finding views in VS2012 [71]

January 23, 2013, 10:06 pm

≫ Next: Created Issue: MVC4 breaks RazorGenerator.Testing [95]

≪ Previous: Closed Issue: Incorrect namespace for viewmodels [68]

$

0

0

When opening, compiling and running a VS2010 MVC.net 3 project in VS2012, the views cannot be found.
The project compiles correct, however the RazorGenerator ViewEngine does not find the views, or does not even kick in...
Comments: * There're are issues in some old Mvc project templates where the SpecificVersion for System.Web.WebPages assembly is set to false. This causes issues. To fix this, re-add the System.Web.WebPages assembly pointing to the right version (1.0 for Mvc 3 projects, 2.0 for Mvc 4 projects) * RazorGenerator 1.5 targets the parser based on the version of Mvc used. So issues with incorrect view generation should be fixed. * For Mvc apps consuming RazorGenerator.MVC, ensure it has the right binding redirects in the root web.config. The RazorGenerator assembly is compiled against Mvc 3, but the right set of binding redirects should ensure it does the view lookup correctly. If you're still seeing this issue, please feel free to reopen this

Created Issue: MVC4 breaks RazorGenerator.Testing [95]

January 25, 2013, 12:39 am

≫ Next: Commented Issue: MVC4 breaks RazorGenerator.Testing [95]

≪ Previous: Closed Issue: RazorGenerator not finding views in VS2012 [71]

$

0

0

It's as simple as that.

I upgraded the MVC3 project I had been working on to MVC4, and after having resolved all the references etc found my unit tests were failing - deep in the bowels of MVC, the AjaxHelper constructor was throwing an ArgumentNullException (note: NOT a NullReferenceException) because the view context was null.

To prove it wasn't me going mad I went and created 2 vanilla empty MVC sites - one in MVC3 and one in MVC4. I then added a class library to each one and nugetted NUnit.

Then I added the latest nuget packages for RazorGenerator.Mvc to the respective web apps, and RazorGenerator.Testing to the unit test projects.

I added a HelloWorldController to each web app, and right clicked on the Index method to create the View. Just to make sure the view was correct I added some Hello World text to the view so we could be sure that it was this view being rendered when run in the browser.

I then created a unit test in each unit test folder, which simply instantiates the view Index (which works), and then calls the RenderAsHtml<TModel>(model) extension method defined in the testing package (which breaks in MVC4, but not in MVC3).

Sure enough, MVC3 worked fine, but MVC4 gave me the error as described above.

Further investigation led me to find that it seems to be the way that the ReflectionMagic package interacts with System.Web.WebPages 2.0, when the various mock objects are being created, prior to rendering.

The ironic thing is that copying the code out of the site (http://razorgenerator.codeplex.com/SourceControl/changeset/view/da5af667e8a8#RazorGenerator.Testing/WebViewPageExtensions.cs) and placing it in the same assembly as the test code actually seemed to fix this! However, a very important caveat is that the code MUST be in the same assembly - if it's in, say, a testing infrastructure common assembly, this will not only cause MVC to throw an exception - it will crash the NUnit agent process with an ExecutionEngineException...

Obviously this is quite a serious issue, as it would be much better to use the package as-is, rather than have to go to codeplex and copy the code manually into my test project.

Commented Issue: MVC4 breaks RazorGenerator.Testing [95]

January 25, 2013, 4:53 pm

≫ Next: Commented Issue: MVC4 breaks RazorGenerator.Testing [95]

≪ Previous: Created Issue: MVC4 breaks RazorGenerator.Testing [95]

$

0

0

It's as simple as that.

I upgraded the MVC3 project I had been working on to MVC4, and after having resolved all the references etc found my unit tests were failing - deep in the bowels of MVC, the AjaxHelper constructor was throwing an ArgumentNullException (note: NOT a NullReferenceException) because the view context was null.

To prove it wasn't me going mad I went and created 2 vanilla empty MVC sites - one in MVC3 and one in MVC4. I then added a class library to each one and nugetted NUnit.

Then I added the latest nuget packages for RazorGenerator.Mvc to the respective web apps, and RazorGenerator.Testing to the unit test projects.

I added a HelloWorldController to each web app, and right clicked on the Index method to create the View. Just to make sure the view was correct I added some Hello World text to the view so we could be sure that it was this view being rendered when run in the browser.

I then created a unit test in each unit test folder, which simply instantiates the view Index (which works), and then calls the RenderAsHtml<TModel>(model) extension method defined in the testing package (which breaks in MVC4, but not in MVC3).

Sure enough, MVC3 worked fine, but MVC4 gave me the error as described above.

Further investigation led me to find that it seems to be the way that the ReflectionMagic package interacts with System.Web.WebPages 2.0, when the various mock objects are being created, prior to rendering.

The ironic thing is that copying the code out of the site (http://razorgenerator.codeplex.com/SourceControl/changeset/view/da5af667e8a8#RazorGenerator.Testing/WebViewPageExtensions.cs) and placing it in the same assembly as the test code actually seemed to fix this! However, a very important caveat is that the code MUST be in the same assembly - if it's in, say, a testing infrastructure common assembly, this will not only cause MVC to throw an exception - it will crash the NUnit agent process with an ExecutionEngineException...

Obviously this is quite a serious issue, as it would be much better to use the package as-is, rather than have to go to codeplex and copy the code manually into my test project.


Comments: Strange. If you manage to figure out the root of the problem and have a fix which works with both MVC3 and MVC4, please send a pull request and we'll get that in. We have limited time to work on RazorGenerator, so we can use any help we can get :)

Commented Issue: MVC4 breaks RazorGenerator.Testing [95]

January 27, 2013, 7:41 pm

≫ Next: Commented Issue: RazorGenerator.MsBuild fails to generate when using NuGet package restore and pacakges folder not in source control [87]

≪ Previous: Commented Issue: MVC4 breaks RazorGenerator.Testing [95]

$

0

0

It's as simple as that.

I upgraded the MVC3 project I had been working on to MVC4, and after having resolved all the references etc found my unit tests were failing - deep in the bowels of MVC, the AjaxHelper constructor was throwing an ArgumentNullException (note: NOT a NullReferenceException) because the view context was null.

To prove it wasn't me going mad I went and created 2 vanilla empty MVC sites - one in MVC3 and one in MVC4. I then added a class library to each one and nugetted NUnit.

Then I added the latest nuget packages for RazorGenerator.Mvc to the respective web apps, and RazorGenerator.Testing to the unit test projects.

I added a HelloWorldController to each web app, and right clicked on the Index method to create the View. Just to make sure the view was correct I added some Hello World text to the view so we could be sure that it was this view being rendered when run in the browser.

I then created a unit test in each unit test folder, which simply instantiates the view Index (which works), and then calls the RenderAsHtml<TModel>(model) extension method defined in the testing package (which breaks in MVC4, but not in MVC3).

Sure enough, MVC3 worked fine, but MVC4 gave me the error as described above.

Further investigation led me to find that it seems to be the way that the ReflectionMagic package interacts with System.Web.WebPages 2.0, when the various mock objects are being created, prior to rendering.

The ironic thing is that copying the code out of the site (http://razorgenerator.codeplex.com/SourceControl/changeset/view/da5af667e8a8#RazorGenerator.Testing/WebViewPageExtensions.cs) and placing it in the same assembly as the test code actually seemed to fix this! However, a very important caveat is that the code MUST be in the same assembly - if it's in, say, a testing infrastructure common assembly, this will not only cause MVC to throw an exception - it will crash the NUnit agent process with an ExecutionEngineException...

Obviously this is quite a serious issue, as it would be much better to use the package as-is, rather than have to go to codeplex and copy the code manually into my test project.


Comments: Does your test project have the right binding redirects to Mvc? If you've added the Mvc reference via Microsoft.AspNet.Mvc package, NuGet would add it for you, if you added the reference from GAC have to manually add it by calling Add-BindingRedirect (or copying it from your web.config). I tested this using XUnit and VS 2012's test runner and adding the binding redirects fixed it for me.

Commented Issue: RazorGenerator.MsBuild fails to generate when using NuGet package restore and pacakges folder not in source control [87]

February 1, 2013, 1:24 pm

≫ Next: Created Issue: Custom tool error: Unable to load one or more of the requested types. [96]

≪ Previous: Commented Issue: MVC4 breaks RazorGenerator.Testing [95]

$

0

0

I think there is a Catch-22 when using Package Restore and the packages folder is not checked in. The initial install of RazorGenerator.MsBuild adds the "..\packages\**\tools\NuGet.import.targets" import to NuGet.targets, but when the packages folder is not checked in, the RazorGenerator NuGet.import.targets file does not yet exist when the build is initiated. Package restore pulls down the RazorGenerator.MsBuild package, which brings in the import targets file, but I think it it is too late in the build process.

This can be reproduced by installing the RazorGenerator.MsBuild package, deleting the packages folder, and then building the solution - view the build output at normal verbosity and verify that the PrecompileRazorFiles target is never invoked.

One potential solution is for the NuGet installation to add the RazorGenerator.targets file directly to the MVC project itself - then package restore is only responsible for pulling down the binaries.
Comments: I worked around the issue by following the pattern that the MSBuild Community Tasks NuGet package uses. 1. Create a top-level .razorgenerator solution folder 2. Copy the RazorGenerator.targets and RazorGenerator.MsBuild.dll files 3. Fix up .csproj import to point to the new location of the .targets file This allows the NuGet package restore to run before trying to build that project.