BB.Libs Getting Started Guide

When your repo has BB NuGets

add new source of packagez:

URL: https://nuget.pkg.github.com/Blackopgaming/index.json
User: your@bonmoja.com email
Password: follow the steps below to generate your Personal Access Token (classic)
Verify your email address, if it hasn’t been verified yet.
In the upper-right corner of any page on GitHub, click your profile photo, then click Settings.
In the left sidebar, click Developer settings.
In the left sidebar, under Personal access tokens, click Tokens (classic).
Select Generate new token, then click Generate new token (classic).
In the “Note” field, give your token a descriptive name.
To give your token an expiration, select Expiration, then choose a default option or click Custom to enter a date.
Select the scopes you’d like to grant this token. To use your token to access repositories from the command line, select repo. A token with no assigned scopes can only access public information. For more information, see Scopes for OAuth apps.
Click Generate token.
Optionally, to copy the new token to your clipboard, click .
Screenshot of the “Personal access tokens” page. Next to a blurred-out token, an icon of two overlapping squares is outlined in orange.
To use your token to access resources owned by an organization that uses SAML single sign-on, authorize the token. For more information, see Authorizing a personal access token for use with SAML single sign-on in the GitHub Enterprise Cloud documentation. source: https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens

you should be all set to do the command: nuget restore

When you want to publish your own NuGet

create a repo. naming must start with BB.Libs.
adjust the .csproj adding these lines:

<PropertyGroup>
    <TargetFramework>net8.0</TargetFramework>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
    <AnalysisMode>Recommended</AnalysisMode> <!-- this will provide stricter warnings. because who would want to see more warnings coming from a nuGet... strongly suggested! -->
    <GenerateDocumentationFile>true</GenerateDocumentationFile> <!-- this will prompt adding descriptions to public types/methods/properties. strongly suggested! -->

    <OutputType>Library</OutputType> <!-- for a class library project type. -->
    <GeneratePackageOnBuild>True</GeneratePackageOnBuild>
    <PackageId>BB.Libs.Logging</PackageId> <!-- this is the display name. -->
    <Version>1.0.1</Version> <!-- this is the version. this must change with every commit and package update. we can consider using VERSIONIZE to automate. -->
    <Authors>BongoBongo</Authors>
    <Company>BongoBongo</Company>
    <PackageDescription>This package should contain all related to Logging, including IBBLogger.</PackageDescription>
    <RepositoryUrl>https://github.com/Blackopgaming/BB.Libs.Logging</RepositoryUrl> <!-- this is fixed. -->
</PropertyGroup>

add a file named nuget.config into the root of the repo:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
    <packageSources>
        <add key="github" value="https://nuget.pkg.github.com/Blackopgaming/index.json" />
    </packageSources>
</configuration>

add .gitignore. sample: obj/ bin/ .vscode/ bootstrap function.zip tpl.yaml *.pdb *.dbg NuGet.config
ReadMe.md is strongly suggested!

write how to add dependencies
how to use
etc

to publish:

change version in .csproj if changes were made > push the repo
dotnet build --configuration Release if xml <GeneratePackageOnBuild>True</GeneratePackageOnBuild> is True you will see that package was generated and there will be a location copy the location
`dotnet nuget push “paste the location” —source “github” —api-key your_ghp_key
should get a 200 for PUT request
then package will be discoverable in the NuGet package manager in your favorite IDE

When you could use some guidance/tips on how packages might differ from other c# stuff

suggested folders: root/src/BB.Libs.YourProject AND root/tests/BB.Libs.YourProject.Tests
Abstractions package should be used when a package includes another package, and then the final package user would use the implementation package. this is important, because if you update the package-in-the-package’s repo - then you will have to go and update it in ALL packages it was used in - but if you have an .Abstractions package then no need to update anything, but the end package user.

for example, you need to use BBLogging package in your package, so instead of installing the BB.Libs.Logging - use the BB.Libs.Logging.Abstractions package that contains the IBBLogger interface which you just inject where ever you need logging and in the end user of your package install the BB.Libs.Logging

write good readme. cuz all will be forgotten in a week…and you will find yourself wondering about how to use your own package…
make packages narrow focused and specialized. a giant package with numerous features might be used for 10% if it, like BBCommon. Don’t do BBCommon style packages!
Library package is essentially a class library so it doesn’t have an entry point, but it has a registration method (for ease of use and convenience): please consider installing all package dependencies using 1 IServiceProvider extension method.
package might have Contracts, i.e Types that are Accepted by package as requests/queries/commands/other input types AND responses/queryRersults/commandResults/other output types. Consider making these public and putting them in a separate folder. if more than 1 packages need to use the same Contracts, cinsider making a .Contracts package.
other internal ValueObjects can be internal so that auto fill coding prompts are not crowded with unnecessary suggestions.
Interfaces that you plan to inject into package use project are ofc public, and implementations can be internal.
Types used internally - should be internal.
All public types/methods should have ///Summary so that the user of the package would understand what is done. imagine System types and methods had no ///Summary - nighmare
Unit test your package’s internal logic.