A key component of digital experience management is effective information retrieval. A simplified approach is required for websites, applications, and platforms containing a lot of material so that consumers can easily get the data they require. This need is met by Sitecore, a well-known name in the field of digital experience platforms (DXPs), which provides powerful and comprehensive search functionality. We will travel into the realm of Sitecore Search in this article, learning about its capabilities, architecture , and the enormous value it offers both developers and end users. Introduction to Sitecore Search A headless content discovery platform powered by AI , Sitecore Search enables you to build predictive and custom search experiences across various content sources. To extract and ...
Get link
Facebook
X
Pinterest
Email
Other Apps
Speed Up Sitecore Upgrade with PackageReference
Get link
Facebook
X
Pinterest
Email
Other Apps
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:
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:
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:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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):
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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
This article will provide the details about Sitecore GraphQL queries usage and how it will be useful in creating Sitecore projects especially Sitecore JSS projects. The topics covered under this Sitecore GraphQL article are: • Overview of Sitecore GraphQL (GQL) • Setup GraphQL (GQL) in Sitecore • Usage of Sitecore GraphQL (GQL) in Sitecore JSS • GraphQL (GQL) Queries Usage o Get an item by path and show field id and name o Return the name and value from all fields o Get the values of Treelist or Multilist field type o Get the template field details with values of current item o Get the field values using Aliases o Return a specific field with Alias ...
The Headless development in Sitecore is powered by a layer of services, API endpoints, and rendering SDKs: Services and API endpoints Sitecore Headless Services Sitecore Experience Edge for XM Rendering SDKs Sitecore ASP.NET Rendering SDK Sitecore JavaScript Rendering SDKs (JSS) In this article, we will explore about Sitecore scalable API layer called Sitecore Experience Edge which provides you a Sitecore-hosted GraphQL (GQL) API. With these Edge GraphQL (GQL) endpoint you can build your solution in any language and pull the required content with the help of GraphQL (GQL) . The major GraphQL APIs of Sitecore Experience Edge are: Preview API Delivery API You can check more details about these APIs at Type of Sitecore Experience Edge API . GraphQL is a query language for these APIs t...
Sitecore Experience Manager Cloud, or XM Cloud is a game-changing force in the field of digital experience management in the age of cloud computing. We must identify the fundamental components that make up this cutting-edge platform in order to fully appreciate its capabilities. Join us as we dissect the fundamental elements that make up the Sitecore Experience Manager Cloud (or XM Cloud) architecture and investigate how they work together to produce a dynamic, scalable, and customized digital experience environment. Sitecore XM Cloud Overview The SaaS enterprise-ready , cloud-native CMS from Sitecore called the Experience Manager Cloud (XM Cloud) allows for the creation of content only once and delivers it to every channel for exceptional client experiences. Developers and marketers can q...
Comments