https://discord.umbraco.com
Join Discord
Voodoo magic question for @Kevin Jump
# package-development
s
Voodoo magic question for @Kevin Jump please (no rush) 🧵
I can see that your 
App_Plugins
folder stays in your 
.Client
project.. but how does the Umbraco 
.Website
know how to pick it up? https://cdn.discordapp.com/attachments/1209807427067846717/1209807604352819220/image.png?ex=65e84422&is=65d5cf22&hm=76c49d5e4a5f3ffe98081ee4a16fc7a25e2dacd0addb35d6811ec241d028a895&
I tried replicating this in a new project but I don't understand how they are "magically" linked.
k
In my examples there is a "Package" project (so 
TimeDashbboard
) that has a dependency on client,
and the website is dependeny on the package.
but also.
s
aha!
k
the client project is a Razor class libary (so in csproj) and that does all the magic wwwroot stuff.
s
Yep, I did set it up as an RCL, referenced 
.Client
from 
.Website
but I guess that's not quite enough to do all the magic 🤔
k
it should in theory work that way too, have you set the 
StaticWebAssetBasePath
in the RCL too ?
j
You also need to call UseStaticFiles in Program.cs, I think? https://learn.microsoft.com/en-us/aspnet/core/fundamentals/static-files?view=aspnetcore-8.0
k
Nah umbraco does that bit for you 🙂
s
> have you set the StaticWebAssetBasePath in the RCL too ? yep have set that! So I was wondering what 
TimeDashboard.Core
and `TimeDashboard`projects were for, since they're empty.
So I guess the problem might be that I don't actually know how to know if it worked! 😂
My property editor is not showing up, that's for sure 😬
Oh wait, missing 
umbraco-package.json
💡
That helped, now we're in business! Thanks both! 🙌
k
🙂
The timedashboard, is setup like the early adopter template which in turn is setup for a package dev. so .. - the "TimeDashboard" at the top is the package - the thing that is nuget'ed - .Client is all the front end stuff, (and in this case the controllers too) - .Core would be back end stuff like services, repos, etc in theory if its done this way you can have the front end agnostic from the back, and if you have a package that took, client and core it would be v14, but you could have another project that did the "client" for v13, and it would work. obvs depending on the package it might be a bit diffrent, e.g usync is going to have a 
Management.Client
and 
Management.Api
project to seperate out the controllers, because other projects use usync's front end so i need to make it a NPM library of its own so it can be consumed by other front ends
s
Ah that makes sense, Voodoo explained! I am very close to having my own little thing working and will look into your fancy setup again as it does make a lot of sense, less so for a single property editor that I'm working on now - but I like the look of your setup much more 🙂
k
Yeah i think you can ditch bits of it and go with package.csproj & site.csproj for all the package dev i do, i don't do much property editor stuff, so i often end up with all the backend code too.
PreviousNext
Powered by

Umbraco

A hub and casual space for you to interact with fellow community members and learn more about Umbraco!

Powered by