Quantcast
Channel: RazorGenerator Issue Tracker Rss Feed
Viewing all 525 articles
Browse latest View live

Commented Unassigned: MsBuild task does not correctly generate namespaces for files in folders beginning with digits [106]

$
0
0
For a view file located in a path:
Views\123\Index.cshtml

The FileNamespace in VS is generated as
Views._123

While the MsBuild task does not include the leading underscore and generates it as
Views.123

This prevents compilation.
Comments: Fixed in changeset 95f0591174e85ba7333c8c42dda513904e0a7613

Commented Issue: RazorGenerator.MSBuild is too aggressive when finding .cshtml files [90]

$
0
0
The MSBuild extension is trying to pre-compile *all* .cshtml files it can find under the project root, instead of just the ones that are in the project. This is a bit of a problem when working in a hybrid app where a CMS such as Umbraco is managing it's own razor templates in the same web application.

(e.g. App_Data\TEMP\Razor folder is a cache folder used by umbraco and is not part of my MVC project)
Comments: This definitely causes an issue when using Visual Studio 2010's publish functionality (I can't vouch for 2012). In these cases, the files that will be deployed, which can include .cshtml files, are copied in to a directory under the "obj" folder. Razor Generator will pick up these files by default and it causes problems when trying to pre-compile views. Adding the following to my project file did resolve the issue, but caused all of my Razor views to show up twice in the solution explorer (since RazorSrcFiles get treated as a new build action): ``` <ItemGroup> <RazorSrcFiles Include="**\*.cshtml" Exclude="obj\**\*.cshtml" /> </ItemGroup> ``` I will try the suggestion from the previous comment and create a separate targets file for the ItemGroup

Commented Issue: Error when use "DisplayTemplates\PersonViewModel.cs" and "PersonViewModel.cshtml" (Same name) [103]

$
0
0
I followed exactly the steps described in this post.
http://stacktoheap.com/blog/2013/01/19/precompiling-razor-views-in-asp-dot-net-mvc-3/

But the error is displayed below

> ASP.NET runtime error: There is no build provider registered for the extension '.cshtml'. You can register one in the <compilation><buildProviders> section in machine.config or web.config. Make sure is has a BuildProviderAppliesToAttribute attribute which includes the value 'Web' or 'All'.


__What am I doing wrong?__
Comments: I had this same issue when trying to use DisplayTemplates for DateTime properties and here's how I fixed it: Recreate Issue: Create a DateTime.cshtml file in the DisplayTemplates folder: ``` @model DateTime @MvcHtmlString.Create(Model.Date.ToShortDateString()) ``` Try to compile and you'll receive errors: '(AssemblyName).Views.Shared.DisplayTemplates.DateTime' does not contain a definition for 'Date' and no extension method 'Date' accepting a first argument of type '(AssemblyName).Views.Shared.DisplayTemplates.DateTime' could be found. Why this is happening: Because the view page is getting compiled and has the same name as the model, the compiler tries to use the compiled view page as the model for itself. If you look carefully at the error you'll see that it's trying to access the .Date property of the compiled DateTime view, which will throw an error because it doesn't exist. How to fix it so that the right model is used: Explicity type out the namespace for the model that you want to use: ``` @model System.DateTime <- Instead of just DateTime, give the full namespace @MvcHtmlString.Create(Model.Date.ToShortDateString()) ``` This will now compile as expected.

Created Unassigned: PrecompiledMvcEngine ctor masks baseVirtualPath [107]

$
0
0
Hi,

there seems to have crept in a mistake in commit b0a2e6258 (Default implementation of IViewPageActivator to avoid logic duplication. Work Item: 105) where the two parameter constructor for PrecompiledMvcEngine does not pass the given baseVirtualPath parameter when calling the three parameter overload, instead it always passes null.

The attached patch should fix this.

Closed Unassigned: PrecompiledMvcEngine ctor masks baseVirtualPath [107]

$
0
0
Hi,

there seems to have crept in a mistake in commit b0a2e6258 (Default implementation of IViewPageActivator to avoid logic duplication. Work Item: 105) where the two parameter constructor for PrecompiledMvcEngine does not pass the given baseVirtualPath parameter when calling the three parameter overload, instead it always passes null.

The attached patch should fix this.
Comments: Good catch! Fixed in v2.0.1

Commented Issue: RazorGenerator not generating complete code on .cshtml [102]

$
0
0
I'm running into an issue where it appears that razor generator is not generating complete code for some of my Shared Templates.

These are templates that are created from the "MvcSiteMap" package.

The Razor Code is listed here:
```
@model MvcSiteMapProvider.Web.Html.Models.MenuHelperModel
@using System.Web.Mvc.Html
@using MvcSiteMapProvider.Web.Html.Models
<ul id="menu">
@foreach (var node in Model.Nodes) {
<li id="@node.MetaAttributes["id"]">@Html.DisplayFor(m => node)
@if (node.Children.Any()) {
@Html.DisplayFor(m => node.Children)
}
</li>
}
</ul>
```

what is being generated by RazorGenerator is:
```
#pragma warning disable 1591
//------------------------------------------------------------------------------
// <auto-generated>
// This code was generated by a tool.
// Runtime Version:4.0.30319.18033
//
// Changes to this file may cause incorrect behavior and will be lost if
// the code is regenerated.
// </auto-generated>
//------------------------------------------------------------------------------

namespace TP2012MVC.Views.Shared.DisplayTemplates
{
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.Mvc;
using System.Web.Mvc.Ajax;

#line 2 "..\..\Views\Shared\DisplayTemplates\MenuHelperModel.cshtml"
using System.Web.Mvc.Html;

#line default
#line hidden
using System.Web.Routing;
using System.Web.Security;
using System.Web.UI;
using System.Web.WebPages;
using MvcSiteMapProvider.Web.Html;

#line 3 "..\..\Views\Shared\DisplayTemplates\MenuHelperModel.cshtml"
using MvcSiteMapProvider.Web.Html.Models;

#line default
#line hidden

[System.CodeDom.Compiler.GeneratedCodeAttribute("RazorGenerator", "1.5.4.0")]
public class MenuHelperModel : System.Web.WebPages.HelperPage
{
}
}
```

When the compiled code is being executed, the custom "id=@node....." is not being generated in the html.

Going through the generated models, I'm noticing that there are several of these templates that the class generated is empty.

This is RazorGenerator.Mvc 1.5.5.0
RazorGenerator Extension 1.5.4
Visual Studio 2012
MVC 4 (asp.net 4.5 application)

Any advice would be appreciated.
Comments: `@* Generator: MvcView *@` Works for me. Saved me hours of work! Thank you!

Edited Unassigned: MsBuild task does not correctly generate namespaces for files in folders beginning with digits [106]

$
0
0
For a view file located in a path:
Views\123\Index.cshtml

The FileNamespace in VS is generated as
Views._123

While the MsBuild task does not include the leading underscore and generates it as
Views.123

This prevents compilation.

Commented Unassigned: MsBuild task does not correctly generate namespaces for files in folders beginning with digits [106]

$
0
0
For a view file located in a path:
Views\123\Index.cshtml

The FileNamespace in VS is generated as
Views._123

While the MsBuild task does not include the leading underscore and generates it as
Views.123

This prevents compilation.
Comments: Fixed in changeset 78df079cffaae189759096ac6d66217fba2ba238

Created Unassigned: Helper in App_Code does not compile [108]

$
0
0
Hi,

I've setup an empty MVC project and RazorGenerator (2.0.1) and RazorGenerator (1.5.3.0) as explained in http://www.dzone.com/links/r/precompiling_razor_views_in_aspnet_mvc_3.html.
(in short: add packages and add build targets and then voila)

It works fine except when I put a simple helper to App_Code like this
``` CS
@helper FailMiserably()
{
var ctx = Context;
}
```

It gives "The name 'Context' does not exists in the current context". It works fine if I turn RazorGenerator off.

I've also tried
``` CS
@* Generator: MvcHelper *@
```

but does not solve the problem.

I looked at the generated cs code in `obj\CodeGen\App_Code`. I saw that helper class `MyHelper` does not inherit from `HelperPage` class. Is this normal?

Created Unassigned: 2.0.1 Razor Generator Issues (MSBuild, MVC, App_Code) [109]

$
0
0
Hi,

We found there are few issues with 2.0.1 Razor Generator MSBuild task.

__Issue One:__
The App_Code/{helper}.cshtml can not compile into the correct place even by using _RazorViewsCodeGenDirectory_. So the MSBuild task always complains failed to found source files.

__Issue Two:__
Event, we manually copy the generated files (helloWorldHelper.cshtml.cs) into the correct place, the MSBuild task does not compile it into the assembly.

Looking for answers.

Kind regards.


Edited Unassigned: 2.0.1 Razor Generator Issues (MSBuild, MVC, App_Code) [109]

$
0
0
Hi,

We found there are few issues with 2.0.1 Razor Generator MSBuild task.

__Issue One:__
The App_Code/{helper}.cshtml can not compile into the correct place even by using _RazorViewsCodeGenDirectory_. So the MSBuild task always complains failed to locate source files.

__Issue Two:__
Event, we manually copy the generated file (helloWorldHelper.cshtml.cs) into the correct place, the MSBuild task does not compile it into the assembly.

Looking for answers.

Kind regards.

Jing

Created Unassigned: 2.0.1 load precompiled vies from all referenced assemblies [110]

$
0
0
Instead of doing
```
assembly.GetTypes()
```
there should be a like of
```
foreach (var assemblyName in assembly.GetReferencedAssemblies()) {
// load types from assemblyName
}
```
That way you can simply reference assemblies with precompiled views and forget about the hassle.

Edited Unassigned: 2.0.1 Load precompiled views from all referenced assemblies [110]

$
0
0
Instead of doing
```
assembly.GetTypes()
```
there should be a like of
```
foreach (var assemblyName in assembly.GetReferencedAssemblies()) {
// load types from assemblyName
}
```
That way you can simply reference assemblies with precompiled views and forget about the hassle.

Created Unassigned: 2.0.1 Make PageVirtualPathAttribute based on namespace [111]

$
0
0
Make PageVirtualPathAttribute value based on namespace instead of folder path.

Namespaces are more versatile in three ways:
* They obviously can mirror folder path since by default each folder is a "namespace provider"
* Some folders might not have "namespace provider" attribute giving more space to maneuver
* A separate project with precompiled views can have a different namespace (a sub-namespace that is) from the main MVC project. This way, for instance, project Areas could be moved into separate assembly allowing for better structuring of a project (combined with issue #110)

Commented Unassigned: 2.0.1 Load precompiled views from all referenced assemblies [110]

$
0
0
Instead of doing
```
assembly.GetTypes()
```
there should be a like of
```
foreach (var assemblyName in assembly.GetReferencedAssemblies()) {
// load types from assemblyName
}
```
That way you can simply reference assemblies with precompiled views and forget about the hassle.
Comments: I think this would affect delay loaded assemblies. Bin-placed assemblies are eagerly loaded, but doing this would also load GACed assemblies into the AppDomain earlier than necessary. Correct me if I'm wrong.

Commented Unassigned: 2.0.1 Load precompiled views from all referenced assemblies [110]

$
0
0
Instead of doing
```
assembly.GetTypes()
```
there should be a like of
```
foreach (var assemblyName in assembly.GetReferencedAssemblies()) {
// load types from assemblyName
}
```
That way you can simply reference assemblies with precompiled views and forget about the hassle.
Comments: Yes indeed, this method does load referenced assemblies eagerly. I meant to write CurrentAppDomain.GetAssemblies() instead, my bad :)

Edited Unassigned: 2.0.1 Load precompiled views from all referenced assemblies [110]

$
0
0
Instead of doing
```
assembly.GetTypes()
```
there should be a like of
```
foreach (var assemblyName in assembly.GetReferencedAssemblies()) {
// load types from assemblyName
}
```
That way you can simply reference assemblies with precompiled views and forget about the hassle.

**Update**

Ofcourse I meant CurrentAppDomain.GetAssemblies() instead of Assembly.GetReferencedAssemblies()

Created Unassigned: Workaround for bug in Mono framework [112]

$
0
0
Mono's implementation of System.Web is crap (see https://github.com/mono/mono/blob/master/mcs/class/System.Web/System.Web.Configuration_2.0/WebConfigurationHost.cs#L194 for an example on "how to write terrible code").

When MvcWebConfigTransformer tries to use WebConfigurationManager.OpenMappedWebConfiguration, it crashes at the location linked above. This prevents compilation of views under Mono at all. There isn't much RazorGenerator can do to fix this at the source (short of reimplementing System.Web).

So in order to work around this issue, I'm suggesting that line 44 to line 64 of MvcWebConfigTransformer.cs is wrapped in a try-catch, such that the code becomes:

```
try
{
var config = WebConfigurationManager.OpenMappedWebConfiguration(configFileMap, directoryVirtualPath);

// We use dynamic here because we could be dealing both with a 1.0 or a 2.0 RazorPagesSection, which
// are not type compatible (http://razorgenerator.codeplex.com/workitem/26)
dynamic section = config.GetSection(RazorPagesSection.SectionName);
if (section != null)
{
string baseType = section.PageBaseType;
if (!DefaultBaseType.Equals(baseType, StringComparison.OrdinalIgnoreCase))
{
_transformers.Add(new SetBaseType(baseType));
}

if (section != null)
{
foreach (NamespaceInfo n in section.Namespaces)
{
razorHost.NamespaceImports.Add(n.Namespace);
}
}
}
}
catch (IndexOutOfRangeException)
{
// Bug in Mono framework.
// Configure namespaces using the RazorGenerator directives file instead.
}
```

As stated in the code above, users can specify the namespaces using the directives file (which I've tested to confirm works). I feel as though this is an appropriate workaround given that:

a) There's not much RazorGenerator can do to work around the issue, other than implementing code to search for Web.config and use an XML reader to get the namespaces out.
b) There's an appropriate and easy workaround (using the directives file), for the small percentages of users using RazorGenerator with Mono.
c) Mono's implementation of System.Web and System.Web.Configuration is terrible in many other ways, so there's not much point trying to fix the issue upstream in Mono (especially given that I've already worked around several other bugs related to their implementation of System.Web).

At the moment I've built a version of RazorGenerator with this try-catch in it, but obviously long term I want to discard my patch and just use the upstream RazorGenerator version.

Commented Unassigned: Workaround for bug in Mono framework [112]

$
0
0
Mono's implementation of System.Web is crap (see https://github.com/mono/mono/blob/master/mcs/class/System.Web/System.Web.Configuration_2.0/WebConfigurationHost.cs#L194 for an example on "how to write terrible code").

When MvcWebConfigTransformer tries to use WebConfigurationManager.OpenMappedWebConfiguration, it crashes at the location linked above. This prevents compilation of views under Mono at all. There isn't much RazorGenerator can do to fix this at the source (short of reimplementing System.Web).

So in order to work around this issue, I'm suggesting that line 44 to line 64 of MvcWebConfigTransformer.cs is wrapped in a try-catch, such that the code becomes:

```
try
{
var config = WebConfigurationManager.OpenMappedWebConfiguration(configFileMap, directoryVirtualPath);

// We use dynamic here because we could be dealing both with a 1.0 or a 2.0 RazorPagesSection, which
// are not type compatible (http://razorgenerator.codeplex.com/workitem/26)
dynamic section = config.GetSection(RazorPagesSection.SectionName);
if (section != null)
{
string baseType = section.PageBaseType;
if (!DefaultBaseType.Equals(baseType, StringComparison.OrdinalIgnoreCase))
{
_transformers.Add(new SetBaseType(baseType));
}

if (section != null)
{
foreach (NamespaceInfo n in section.Namespaces)
{
razorHost.NamespaceImports.Add(n.Namespace);
}
}
}
}
catch (IndexOutOfRangeException)
{
// Bug in Mono framework.
// Configure namespaces using the RazorGenerator directives file instead.
}
```

As stated in the code above, users can specify the namespaces using the directives file (which I've tested to confirm works). I feel as though this is an appropriate workaround given that:

a) There's not much RazorGenerator can do to work around the issue, other than implementing code to search for Web.config and use an XML reader to get the namespaces out.
b) There's an appropriate and easy workaround (using the directives file), for the small percentages of users using RazorGenerator with Mono.
c) Mono's implementation of System.Web and System.Web.Configuration is terrible in many other ways, so there's not much point trying to fix the issue upstream in Mono (especially given that I've already worked around several other bugs related to their implementation of System.Web).

At the moment I've built a version of RazorGenerator with this try-catch in it, but obviously long term I want to discard my patch and just use the upstream RazorGenerator version.
Comments: Adding onto this, there's another issue where Mono throws a HttpException when using VirtualPathUtility because the caller isn't inside an actual web application. This is done in AddPageVirtualPathAttribute. Suggested fix is to change the code to the following: ``` try { virtualPath = _overriddenVirtualPath ?? VirtualPathUtility.ToAppRelative("~/" + _projectRelativePath.TrimStart(Path.DirectorySeparatorChar, Path.AltDirectorySeparatorChar)); } catch (HttpException) { // Mono workaround. This seems like it works anyway! virtualPath = "~/" + _projectRelativePath.TrimStart(Path.DirectorySeparatorChar, Path.AltDirectorySeparatorChar); } ```

Closed Unassigned: Workaround for bug in Mono framework [112]

$
0
0
Mono's implementation of System.Web is crap (see https://github.com/mono/mono/blob/master/mcs/class/System.Web/System.Web.Configuration_2.0/WebConfigurationHost.cs#L194 for an example on "how to write terrible code").

When MvcWebConfigTransformer tries to use WebConfigurationManager.OpenMappedWebConfiguration, it crashes at the location linked above. This prevents compilation of views under Mono at all. There isn't much RazorGenerator can do to fix this at the source (short of reimplementing System.Web).

So in order to work around this issue, I'm suggesting that line 44 to line 64 of MvcWebConfigTransformer.cs is wrapped in a try-catch, such that the code becomes:

```
try
{
var config = WebConfigurationManager.OpenMappedWebConfiguration(configFileMap, directoryVirtualPath);

// We use dynamic here because we could be dealing both with a 1.0 or a 2.0 RazorPagesSection, which
// are not type compatible (http://razorgenerator.codeplex.com/workitem/26)
dynamic section = config.GetSection(RazorPagesSection.SectionName);
if (section != null)
{
string baseType = section.PageBaseType;
if (!DefaultBaseType.Equals(baseType, StringComparison.OrdinalIgnoreCase))
{
_transformers.Add(new SetBaseType(baseType));
}

if (section != null)
{
foreach (NamespaceInfo n in section.Namespaces)
{
razorHost.NamespaceImports.Add(n.Namespace);
}
}
}
}
catch (IndexOutOfRangeException)
{
// Bug in Mono framework.
// Configure namespaces using the RazorGenerator directives file instead.
}
```

As stated in the code above, users can specify the namespaces using the directives file (which I've tested to confirm works). I feel as though this is an appropriate workaround given that:

a) There's not much RazorGenerator can do to work around the issue, other than implementing code to search for Web.config and use an XML reader to get the namespaces out.
b) There's an appropriate and easy workaround (using the directives file), for the small percentages of users using RazorGenerator with Mono.
c) Mono's implementation of System.Web and System.Web.Configuration is terrible in many other ways, so there's not much point trying to fix the issue upstream in Mono (especially given that I've already worked around several other bugs related to their implementation of System.Web).

At the moment I've built a version of RazorGenerator with this try-catch in it, but obviously long term I want to discard my patch and just use the upstream RazorGenerator version.
Comments: Fixed in 1.5.5. Please verify with official vsix. Thanks!
Viewing all 525 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>