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

Edited Issue: Problems with. 4.5 and net MVC4 [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?__

Commented Issue: Problems with. 4.5 and net MVC4 [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: Not sure that this error is directly related to RazorGenerator. Maybe this [thread](http://stackoverflow.com/questions/4158573/need-razor-view-engine-auto-complete-to-work-in-a-class-library) can help?

Commented Issue: Problems with. 4.5 and net MVC4 [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: When I remove any reference to RazorGenerator from .csproj the error does not occur. I tried to copy the Web.config described in the post but the same error appears. When the edit .csproj with this: ``` <MvcBuildViews>true</MvcBuildViews> <PrecompileRazorFiles>false</PrecompileRazorFiles> <!--<Import Project="$(SolutionDir)\packages\RazorGenerator.MsBuild.1.5.3.0\tools\RazorGenerator.targets"/> <Target Name="BeforeBuild"> <ItemGroup> <Content Remove="Views\**\*.cshtml" /> <None Include="Views\**\*.cshtml" /> </ItemGroup> </Target>--> ``` everything works perfectly. I do not know what else to do.

Commented Issue: Problems with. 4.5 and net MVC4 [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: Can you try my [test project](https://github.com/davidebbo/MvcApplicationRazorGeneratorSeparateLibrary)? Knowing whether that works would help determine whether the issue is with your project or something with the way the machine/VS is set up.

Commented Issue: Problems with. 4.5 and net MVC4 [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 think I found the problem! Create: http://cl.ly/NfOH 1. Add a controller `PersonController` 2. Create class ViewModel ``` public class PersonViewModel { public string Name { get; set; } } ``` 3. Create view Index.cshtml ``` @model PersonViewModel @Html.DisplayForModel(); ``` 4. Create in DisplayTemplates folder the PersonViewModel.cshtml ``` @model PersonViewModel @Html.EditorFor(p => p.Name) ``` 5. Try compile ![Image](http://cl.ly/NeL4/RazorGeneratorProblemError.jpg) > http://cl.ly/NeL4

Edited 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?__

Created Issue: duplicate *.generated.cs-file after renaming view [104]

$
0
0
I've renamed a view "Chart.cshtml" to "ChartDisplay.cshtml" and then renamed "Configuration.cshtml" to "Chart.cshtml". As a result I get two generated files "Chart.generated.cs" and "Chart1.generated.cs" where the first one is the renamed file that still contains a class "Configuration" (the name the view did have before renaming).

I'm using TFS as a source code repository (didn't test if that also happens without source control, because working without source control is not an option for me).

A simple workaround is to delete the "Chart.generated.cs" and keep "Chart1.generated.cs" - but I don't really want to have that "1" inside the file name (I have some doubts whether I will end up with additional file with in the future).

Commented Issue: duplicate *.generated.cs-file after renaming view [104]

$
0
0
I've renamed a view "Chart.cshtml" to "ChartDisplay.cshtml" and then renamed "Configuration.cshtml" to "Chart.cshtml". As a result I get two generated files "Chart.generated.cs" and "Chart1.generated.cs" where the first one is the renamed file that still contains a class "Configuration" (the name the view did have before renaming).

I'm using TFS as a source code repository (didn't test if that also happens without source control, because working without source control is not an option for me).

A simple workaround is to delete the "Chart.generated.cs" and keep "Chart1.generated.cs" - but I don't really want to have that "1" inside the file name (I have some doubts whether I will end up with additional file with in the future).
Comments: Try deleting all the generated files and then regenerate it by right clicking on cshtml and choosing 'Run Custom Tool' (or just resave the file).

Commented Issue: duplicate *.generated.cs-file after renaming view [104]

$
0
0
I've renamed a view "Chart.cshtml" to "ChartDisplay.cshtml" and then renamed "Configuration.cshtml" to "Chart.cshtml". As a result I get two generated files "Chart.generated.cs" and "Chart1.generated.cs" where the first one is the renamed file that still contains a class "Configuration" (the name the view did have before renaming).

I'm using TFS as a source code repository (didn't test if that also happens without source control, because working without source control is not an option for me).

A simple workaround is to delete the "Chart.generated.cs" and keep "Chart1.generated.cs" - but I don't really want to have that "1" inside the file name (I have some doubts whether I will end up with additional file with in the future).
Comments: Thanks for the quick Response, but deleting both files and re-running the tool generates a file called "Chart1.generated.cs" (including the "1"). It seems the tool still "sees" the old file inside TFS (the deleted one) and tries to avoid that file name. Does Razor Generator check fthe file System only to prevent overwriting existing files or does it also check the source control?

Commented Issue: duplicate *.generated.cs-file after renaming view [104]

$
0
0
I've renamed a view "Chart.cshtml" to "ChartDisplay.cshtml" and then renamed "Configuration.cshtml" to "Chart.cshtml". As a result I get two generated files "Chart.generated.cs" and "Chart1.generated.cs" where the first one is the renamed file that still contains a class "Configuration" (the name the view did have before renaming).

I'm using TFS as a source code repository (didn't test if that also happens without source control, because working without source control is not an option for me).

A simple workaround is to delete the "Chart.generated.cs" and keep "Chart1.generated.cs" - but I don't really want to have that "1" inside the file name (I have some doubts whether I will end up with additional file with in the future).
Comments: RazorGenerator has no special logic for this, as it's a standard VS generator. So I think any behavior relating to TFS is probably standard behvaior. And admittedly I'm not really sure how that all works with TFS.

Commented Issue: RazorGenerator not available for VS11 [54]

$
0
0
RazorGenerator is not showing up in the extension manager for Visual Studio 11
Comments: I just tried out williamBurgeson's idea and it actually works. Downloaded VSIX from http://visualstudiogallery.msdn.microsoft.com/1f6ec6ff-e89b-4c47-8e79-d2d68df894ec and only added the VWDExpress element. Modified VSIX attached.

Created Unassigned: View activation process unification [105]

$
0
0
Currently we have two different places with different code that implements view instantiation logic.

__PrecompiledMvcView.Render__
This code is used to create an instance of ordinary view. It:

1. Tries to resolve `IViewPageActivator` through `DependencyResolver` and use it to create instance of needed view class.
2. If activator could not be resolved, it uses DependencyResolver to resolve required class instance.
3. If previous steps failed (object is still uninitialized), it uses `Activator.CreateInstance` as a fallback mechanism.

```cs
object instance = null;
if (DependencyResolver.Current != null)
{
var viewPageActivator = DependencyResolver.Current.GetService<IViewPageActivator>();
if (viewPageActivator != null)
instance = viewPageActivator.Create(viewContext.Controller.ControllerContext, _type);
else
instance = DependencyResolver.Current.GetService(_type);
}
if (instance == null)
instance = Activator.CreateInstance(_type);

WebViewPage webViewPage = instance as WebViewPage;
```

__PrecompiledMvcViewEngine.CreateInstance__
The code below is used to instantiate specific views: _ViewStart & Layouts. Its logic:

1. Tries to resolve instance of a class class through DependencyResolver if it has been set.
2. If dependency resolver is null, it uses `Activator.CreateInstance`

```cs
if (_mappings.TryGetValue(virtualPath, out type))
{
if (DependencyResolver.Current != null)
{
return DependencyResolver.Current.GetService(type);
}
return Activator.CreateInstance(type);
}
```

This logic does not use `IViewPageActivator`. Moreover, `DependencyResolver.GetService` could return __null__.

I use Autofac and its ASP.NET MVC integration. It uses explicit service registration, so if some class have not been registered explicitly, it could not be resolved (`DependencyResolver` returns null). Before precompiled view engine, all things were ok, because default `RazorViewEngine` implementation uses `DefaultViewPageActivator` class and it use `Activator.CreateInstance` as a fallback:

```cs
return _resolverThunk().GetService(type) ?? Activator.CreateInstance(type);
```

I suggest to unify this logic and incapsulate it in the similar default activator class. And use it in `PrecompiledMvcView.Render` and `PrecompiledMvcViewEngine.CreateInstance` methods. See my pull request.

Commented Unassigned: View activation process unification [105]

$
0
0
Currently we have two different places with different code that implements view instantiation logic.

__PrecompiledMvcView.Render__
This code is used to create an instance of ordinary view. It:

1. Tries to resolve `IViewPageActivator` through `DependencyResolver` and use it to create instance of needed view class.
2. If activator could not be resolved, it uses DependencyResolver to resolve required class instance.
3. If previous steps failed (object is still uninitialized), it uses `Activator.CreateInstance` as a fallback mechanism.

```cs
object instance = null;
if (DependencyResolver.Current != null)
{
var viewPageActivator = DependencyResolver.Current.GetService<IViewPageActivator>();
if (viewPageActivator != null)
instance = viewPageActivator.Create(viewContext.Controller.ControllerContext, _type);
else
instance = DependencyResolver.Current.GetService(_type);
}
if (instance == null)
instance = Activator.CreateInstance(_type);

WebViewPage webViewPage = instance as WebViewPage;
```

__PrecompiledMvcViewEngine.CreateInstance__
The code below is used to instantiate specific views: _ViewStart & Layouts. Its logic:

1. Tries to resolve instance of a class class through DependencyResolver if it has been set.
2. If dependency resolver is null, it uses `Activator.CreateInstance`

```cs
if (_mappings.TryGetValue(virtualPath, out type))
{
if (DependencyResolver.Current != null)
{
return DependencyResolver.Current.GetService(type);
}
return Activator.CreateInstance(type);
}
```

This logic does not use `IViewPageActivator`. Moreover, `DependencyResolver.GetService` could return __null__.

I use Autofac and its ASP.NET MVC integration. It uses explicit service registration, so if some class have not been registered explicitly, it could not be resolved (`DependencyResolver` returns null). Before precompiled view engine, all things were ok, because default `RazorViewEngine` implementation uses `DefaultViewPageActivator` class and it use `Activator.CreateInstance` as a fallback:

```cs
return _resolverThunk().GetService(type) ?? Activator.CreateInstance(type);
```

I suggest to unify this logic and incapsulate it in the similar default activator class. And use it in `PrecompiledMvcView.Render` and `PrecompiledMvcViewEngine.CreateInstance` methods. See my pull request.
Comments: Added pull request: https://razorgenerator.codeplex.com/SourceControl/network/forks/odinserj/RazorGenerator/contribution/4565

Edited Unassigned: View activation process unification [105]

$
0
0
Currently we have two different places with different code that implements view instantiation logic.

__PrecompiledMvcView.Render__
This code is used to create an instance of ordinary view. It:

1. Tries to resolve `IViewPageActivator` through `DependencyResolver` and use it to create instance of needed view class.
2. If activator could not be resolved, it uses DependencyResolver to resolve required class instance.
3. If previous steps failed (object is still uninitialized), it uses `Activator.CreateInstance` as a fallback mechanism.

```cs
object instance = null;
if (DependencyResolver.Current != null)
{
var viewPageActivator = DependencyResolver.Current.GetService<IViewPageActivator>();
if (viewPageActivator != null)
instance = viewPageActivator.Create(viewContext.Controller.ControllerContext, _type);
else
instance = DependencyResolver.Current.GetService(_type);
}
if (instance == null)
instance = Activator.CreateInstance(_type);

WebViewPage webViewPage = instance as WebViewPage;
```

__PrecompiledMvcViewEngine.CreateInstance__
The code below is used to instantiate specific views: _ViewStart & Layouts. Its logic:

1. Tries to resolve instance of a class class through DependencyResolver if it has been set.
2. If dependency resolver is null, it uses `Activator.CreateInstance`

```cs
if (_mappings.TryGetValue(virtualPath, out type))
{
if (DependencyResolver.Current != null)
{
return DependencyResolver.Current.GetService(type);
}
return Activator.CreateInstance(type);
}
```

This logic does not use `IViewPageActivator`. Moreover, `DependencyResolver.GetService` could return __null__.

I use Autofac and its ASP.NET MVC integration. It uses explicit service registration, so if some class have not been registered explicitly, it could not be resolved (`DependencyResolver` returns null). Before precompiled view engine, all things were ok, because default `RazorViewEngine` implementation uses `DefaultViewPageActivator` class and it use `Activator.CreateInstance` as a fallback:

```cs
return _resolverThunk().GetService(type) ?? Activator.CreateInstance(type);
```

I suggest to unify this logic and incapsulate it in the similar default activator class. And use it in `PrecompiledMvcView.Render` and `PrecompiledMvcViewEngine.CreateInstance` methods. See my pull request.

Commented Unassigned: View activation process unification [105]

$
0
0
Currently we have two different places with different code that implements view instantiation logic.

__PrecompiledMvcView.Render__
This code is used to create an instance of ordinary view. It:

1. Tries to resolve `IViewPageActivator` through `DependencyResolver` and use it to create instance of needed view class.
2. If activator could not be resolved, it uses DependencyResolver to resolve required class instance.
3. If previous steps failed (object is still uninitialized), it uses `Activator.CreateInstance` as a fallback mechanism.

```cs
object instance = null;
if (DependencyResolver.Current != null)
{
var viewPageActivator = DependencyResolver.Current.GetService<IViewPageActivator>();
if (viewPageActivator != null)
instance = viewPageActivator.Create(viewContext.Controller.ControllerContext, _type);
else
instance = DependencyResolver.Current.GetService(_type);
}
if (instance == null)
instance = Activator.CreateInstance(_type);

WebViewPage webViewPage = instance as WebViewPage;
```

__PrecompiledMvcViewEngine.CreateInstance__
The code below is used to instantiate specific views: _ViewStart & Layouts. Its logic:

1. Tries to resolve instance of a class class through DependencyResolver if it has been set.
2. If dependency resolver is null, it uses `Activator.CreateInstance`

```cs
if (_mappings.TryGetValue(virtualPath, out type))
{
if (DependencyResolver.Current != null)
{
return DependencyResolver.Current.GetService(type);
}
return Activator.CreateInstance(type);
}
```

This logic does not use `IViewPageActivator`. Moreover, `DependencyResolver.GetService` could return __null__.

I use Autofac and its ASP.NET MVC integration. It uses explicit service registration, so if some class have not been registered explicitly, it could not be resolved (`DependencyResolver` returns null). Before precompiled view engine, all things were ok, because default `RazorViewEngine` implementation uses `DefaultViewPageActivator` class and it use `Activator.CreateInstance` as a fallback:

```cs
return _resolverThunk().GetService(type) ?? Activator.CreateInstance(type);
```

I suggest to unify this logic and incapsulate it in the similar default activator class. And use it in `PrecompiledMvcView.Render` and `PrecompiledMvcViewEngine.CreateInstance` methods. See my pull request.
Comments: Fixed in changeset b0a2e6258e987bc8c8b27759df48fa52817cf37d

Commented Issue: CreateInstance DependencyResolver in PrecompiledMvcEngine [64]

$
0
0
Line 141 causing a null exception when our CastleWindsor IDependencyResolver returns null for GetService() resolution of _ViewStart, and _AreaLayout et al.

Adding a null-coalescing operator to the DependencyResolver.Current.GetService(type) call can avoid the issue:

return DependencyResolver.Current.GetService(type) ?? Activator.CreateInstance(type);
Comments: I think it has been resolved in https://razorgenerator.codeplex.com/workitem/105

Commented Issue: CreateInstance DependencyResolver in PrecompiledMvcEngine [64]

$
0
0
Line 141 causing a null exception when our CastleWindsor IDependencyResolver returns null for GetService() resolution of _ViewStart, and _AreaLayout et al.

Adding a null-coalescing operator to the DependencyResolver.Current.GetService(type) call can avoid the issue:

return DependencyResolver.Current.GetService(type) ?? Activator.CreateInstance(type);
Comments: I agree that [changeset](https://razorgenerator.codeplex.com/SourceControl/changeset/b0a2e6258e987bc8c8b27759df48fa52817cf37d) has resolved this item with the implementation of the new RazorGenerator.Mvc/DefaultViewPageActivator.cs I have not tested this out for our implementation, but my code review aligns with my recommendation. Thanks.

Closed Issue: CreateInstance DependencyResolver in PrecompiledMvcEngine [64]

$
0
0
Line 141 causing a null exception when our CastleWindsor IDependencyResolver returns null for GetService() resolution of _ViewStart, and _AreaLayout et al.

Adding a null-coalescing operator to the DependencyResolver.Current.GetService(type) call can avoid the issue:

return DependencyResolver.Current.GetService(type) ?? Activator.CreateInstance(type);
Comments: Thanks odinserj for making this change!

Created 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.

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.
Viewing all 525 articles
Browse latest View live


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