Full Duck Dev

A few words on software deployment. :-) Please like and share for visibility!

#architecture #azure #ci #continuousdeployment #continuousintegration #deployment #devops #di #infrastructure #softwaredeployment

When building a library, it's useful to test it locally, before even pushing it to a test (and definitely prod) environment. The following tutorial shows all the steps necessary to perform those local tests and see exactly what an end-user will see when using your NuGet package. All this, without leaving your machine!

Table Of Contents

- Video tutorial - Setup your environment - Different ways of packing your library - Pack using Visual Studio - Pack using NuGet CLI - Pack using dotnet CLI - Release the package locally - Use your local NuGet package - Conclusion

Video tutorial

https://youtu.be/-IXCTljXayg

Setup your environment

First, we have to download NuGet executable and add it to our PATH to use NuGet CLI comfortably. This will allow you to type nuget in your Command Prompt to run any NuGet script. You can skip to the next chapter if you already have it configured. Before we attempt to set it up, check if you don't already have it ready: - Press Win + S - Type cmd and press Enter - Type nuget and press Enter If you see the following message... 'nuget' is not recognized as an internal or external command, operable program or batch file.

NuGet not found - The exe wasn't added to PATH ...Perform the steps below. Otherwise, move on to the Pack it section: - Download NuGet.exe from here (latest recommended version is okay) - Place it in a folder it will be stored in. For example: C:Usersuser_nameNuGet, remember to replace user_name with your own. Copy that folder path (remember not to include nuget.exe in the path. - Copy that path address - Press Win + S - Type Environment and press Enter on Edit the system environment variables - In Advanced tab, click on Environment variables... button - In User variables, click on Path variable and select Edit - Click New - Paste the path to your nuget.exe - Press OK - Repeat steps 7-10 for System variables Alternatively, refer to this article.

Different ways of packing your library

Before we release the package, we have to prepare it first. To do that, we use a pack command. I'll show you three ways to do that. Pack using Visual Studio - Open your project/solution in Visual Studio - Right-click on the library and select Properties - Navigate to the Package tab - Tick Generate NuGet package on build - this will do exactly what is says on the tin. It will automatically pack your NuGet package on build. - Insert package details in the fields below. Make sure to specify the package version. The convention I usually use is Major.Minor.Patch starting with 0.0.0. Add "-beta" suffix for the test release. - Save the file - Press Ctrl + Shift + B or select Build -> Build Solution - Right-click on your library .csproj file in Solution Explorer - Select Open folder in File Explorer - You should now see a bin folder, which contains the binary output of your compilation. Enter that folder and go to Debug/Release, whichever configuration you selected when building the project - the *.nupkg file should be there.

Project settings in Visual Studio allow generating a NuGet package on build Pack using NuGet CLI - Navigate to the folder containing your *.csproj file of the library you'd like to release - Type cmd in the File Explorer address bar and hit Enter. This will open Command Prompt - Type dotnet build and hit Enter. This will build your project. bin and obj folders should appear. - Back in Command Prompt, type nuget pack and hit Enter. This will generate *.nupkg file in the current directory.

Using NuGet CLI to pack the DLL Pack using dotnet CLI - Navigate to the folder containing your *.csproj file of the library you'd like to release - Type cmd in the File Explorer address bar and hit Enter. This will open Command Prompt. - Type dotnet build and hit Enter. This will build your project. bin and obj folders should appear. - Back in Command Prompt, type dotnet pack and hit Enter. This will generate *.nupkg file in the bin/{environment}/ directory, where enviroment is either Debug or Release, depending what you chose for your build.

Using dotnet CLI to pack the DLL

Release the package locally

We're almost there, we already have a packed library, all we want is to make it available in our Visual Studio project locally, so we can imitate using a normal NuGet package downloaded from a remote repository. To do that, follow the below steps: - Open Command Prompt as an Administrator in the location of your *.nupkg file. - Type nuget add package_filename.nupkg -Source "C:Program Files (x86)Microsoft SDKsNuGetPackages" (escape characters and quotation marks are important since the path contains spaces) - Replace package_filename (your nupkg file name) with the correct value and hit Enter. The source specifies where the package will be unpacked to - the location I provided is the default location for offline NuGet packages in Visual Studio. This will matter in a minute.

Release locally to the folder available in Visual Studio Offline

Use your local NuGet package

- Open the project you'd like to install your library to in Visual Studio - Right-click on the solution/project - wherever you'd like to install your new NuGet package and select Manage NuGet Packages... - In the top-right, you should have a dropdown menu under Package Source with a default value of nuget.org. Visual Studio normally searches there for the packages by default, but since our package is deployed locally, change it to Microsoft Visual Studio Offline Packages. (You can configure where that location is by pressing a little cog icon next to the dropdown if you'd like to change it) - Search your package name and hit Enter. It should appear on the list - You can now enjoy your package locally!

Find your new package in Visual Studio Package Manager

Conclusion

Me

Howdy. I'm Pawel and I'm a software engineer by trade and passion. You can find a bit more about myself in the About section, but I'd like to keep this post focused on the motives behind this technical blog and the big picture.

The blog