Statiq.Web Version 1.0.0-beta.49 causes error in libraries that depend on Statiq

[StevenTCramer]

I am trying to write a library that depends on Statiq.Web and when I use Statiq.Web version 1.0.0-beta.49 I get the following error:

Error	CS0234	The type or namespace name 'Extensions' does not exist in the namespace 'StatiqHelpers' (are you missing an assembly reference?)	StatiqHelpers	C:\git\github\AnkurSheel\StatiqHelpers\src\StatiqHelpers\Commands\NewPost.cs	10	Active

When I use version 1.0.0-beta.48 I do NOT get that error.

I have been referencing https://github.com/AnkurSheel/StatiqHelpers repo which is using version 1.0.0-beta.47 at the time of this issue and notice if I attempt to update that repo to 1.0.0-beta.49 it too fails. @AnkurSheel

Curious if the change in 1.0.0-beta.49 of renaming from Statiq.Web.prop to Statiq.Web.targets is the cause?

[AnkurSheel]

I have had a quick look and I suspect the issue is because both StatiqHelpers and Statiq.Framework have an extension folder and the compiler cannot resolve the extension methods after adding the implicit usings to the .targets file.

I have created AnkurSheel/StatiqHelpers#15 to fix this in StatiqHelpers

[AnkurSheel]

This should be fixed in the latest release of StatiqHelpers

[daveaglick]

Sorry for the radio silence! Been a crazy start to the school year here on my end.

I’m guessing you figured out the Extensions folder was indeed the problem? For context, Statiq.Web installs a .targets file that, among other things, excludes a few folders from the C# project like the input folder. As part of that it also excludes an extensions folder. This isn’t well documented (or maybe not documented at all 😬) but the idea is that eventually Statiq Web will support generation-time extensions similar to themes that get compiled by Statiq - and those would go in that extensions folder, which would then need to be excluded from the project so it doesn’t end up being compiled twice and crating conflicts (once by the project and then again by the Statiq engine). It’s the exact same reason files under theme are excluded (and extensions will look very much like themes, just with the intent of bringing in multiple of them to augment a theme).

Does that make sense?

[StevenTCramer]

I did figure out that the targets were excluding the extensions folder. And I have worked around it with Extension_s folder for now. But as to making sense or not I don't know. It seems odd that using a library prevents me from naming a folder something, but I understand what you are trying to do. For now we have work around. Later if I can think of a cleaner option I will yell :)
Thanks.

[daveaglick]

Yeah - it's kind of a weird situation because of the balance between providing conventional behavior and not stepping on any toes. In this case, a handful of "reserved" folder names allows me to write documentation that tells people just to use those folders for certain purposes. The alternative would be to make everyone manually define the folders that contain themes, extensions, etc. and then instruct them to add those build exclusions to their own project files - I suspect that would cause way more problems than these carved-out exclusions do. Now I just need to do a better job of documenting this behavior.

[AnkurSheel]

I agree. I think its better to be a little opinionated and have reserved folder names. I do wonder if it would be better to have lets say the extension folder under another folder so that you could potentially exclude CustomFramework/extensions instead of extensions.

The lack of documentation for a beta release doesn't bother me as much. It was quite easy to figure out what was going wrong.