ArgumentException: The path in 'value' must start with '/'. (Parameter 'value')

After upgrading to v4.0.0, I see the following exception:

ArgumentException: The path in 'value' must start with '/'. (Parameter 'value')
Microsoft.AspNetCore.Http.PathString..ctor(string value)
Smidge.RequestHelper.Content(string path) in RequestHelper.cs
+
                return pathBase.Add(new PathString(path.Substring(1))).Value;
Smidge.RequestHelper.Content(IWebFile file) in RequestHelper.cs
+
            var filePath = Content(file.FilePath);
Smidge.SmidgeHelper+<>c__DisplayClass20_0.<GenerateBundleUrlsAsync>b__0(IWebFile d) in SmidgeHelper.cs
+
                result.AddRange(files.Select(d => _urlManager.AppendCacheBuster(_requestHelper.Content(d), debug, cacheBusterValue)));
System.Linq.Enumerable+SelectEnumerableIterator<TSource, TResult>.MoveNext()
System.Collections.Generic.List<T>.InsertRange(int index, IEnumerable<T> collection)
Smidge.SmidgeHelper.GenerateBundleUrlsAsync(string bundleName, string fileExt, bool debug) in SmidgeHelper.cs
+
                result.AddRange(files.Select(d => _urlManager.AppendCacheBuster(_requestHelper.Content(d), debug, cacheBusterValue)));
Smidge.SmidgeHelper.GenerateCssUrlsAsync(string bundleName, bool debug) in SmidgeHelper.cs
+
            return Task.FromResult(GenerateBundleUrlsAsync(bundleName, ".css", debug));
Smidge.TagHelpers.SmidgeLinkTagHelper.ProcessAsync(TagHelperContext context, TagHelperOutput output) in SmidgeLinkTagHelper.cs
+
                var result = (await _smidgeHelper.GenerateCssUrlsAsync(Source, Debug)).ToArray();
Microsoft.AspNetCore.Razor.Runtime.TagHelpers.TagHelperRunner.<RunAsync>g__Awaited|0_0(Task task, TagHelperExecutionContext executionContext, int i, int count)
AspNetCore.Web_Views_Installation_ServiceUnavailable.<ExecuteAsync>b__19_2() in ServiceUnavailable.cshtml
+
		<link rel="stylesheet" href="css-site" debug="true" />

This occurs with a bundle set up as follows:

bundles.CreateCss("css-site",
	$"~/styles/Style.css"
);

At the line https://github.com/Shazwazza/Smidge/blob/f712bf89cc9777d9969b8e429e76c0ec290f9b43/src/Smidge/RequestHelper.cs#L80 the value of variable path is “~Styles/Style.css”

I’ve traced this issue to a recent change to line 80 of SmidgeFileSystem.cs - see https://github.com/Shazwazza/Smidge/commit/3cd798b00348a8ddca6ed4cdf1094ec3991299bf#diff-6bfda8a8c26e0c51fd7564f1f6231f4760074468339b588ea24279e2427b8dcfL78

In my case, the results are from line 52 of DefaultFileProviderFilter.GetMatchingFiles and do not start with a slash. https://github.com/Shazwazza/Smidge/blob/b0383c3b7e2b667402451dcff7055209ceabd428/src/Smidge.Core/DefaultFileProviderFilter.cs#L52

Maybe this can be fixed with a condition - something like:

return _fileProviderFilter.GetMatchingFiles(_sourceFileProvider, filePattern)
    .Select(x => x.StartsWith("/") ? $"~{x}" : $"~/{x}"); // back to virtual path

Note that none of the unit tests cover the scenario where _rootFileInfo?.PhysicalPath != null in DefaultFileProviderFilter.GetMatchingFiles.

[PhyxionNL]

This happens because of the default file provider. You can fix it like this (add before AddSmidge):

     services.AddSingleton<ISmidgeFileProvider>(s =>
            {
                var webHostEnvironment = s.GetRequiredService<IWebHostEnvironment>();
                return new SmidgeFileProvider(webHostEnvironment.WebRootFileProvider);
            });

[Shazwazza]

Thanks for reporting @dsparkplug and the fix you proposed works fine. The reason this was not seen in the test website is because it had multiple file providers registered. This bug is only seen when there is a single file provider registered. I’ll need to add some tests for that scenario.