https://discord.umbraco.com
Join Discord
Package developers, would anyone care to
# package-development
m
Package developers, would anyone care to share their approach to how to setup a test env for a nuget package? Reading around it seems add the , to generate the nupkg when building the package project in VS, and then spin up a new test site with 
dotnet add package my.package --source D:\Release --prerelease
as the package reference (where the generated nupkg is in 
D:\Release
) If the test site is already in existence (with the above pkg ref) does it take notice of a new build of the package, or need the version incrementing on each build? Or is there a way to set the package source to simply look at the package source files and any changes are reflected on the test site immediately? (and obv don't mess with local nuget sources at after seeing @Sebastiaan protip re cache hell)
s
It looks at the version so keep increasing beta001, beta002, etc.
a
Like most things, there are multiple ways to go about this. For most of my packages, I have a 
release.bat
and a 
debug.bat
. https://github.com/skybrud/Skybrud.Umbraco.Redirects/blob/v13/main/release.bat https://github.com/skybrud/Skybrud.Umbraco.Redirects/blob/v13/main/debug.bat The 
release.bat
file is for building the package and creating the NuGet for release. If you're not a dinosaur like me, you probably use some kind of automation (eg. GitHub actions) to handle this part. The 
debug.bat
file will build the package in debug mode, and then create and save a NuGet package at 
c:\nuget
(could be any folder). In Visual Studio you can configure a custom NuGet package feed, so I've added 
c:\nuget
to mine. This means that in my test project, I can select the local package feed, and then write 
Install-Package MyPackage -pre
to install the package (or 
Update-Package
to update it). 
-pre
means that we allow pre-releases, and since I'm appending the timestamp to the version number, I don't have to manually bump the version number each time I'm testing a new build locally.
m
Cheers @Sebastiaan @Anders Bjerner, I sort of assumed that living in VS there was someway for it to just work.. without having to constantly deploy a new stamped version on the package and then have to either recreate or update the package in the test site. I guess it's a case of work against a project dependency to get your package correct first from a code perspective.. And then a more manual build and rebuild and update to see if you got the packaging right. I guess prebuild actions in the cproj could be used to automatically update the version ref in the test site though...
a
You can add the DLL to your test project as an assembly reference. But then any assets won't get included. I sometimes do this, and then copy the assets over manually while testing and developing. This should also give you better stack traces (eg. line numbers), as you then have access to the PDB file - which you won't have with the NuGet package.
m
would staticwebassests and rcl be the way to go then... for the sans debug dll include approach?
or indeed back to buldactions (xcopy) to auto copy on nuget proj build into the test web project 😉
a
The assets (except .cshtml files I think) are not placed in the DLL, but the NuGet package. So adding an assembly reference won't get you the assets.
k
If you include the package reference for a RCL project in the test site it will get the dll and the static files are served into the site from the project. (No need to copy anything manually) So you also get automatic updates/refresh when you change the JS files in the RCL the site reloads it's quite a nice way to work
a
Yes, that's the setup I (tried) to explain earlier. Adding an assembly reference was an alternative to that. I use a mix of both when testing, but mostly installing the NuGet package from my local feed.
m
by adding the package reference to the RCL Project (is that the same as the nuget package project) and so just doing 
dotnet add package my.package --source D:\MyPackageProj --prerelease
doesn't need the 
nupkg
it will fetch the debug/release dll and directly reference the static files? That sounds like exactly what I thought should happen!
3 Views
PreviousNext
Powered by

Umbraco

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

Powered by