Now a day’s most of the organizations are following the path of Sitecore upgrade due to
increase demand from Business side and organizations not able to execute demand using the old Sitecore version.
In this case, organization need to go with Sitecore Upgrade, and I tried to explain the Sitecore Upgrade path at
Sitecore Upgrade Process which includes:
Sitecore Upgrade Articles:
Sitecore Upgrade Process
Sitecore Content Migration Using Sitecore Express Migration Tool
Sitecore Content Migration Using Sitecore Content Serialization Tool
Sitecore xDB Migration Using Sitecore xDB Data Migration Tool
To do the Sitecore Upgrade, we also need to look into the code base upgrade (Solution Upgrade) part also, and this piece of work required lot of effort because legacy code base may have:
o Many Projects for which assemblies reference need to be changed to matched with latest .NET and Sitecore Version Framework
o Many Project can have references of assemblies from physical folder instead of Nuget Packages
o Unnecessary assemblies references
By considering some items from above list, it’s going to have FUN while doing Sitecore Upgrade every time 😊.
To avoid these issues and save time every time during Sitecore Upgrade, its better to switch your code base to
PackageReference format with
Central Package Versions.
PackageReference not provide official support for ASP.NET Web Application (.NET Framework) based projects, but you can use it 😊:
Package references, using the PackageReference node, manage NuGet dependencies directly within project files (as opposed to a separate packages.config file).
By default, PackageReference is used for .NET Core projects, .NET Standard projects. .NET Framework projects support PackageReference, but currently default to packages.config. To use PackageReference, migrate the dependencies from packages.config into your project file, then remove packages.config.
The Microsoft.Build.CentralPackageVersions MSBuild project SDK allows project tree owners to manage their NuGet package versions in one place. Stock NuGet requires that each project contain a version. You can also use MSBuild properties to manage versions.
You can convert your solution to use PackageReference instead of packages.config by following the article
Migrate to PackageReference from packages config but I faced issue (please find below screenshot of error) so I followed the MANUAL approach:
In this article, we will explore:
Manual steps to convert your Sitecore Visual Studio Solution into PackageReference
To proceed with MANUAL steps for converting your code base with use of
PackageReference and
Central Package Versions at High-Level you have to follow below steps:
I will be explaining some steps which are annotated with numbers in the above flow diagram:
To implement the Microsoft.Build.CentralPackageVersions the first step is to create the MSBuild project at the root of your repository named Packages.props that declares PackageReference items that set the versions for projects:
The above Packages.props is an example, and we need to update Packages.props based on Step-6.
In the Packages.props file PropertyGroup > SitecoreVersion and PropertyGroup > SitecorePreVersion used as a variable to store the specific versions of assemblies.
Now we will create a Directory.Build.targets at the root of your repository to use Microsoft.Build.CentralPackageVersions (use the latest version):
We have to remove the Import tag above which are marked with RED, and there are some Import related to some assemblies e.g. BuildBundlerMinifier which also needs to be removed:
And for above type of Import assembly tag, we must insert PackageReference item for specific assembly in the Packages.props file after removing from .csproj file:
Reference tag’s which are not having HintPath you can keep it as is and remove rest of the Reference tag’s.
It’s always good to keep Reference tag’s and PackageReference tag’s separately in individual ItemGroup tag’s as a child elements:
Some assemblies references e.g., Microsoft.CodeDom.Providers.DotNetCompilerPlatform you can remove because once you remove it and reload the Project again then automatically VS Solution will add if required because these types of assemblies loads on the basis of Project Type.
The assemblies references which added in .csproj file as Reference under ItemGroup tag’s as a child elements will load without Nuget sign as highlighted with
BLUE border in above image and assemblies references which added in .csproj file as PackageReference under ItemGroup tag’s as a child elements will load with Nuget sign as highlighted with
GREEN border in above image.
If we have any assembly from \packages folder then we have to move those references from .csproj file to Packages.props if not present and in .csproj file change tag with PackageReference tag’s:
In step-6, we identified some assemblies which referenced from the
\packages folder and we have moved those references from .csproj file to Packages.props if not present:
In step-6, we have seen some assemblies which added with Reference tags and would be added again when we reload the Project Solution again on the basis of Project Type.
After all, above steps if required assemblies reloaded then either remove or rename packages.config file from Project Solution.
Items that require your attention
| 1 |
If you proceed with MANUAL steps for converting your code base with use of PackageReference (https://docs.microsoft.com/en-us/nuget/consume-packages/package-references-in-project-files) and Central Package Versions, then
you must remove the Import tag above which are marked with RED, and there are some Import related to some assemblies e.g., BuildBundlerMinifier which also needs to be removed.
|
| 2 |
Don’t check-in your \packages into code repository. |
| 3 |
After completing all the steps, you will find that \packages folder will not be having any assemblies:
|
| 4 |
To convert Sitecore Project Visual Studio solution from Sitecore 9.1 to Sitecore 10.0.0, I have used Microsoft Visual Studio Community 2019 (Version 16.11.6) |
Sitecore Project Solution on GitHub
I have upgraded Sitecore 9.1 Project Solution to Sitecore 10.0.0 Project Solution, and available for use at
Comments