Saeve
May 16, 2025, 9:56pm
9
I think I’m officially putting this on the shelf for the foreseeable future.
Some further research into the Umbraco source code, GitHub issues and experimentation seem to indicate this is just a problem there might not be a good or easy solution to.
This issue got my hopes up, but as others note, it just doesn’t seem to work anymore.
opened 03:45PM - 21 Mar 22 UTC
closed 07:28AM - 10 Jan 23 UTC
### Which *exact* Umbraco version are you using? For example: 9.0.1 - don't just… write v9
9.3.0
### Bug summary
I've been trying to implement support for "themes" in my view rendering and after a bit of digging in the code I realized Umbraco is "wrapping" the default razor view engine into a few additional wrapping engines, which makes it impossible to set options.
### Specifics
On a normal ASP.NET Core application, one would just set new values for `RazorViewEngineOptions.ViewLocationFormats` or by creating a new `ViewLocationExpander` class.
I've been trying to do it with a `Composer` but any change done there never get executed. The only way to inject new view location is by adding directly a new builder method to be called in the startup class
```cs
services.AddUmbraco(_env, _config)
.AddBackOffice()
.AddThemes() //custom extension that adds a new ViewLocationExpander similar to the core umbraco one
.AddWebsite()
.AddComposers()
.Build();
```
This adds the search path, but at the bottom of the search list, so not useful for our context.
A possible cause could be the[`RefreshingRazorViewEngine`](https://github.com/umbraco/Umbraco-CMS/blob/v9/contrib/src/Umbraco.Web.Common/ModelsBuilder/RefreshingRazorViewEngine.cs) that contains a copy of the razor view engine, so setting the options once this has been wrapped has no effect on the view locations.
Another possible cause of the problem could come from the [`ProfilingViewEngine`](https://github.com/umbraco/Umbraco-CMS/blob/v9/contrib/src/Umbraco.Web.Website/ViewEngines/ProfilingViewEngine.cs) which also wraps the current view engine.
Frankly I've no idea how this could be solved, but this makes it impossible to change view locations, and probably also to replace the view engine with something other than Razor (since ModelsBuilder requires it)
### Steps to reproduce
Here is the sample Composer
```cs
public class ThemedViewComposer : IComposer
{
public void Compose(IUmbracoBuilder builder)
{
builder.Services.ConfigureOptions<ThemedViewEngineOptionsSetup>();
}
}
```
And here the Options setup class
```cs
public class ThemedViewEngineOptionsSetup : IConfigureOptions<RazorViewEngineOptions>
{
public void Configure(RazorViewEngineOptions options)
{
if (options == null)
{
throw new ArgumentNullException(nameof(options));
}
options.ViewLocationExpanders.Add(new ViewLocationExpander());
}
}
internal class ViewLocationExpander : IViewLocationExpander
{
public IEnumerable<string> ExpandViewLocations(ViewLocationExpanderContext context, IEnumerable<string> viewLocations)
{
string[] themedLocations = new string[]
{
"/Views/mytheme/{0}.cshtml",
"/Views/mytheme/Shared/{0}.cshtml",
"/Views/mytheme/Partials/{0}.cshtml",
"/Views/mytheme/MacroPartials/{0}.cshtml",
};
viewLocations = themedLocations.Concat(viewLocations);
return viewLocations;
}
// not a dynamic expander
public void PopulateValues(ViewLocationExpanderContext context) { }
}
```
### Expected result / actual result
I'd like to be able to write a Composer that adds viewlocations or ViewLocationExpanders or even adds a new view engine replacing Razor.
I’ve also tried to fiddle with many of the Razor view discovery feature, but to no avail.
The compilation regression with RCL in .NET 9 is also a real bummer that I don’t want to deal with:
opened 02:58AM - 18 Nov 24 UTC
area-blazor
### Is there an existing issue for this?
- [x] I have searched the existing iss… ues
### Describe the bug
Build time for a Razor Class Library with significant static assets (JavaScript files) is more than 4x slower with the .NET 9 SDK than with the .NET 8 SDK.
```
| SDK Version | 1st Build (after clean/restore) | 2nd Build |
|-------------|---------------------------------|-----------|
| 8.0.404 | 36.95 s | 23.90 s |
| 9.0.100 | 143.5 s | 123.8 s |
```
### Expected Behavior
I would expect no such regression without changing code or at least target level. This appears to be driven mostly by the new `ResolveProjectStaticWebAssets` logic, which takes more than 50% of the length of the build, with a good bit of what's left being used by the other "StaticAsset" build steps.
### Steps To Reproduce
1. Make sure you have 8.0.404 and 9.0.0 SDKs installed
2. Clone https://github.com/dymaptic/GeoBlazor
3. In the `src` folder, set the `global.json` to
```
{
"sdk": {
"version": "8.0.0",
"rollForward": "latestMinor"
}
}
```
4. Just to prove that these aren't related, you can delete or comment out all the custom `Targets` in `dymaptic.GeoBlazor.Core.csproj` (otherwise you do need npm and pwsh installed as well)
4. Navigate to `src/dymaptic.GeoBlazor.Core` in a terminal, and run the following commands
```
dotnet clean
dotnet restore
dotnet build -f net8.0
dotnet build -f net8.0
```
5. Edit the `global.json` file, replace `8.0.0` with `9.0.0`
6. Run the commands from step 4 again
### Exceptions (if any)
_No response_
### .NET Version
_No response_
### Anything else?
I expect this is going to be a big issue for any other libraries that wrap significant JavaScript modules. At the very least, I need a workaround to ameliorate this regression so I can move this library to .NET 9 and beyond.
Maybe sometime in the future I’ll revisit this in hopes that I use a ‘mostly’ plug-n-play solution.
1 Like