Our .NET development references many external Nuget packages, multiple projects, multiple solutions, and even multiple repositories.
Simple Nuget package management is relatively easy to handle with VS. But what about complex scenarios like:
1. Nuget package management with multiple solutions in one repository -- this is what I have in my current project, a code repository for the Family Bucket software set for conference big screens. In this repository, close to 30 tools/applications:
2. Multiple warehouses, multiple solutions, multiple projects Nuget management -- the company's products and projects are more complex business, pumping a lot of components (currently 53), the need to deal with version conflicts between components, as well as because of version dependencies need to incrementally upgrade their own version number.
These complex scenarios can create inefficiencies for fellow developers to manipulate and manage code.
So how to efficiently deal with the Nuget version conflict between projects, how to quickly upgrade the Nuget version, how to solve multiple projects on the Nuget component source code for rapid debugging, the following we are introduced separately
Nuget version harmonization, version upgrades
Project Csproj references Nuget package to manage multiple project solutions, through the VS Nuget management page and CsProj file editing can be resolved in most cases of Nuget version of the operation .
Slightly more complex multi-solution scenarios within the warehouse, via MVP Dhee Big Brotherlindexi - Blogland () The reminder that centralized package management, i.e., documentation, can also manage Nuget packages within a repository.Centralized Package Management | Microsoft LearnThe following are some examples of how you can do this. Configure the public Nuget package versions in the repository, and then Csproj references the appropriate Nuget packages as needed.
1 <Project Sdk=""> 2 <PropertyGroup> 3 <TargetFramework>net6.0</TargetFramework> 4 </PropertyGroup> 5 <ItemGroup> 6 <PackageReference Include="" /> 7 </ItemGroup> 8 </Project>
However, I actually don't personally recommend it. If a new Nuget is added that references DirectShowLib, VS again defaults to adding the version number within the CSproj file, unautomatically categorized within:
You need to add the Nuget version information under the solution or repository according to the central package management path. This solution has some modification costs, and I personally feel that the project's Nuget reference version number is not conspicuous enough, and the readability will be weakened.
Continuing to manage Nuget packages with csproj, the cost of managing between multiple projects we solved with tools:WindowsOrg/NugetEfficientTool: VisualStudio Project Development - Nuget Operational Efficiency Tool ()
The image below shows the Nuget version detection of the folder where the Family Bucket app set is located, using the Nuget versioning tool:
Follow the interface shown above:
1. Project path, enter the directory where the repository code is located (can also be an external directory), the path to the solution sln file
2. Click "Start Detection", it will display the Nuget to be repaired information. As shown above, there are many csproj files with the same version, but not with the latest version of the Nuget source, you need to upgrade!
3. Click "Repair Version Conflict" to bring up the version selection window, select the appropriate version to perform the repair. After execution, csproj will be synchronized with version 1.1.15.
When selecting a version, you can select all or specify the Nuget synchronization version number.
Nuget versioning tool, which is based on the little buddy boogie tool versiondotnet-campus/ ()Optimized and improved. Functionality currently implemented in the tool:
1. Synchronize Nuget versions under one solution
2. Synchronize Nuget versions for multiple solutions in one folder
3. Support for setting up Nuget sources and synchronized upgrading of Nuget versions (the above screenshot shows this scenario)
The principle of Nuget version synchronization is to get all the csproj files under the path, and parse out the PackageReference information of the referenced Nuget - Nuget name, version number. List these different versions of Nuget, let the developer choose the version number that needs to be downgraded or upgraded, and then modify the version number of the Nuget reference in the saved csproj file again.
Get all PackageReference nodes within a csproj document:
1 /// <summary> 2 /// Get the node corresponding to the PackageReference name. 3 /// </summary> 4 /// <param name="xDocument"></param> 5 /// <returns></returns> 6 private List<XElement> GetPackageReferenceElements(XDocument xDocument) 7 { 8 if (xDocument == null) 9 { 10 throw new ArgumentNullException(nameof(xDocument)); 11 } 12 var xElementList = new List<XElement>(); 13 var itemGroupElements = ().Where(x => == "ItemGroup"); 14 foreach (var itemGroupElement in itemGroupElements) 15 { 16 (().Where(x => == "PackageReference")); 17 } 18 return xElementList; 19 }
In addition, for multiple warehouses multiple solutions for component set version number synchronization scenarios, the following 53 component warehouses more than 70 Nuget package is introduced how to solve the problem of version dependency between the Nuget key.Nuget versioning tool in combination with Jenkins to do a version number of the automatic construction:
1. clone all component repositories under the component set workgroup and compile multiple solutions in parallel
2. Execute the Nuget versioning tool in the background, and Nuget in the csproj file is automatically upgraded to the highest version. Meanwhile, if there is any reference change in the csproj file, the version number of the current component itself will be added with a new build number.
3. Cycle through step 2 until all csproj files have the same version of the same Nuget package.
4. Save archived Nuget packages to the server, Git Push all component repository changes to csproj files
The following figure shows the log of the process of synchronizing the Nuget package version in Jenkins in a particular one-click synchronization:
You can directly download the Nuget tool if you need it:Nuget Tools_1.0.3.，Execute with command line arguments to upgrade the version numbers of all components in the directory: D:\Gitlab-Company\Components
Nuget Source Code Replacement
Development applications, encountered the need to debug the internal Nuget source code, generally we are uninstalling the Nuget package, and then refer to the source component project csproj.
This operation, 1-2 project operation is okay, meet dozens of projects need to replace the Nuget source project code, the efficiency is very low!
Simple and repetitive things are simplified by tools, and here too the Nuget tool operates:
1. Project path, enter the directory where the repository code is located (can also be a multi-repository directory), or the repository solution.sln file path
2. Enter the path to the source csproj file corresponding to the Nuget package, or the directory where the csproj is located. After you enter it, the Nuget name will be automatically populated.
3. Click "Replace", replace all csproj projects within the Nuget reference PackageReference, for the project reference ProjectReference, you can start the source code debugging!
After debugging the code, you can click "Restore" to withdraw the replacement of the Nuget source code. Then Nuget source code can be submitted to the code, archived Nuget package for the upper tier applications to use.
Isn't it very convenient? Here Nuget replacements, supported by the current version:
1. One solution, replacement of multiple Nuget sources
2. Catalogs i.e. multiple solutions, replacement of multiple Nuget sources
3. Support for multiple interdependent Nuget package replacement (automatic identification of dependencies) and restore
Supports Nuget replacement in the catalog, which greatly improves the efficiency of multi-project multi-warehouse co-development, see a particular operation:
The project I'm working on is a conference software set (family bucket) for intelligent interactive big screen conference scenarios, and there are too many applications. Sometimes to fix a bug in a camera component, manual operation requires opening each solution and replacing the source code, which is a waste of time.
And through the Nuget tool to replace all the Nuget source code, and then use the VS Solution Manager to switch the view, you can open the project very quickly to confirm the source code, debugging, efficiency gains by an order of magnitude!
Here's the Nuget replacement, the most initial version is the little buddy Junjie studentJ. Sunbathing Cat - Blogland () The initial version was developed to run as an extension within VS. Unfortunately I don't have his source code, so I developed a separate exe version of the Nuget tool for my personal needs.
the main logic of which.
1. Solution, add Nuget name item:
1 var solutionFileLines = (_solutionFile).ToList(); 2 //Add Project 3 var previousProjectIndex = (i => (StartProjectRex)); 4 var previousProjectLine = solutionFileLines[previousProjectIndex]; 5 var solutionId = (StartProjectRex, string.Empty).Substring(0, GuidLength); 6 var newProjectLine = $"{StartProjectRex}{solutionId}}}\") = \"{_nugetName}\", \"{_sourceProjectFile}\", \"{{{_newProjectId}}}\""; 7 (previousProjectIndex + 2, "EndProject"); 8 (previousProjectIndex + 2, newProjectLine); 9 //Adding Compilation Configuration 10 var projectConfigStartIndex = (i => ("ProjectConfigurationPlatforms")); 11 var projectConfigEndIndex = (projectConfigStartIndex + 1, i => ("EndGlobalSection")); 12 (projectConfigEndIndex, $"{{{_newProjectId}}}.Debug|Any .0 = Release|Any CPU"); 13 (projectConfigEndIndex, $"{{{_newProjectId}}}.Debug|Any .0 = Release|Any CPU"); 14 (projectConfigEndIndex, $"{{{_newProjectId}}}.Release|Any .0 = Release|Any CPU"); 15 (projectConfigEndIndex, $"{{{_newProjectId}}}.Release|Any .0 = Release|Any CPU"); 16 (_solutionFile, solutionFileLines, Encoding.UTF8);
2. Csprj file, replace the Nuget reference with a project reference to the source project csproj:
1 public ReplacedFileRecord ReplaceNuget() 2 { 3 var nugetInfoReferences = (Document).ToList(); 4 var referenceElement = (x => (x).Name == _nugetName); 5 if (referenceElement == null) 6 { 7 return null; 8 } 9 //Getting Nuget references 10 var replacedFileRecord = GetNugetReferenceInfo(referenceElement, (referenceElement)); 11 //Removing references to Nuget 12 (); 13 //Adding a reference to the source project 14 AddSourceReference(); 15 SaveFile(); 16 return replacedFileRecord; 17 }
A csproj file that may have multiple records that replace Nuget, which are used for subsequent restore operations:
1 /// <summary> 2 /// One file Nuget change log 3 /// </summary> 4 [DataContract] 5 public class ReplacedFileRecord 6 { 7 /// <summary> 8 /// Nuget name 9 /// </summary> 10 [DataMember] 11 public string NugetName { get; set; } 12 /// <summary> 13 /// Name of the document 14 /// </summary> 15 [DataMember] 16 public string FileName { get; set; } 17 /// <summary> 18 /// change location 19 /// </summary> 20 [DataMember] 21 public int ModifiedLineIndex { get; set; } 22 /// <summary> 23 /// Nuget version 24 /// </summary> 25 [DataMember] 26 public string Version { get; set; } 27 [CanBeNull] 28 [DataMember] 29 public string TargetFramework { get; set; } 30 [CanBeNull] 31 [DataMember] 32 public string NugetDllPath { get; set; } 33 /// <summary> 34 /// Nuget referencing method 35 /// </summary> 36 [DataMember] 37 public string ReferenceType { get; set; } 38 }
Nuget Tools:Nuget Tools_1.0.3.The latest version, as well as the source code, is detailed:WindowsOrg/NugetEfficientTool: VisualStudio Project Development - Nuget Operational Efficiency Tool ()
Keywords: Nuget package management, Nuget source code debugging, NugetEfficientTool