Open anit3k opened 3 weeks ago
@anit3k It's indeed a bug. Also when just running the consoleapp from the commandline:
master\HandleBarsDotNet8.DynamicLinq.Console
HandleBars Block Helpers: 97
HandleBars Helpers: 193
Unhandled exception. HandlebarsDotNet.HandlebarsRuntimeException: Template references a helper that cannot be resolved. Helper 'DynamicLinq.Where
Shows the wrong number of helpers.
This is because the PluginLoader loads the *.dll
from the wrong location.
And a workaround: You can set the path yourself:
HandlebarsHelpers.Register(handlebars, c => c.CustomHelperPaths = new BindingList<string>
{
Path.GetDirectoryName(Process.GetCurrentProcess().MainModule!.FileName)!
});
I'll check if I can fix this in Handlebars Helpers plugin loader.
@StefH thx, the workaround works in the api when debugging :) I will test this in my test environment later today :) Let me know if a can do anything to help :)
@anit3k
You can try preview version 2.4.3-ci-18706
.
See https://github.com/Handlebars-Net/Handlebars.Net.Helpers/wiki/MyGet
Just testet this in my simplified repo for the bug/issue and it works great
Just testet this in my simplified repo for the bug/issue and it works great
The preview version you mean?
Yes, haven't had the time for testing in the original solution where i originally discovered the bug. I hope to do it later today :)
Did you have to test it in your production code?
Not yet, sorry. I have been reassign to other projects, but i will do it in the current week :)
@anit3k Did you have time to test it?
Just tested it, did not work, i tried using the provided code snippet as well:
HandlebarsHelpers.Register(handlebars, c => c.CustomHelperPaths = new BindingList
Working just fine in local debug mode.
The environment used for prod "simulation" is a docker/k8 environment, and i only get 193 helper methods, and the application throws an exception with message "Template references a helper that cannot be resolved. Helper 'DynamicLinq.Where'"
It's strange that this does not work in Docker, because my other project WireMock.Net is also bundled in a docker image and this works fine with Handlebars.
That is strange. Currently we have a lot of stuff to do before the summer holydays, so I dont have much time to debug/solve this. Hope to have a little spear time next week.
In my docker container I can see all the dll's when listing the content in app folder, but when i write out the files and directory the helperPath looks in i get:
Helper path: /usr/share/dotnet Files in helper path: /usr/share/dotnet/LICENSE.txt /usr/share/dotnet/ThirdPartyNotices.txt /usr/share/dotnet/dotnet
using this code snippets:
var helperPath = Path.GetDirectoryName(Process.GetCurrentProcess().MainModule!.FileName)!;
HandlebarsHelpers.Register(handlebars, c => c.CustomHelperPaths = new BindingList<string> { helperPath });
PrintDirectoryAndListFiles(helperPath);
private void PrintDirectoryAndListFiles(string path)
{
Console.WriteLine($"Helper path: {path}");
if (Directory.Exists(path))
{
Console.WriteLine("Files in helper path:");
foreach (var file in Directory.GetFiles(path))
{
Console.WriteLine(file);
}
}
else
{
Console.WriteLine("Directory does not exist.");
}
}
when executing the same code snippet locally i get a list of all the files from the debug folder on my laptop
First off all, thx for an awesome project, this library has been saving us a lot of work. I dont know if this is a bug, maybe i am using it wrong.
Description
I am experiencing an issue where the DynamicLinq helpers from Handlebars.Net.Helpers are not being registered correctly in a .NET 8.0 WebAPI project. The same helpers work fine in a console application with identical configuration and dependencies.
Steps to Reproduce
Expected Behavior
Both projects should register the same number of helpers ? 134 Block Helpers and 265 Helpers
Actual Behavior
Repository
A repository containing both the console application and WebAPI project can be found here: https://github.com/anit3k/HandleBarsDotNet8.DynamicLinq
Environment
Additional Context
I have compared the projects multiple times to ensure they have identical configurations and dependencies. I have also tried explicitly loading assemblies and adding additional logging to diagnose the issue without success.
Any help or guidance on resolving this issue would be greatly appreciated.