Most of the code that I publish here on CODEGATOR is packaged up as NUGET packages. That’s because NUGET packages are easy to build, easy to publish, easy to download, and the Package Manager takes care of little things like package dependencies that I would otherwise make everyone’s life difficult.
Thanks to Visual Studio 2017, creating a NUGET package couldn’t be easier. However, in my case at least, creating the .nupkg file is really only part of the battle. I have so many NUGET packages out there now, with so many inter-dependencies, that if I tried to build each one manually, each time I made a change, well, it would take me a while to get through the build cycle. So, to make the most of my limited free time, I created a home-grown build pipeline that automagically builds and publishes a package whenever I check a change into the packages’ associated GIT repository.
My process isn’t too complicated and it seems to work well enough. I’ve been publishing my packages this way for at least a year now. I though it might be fun to describe my work flow. I hope the article helps anyone who might be struggling to put together their own CI pipeline.
I will say a couple of things before we start though: (1) My work flow involves multiple tools and websites. We’ll be doing some switching back and forth as I describe things and we go through the steps to connect the various tools together. It’s alright though, there are several pieces to contend with but the overall complexity level is quite manageable. (2) My work flow involves the use of third party websites. You will have to create accounts on those websites in order follow along with this walk through. However, those accounts didn’t cost me anything and they shouldn’t cost you anything either. I just wanted to warn everyone, up front, about these two things.
Let get started!
My process usually begins by creating a .NET Standard project in Visual Studio. I target .NET Standard unless there’s a compelling reason not to, because .NET Standard works with so many different frameworks and environments.
I start by hitting Ctrl+Shift+N, which brings up the New Project dialog:
I then choose the .NET Standard project type, and select a name and location for the project. Finally, I hit the OK button to create the project. For this walk through, I chose to name my project CG.Walkthrough, but you can feel free to use a name that holds more meaning for you.
The result is a project structure that looks like this:
Next, right click on the project and choose Properties, which should bring up the following dialog:
Make sure the “Package” tab is selected, then make sure the “Generate NuGet package on build” checkbox is checked. You may also take this opportunity to fill in any of the other properties for the package here, such as the package name, copyright, etc. Don’t worry if you don’t know what some of these fields are for, most of them are optional and you can always come back later and fill them out.
At this point you have a Visual Studio project that will build to a NUGET package. Feel free to add your own code, if you like, or simply continue to follow along with the CI portion of the walk through. What we’re trying to do is produce a NUGET package that’s backed by a GITHUB repository, built by an automated CI builder, and deployed to the NUGET site as part of that CI pipeline. For that reason, the code that’s in the project doesn’t really matter. Feel free to simply leave the Class1.cs file in place, if you like.
Now that we have a project to build, the next step is to create a GITHUB repository to attach to that project. So if you don’t already have an account on GitHub.com, go there now and create one. That process is incredibly straightforward so I won’t walk everyone through it. If you do have an account on GitHub.com already then go there now and log in. Afterwards, create a new repository for our NUGET project, using the big green “New” button on the GitHub page:
After you press that button, use the next window to name your repository and include a nice description, so you’ll know what the project was later on, when you come back to it again.
When you’re done naming your repository, press the big green “Create repository” button to actually create the GITHUB repository:
So, obviously, your account name will be different than mine and, hopefully, your repository name will be different as well. However, regardless of what you named your repo, you’ll see a page that looks like this, and that page let’s you know that the empty repository is out on the GitHub.com site, ready for you to copy your project to. To do that, let’s copy the url for our project onto the clipboard by selecting the address in the browser and hitting Ctrl+C:
Again, your url will be different than mine and that’s ok.
After we copy the GITHUB repository url to the clipboard, the next step is to go back into Visual Studio and connect our project to our repository.
The easiest way to do that, in Visual Studio, is to click on the status bar where it says: “Add to Source Control”. That should bring up a context menu with the word Git on it. Clicking that menu should open the Team Explorer window, in Visual Studio:
We’ll want to press the bottom button, under where it says “Push To Remote Repository”. That pops up a window for adding the url that we copied onto the clipboard. Past that url there now and then press the “Publish” button to publish your project to its corresponding GITHUB repository:
Once again, let me stress that your GITHUB url will be different than mine and that’s OK. Just as long as you use the URL that you copied into the clipboard, from your browser.
You can check that the publish operation worked by refreshing the GITHUB window in your browser, which should now look something like this:
Of course, your repository will have a different name and might include additional files, if you added content or classes to your project before we got to this point. The only thing that’s important here, is that we see our project on the GITHUB site, which tells us that the source control connection has been made back to our Visual Studio project.
Our next step is to arrange for something to watch our GITHUB repository and build our project for us, every time a new check in is detected. I’ll cover that process in my next article.
See you then!