meganav
meganav copied to clipboard
Extra NuGet package
Trying to realise this for all Umbraco packages I'm touching :)
Would it be possible to provide an extra NuGet package which only contains your custom code DLL? Using the current NuGet I get unwanted stuff like everything below App_Plugins, which is unwanted for usage in class libraries.
Thanks for raising this @kows! #h5yr
Can you give me an example of where you'd need to do this? I would traditionally just install the package into my "Web" project alongside Umbraco and everything else.
Our company has a very specific project structure coming from Sitecore, which means logically grouping stuff in separate web & class projects :).
One specific case: we put our Modelsbuilder generating class in a separate class library (Customer.Foundation.Data), hence I am in need of the Cogworks.Meganav dll in order to support the generated properties of type "Cogworks.Meganav.Models.MeganavItem".
That's something what iritate me sometimes with some packages as well - good idea IMO.
I remember this issue related with RJP.MultiUrlPicker which was taken by converters and put into the models classes and I needed to install NuGet there and remove the whole App_Plugins directory.
Would be good to keep the practise to separate .Core library from .Web components - @callumbwhyte: something maybe worth to be even included into Package template(s)?
And please delete the Views\Partials\ExampleNavigation.cshtml
file from the NuGet package! Having to delete it on every install/update is a minor annoyance.
Example code should be in the documentation/wiki and/or possibly shown by using a readme.txt
that automatically opens after installing the package: https://docs.microsoft.com/en-us/nuget/create-packages/creating-a-package#adding-a-readme-and-other-files.
@ronaldbarendse did not mention the other files, but it seems to me the new nuspec only contains the dll so this should be fine?
@kows The Cogworks.Meganav.Core
package should indeed only contain the assembly and Cogworks.Meganav
should only include the App_Plugins
files (and a dependecy on the core package).
Example code doesn't belong in NuGet packages (if you ask me), that's all!
Hey all,
Thanks for all of your points. I can see the use case for a separate "Core" package and it's something I'll be looking to do as part of a v2.0.0 release.
While creating these abstractions in itself does not justify a major version release there are some other changes I'd like to bundle with it, some of which is part of the pathway to V8 support.
I'll post updates soon.
Cheers, Callum
It would be nice to have this feature now. We have the models in the separate project too, and we don't have a solution
We have been using separate projects for a long time and I agree on this one as well.
This is not the only package with this “issue” so we use this little “hack” in our csproj:
<ItemGroup>
<AppPluginsDir Include="$(ProjectDir)App_Plugins" />
</ItemGroup>
<Message Text="Removing App_Plugins from Project" Importance="high" />
<RemoveDir Directories="@(AppPluginsDir)" />
And also exclude with .gitignore.
Far from optimal but keeps the library-project/repo clean. Not sure if this means that the need for a separate project decreases but maybe.
Anyway, I agree on the “general issue” maybe there could be some better general solution. Like a buildtaget in the Umbraco-project csproj-file shipped with the cms that is the “recommended target” for package-content but not runs when the package is included in a class library.
@callumbwhyte thoughts on converting this to a Razor class library? for v9+