The team management function in VisualStudio provides a convenient way to add tags. You can create a new tag to add tag information and push a specific tag to the server. Cooperating with the method of pushing tags to pack NuGet will make the whole set of tools very cool to use. Completely localized tag pushing completes the NuGet server package pushing
Enter the team management interface, I use the English version, but the button has not changed in the Chinese version. My VisualStudio is 2019
Click on Tags to enter the tag interface
At this time, you can create a new Tag by clicking the New Tag button to give him the version number and information, please see the figure below
Click the Create button to complete the creation. Only the tag number is required in the above code, but the information is not necessary. Of course, there is information to help small partners to better understand the corresponding function of this Tag
At this point, you can see the newly created Tag. Right-click the newly created Tag number to find the push button. Click the push button to push the tag to the server.
Familiar with this method can quickly add a Tag number to the code
Cooperate with dotnet and Gitlab to do automatic push tag packaging NuGet package can be particularly convenient for tag packaging push
Why do I need to push tags to package? The reason is to solve the problem of falling back to a certain version, and this pit is due to a version of a dependent library. At this time, I expect the smallest change. Although I can get the code of this library, it is difficult to know The NuGet library installed in this version corresponds to the commit code of the dependent library
Every time I need to track the version of the source code of the dependent library corresponding to a NuGet package, I need to enter the packaging server to view the packaging log. After playing for a long time in this way, the company's configuration administrator killed the server and deleted it. The log. And I received a very old project that needs to repair a pit. At this time, this project refers to an old version of the underlying library. At this time, I cannot upgrade the underlying library. The amount of changes in the underlying library should be too large. However, it is difficult for me to locate the commit code of the underlying library corresponding to the NuGet library that my project refers to. The latter can only be done by the dichotomy method, which took a few days of development to complete
So seeing the pit above me, my friends will probably know why I expect to associate the Tag with the NuGet package
In the agreement of my current team, as long as alpha is added as a preview version, you can push the test tag at will and let the server help you package the NuGet package, and then install it in other projects. Why would this be encouraged? The reason is that some friends said that the development of a certain project of mine depends on a certain library, but it is assumed that this library must be merged into the main branch before tag packaging, that is, the code of the little partner in a project will never be pushed. At the same time, small partners can not refer to a private version in csproj, because the private version can only be built by the small partners themselves, and other small partners can not build
Suppose little A needs to develop project F. Since this project has changed
library L. If library L changes are not merged into the master branch, it is not allowed to push Tag packaging.
At this time, if little A pushes the code, this code reference has not been released. The code of the L library, then other small partners will not be able to build through.
At this time, if small A pushes the code, this code refers to the NuGet library generated locally by small A, then other small partners will not find this NuGet library, unable to build through
If the small A does not push the code, just write a commit but this commit contains the code of the L library, but does not upgrade the L library version in csproj, then when the code is rolled back, entering this commit will fail to build
if the small A Upgrade to the NuGet library generated locally in the commit, then when the code is rolled back, because the local NuGet library of the small A does not exist on the public server, the build will still fail
At this time, a little friend named avatar came up with a bad idea. Although the A library code has not been merged, the small A can know the version number assigned after the L library is merged. At this time, update to this version in csproj, and then Reference and push through the local packaging method. But this method has the following problems
- The first time the small partner packed it locally and found that it was overturned and wanted to pack it for the second time, but the version numbers at this time overlapped, and it was necessary to delete the NuGet cache and rebuild it through black technology.
- The code that the small partner wrote in this commit is the public method he thinks will be added when it is released, but in fact the public method was changed when it was finally released. At this time, roll back to this commit, although it can be downloaded to the NuGet library, but found L library's public method does not match, build fails
This is the reason why the push tag is used for packaging. It allows small partners to choose the version of the preview version to push and automatically package, so that you can use the code of the preview version of this tag in the project. At this time, other small partners can also build the commit. When rolling back the code, you can also find the NuGet package on the public server or switch to the corresponding version of the source code