Upgrade uitvoeren naar Azure Search .NET SDK versie 1.1
Als u versie 1.0.2-preview of ouder van de Azure Search .NET SDK gebruikt, helpt dit artikel u bij het upgraden van uw toepassing om versie 1.1 te gebruiken.
Zie Azure Search gebruiken vanuit een .NET-toepassing voor een algemeen overzicht van de SDK, inclusief voorbeelden.
Notitie
Wanneer u een upgrade uitvoert naar versie 1.1 of als u al een versie tussen 1.1 en 2.0 preview gebruikt, moet u upgraden naar versie 3. Zie Upgraden naar azure Search .NET SDK versie 3 voor instructies.
Werk eerst uw NuGet-verwijzing bij voor Microsoft.Azure.Search
het gebruik van de NuGet Pakketbeheer Console of door met de rechtermuisknop op uw projectverwijzingen te klikken en NuGet-pakketten beheren te selecteren... in Visual Studio.
Zodra NuGet de nieuwe pakketten en hun afhankelijkheden heeft gedownload, bouwt u uw project opnieuw.
Als u eerder versie 1.0.0-preview, 1.0.1-preview of 1.0.2-preview gebruikt, moet de build lukken en kunt u aan de slag.
Als u eerder versie 0.13.0 preview of ouder gebruikt, ziet u als volgt buildfouten:
Program.cs(137,56,137,62): error CS0117: 'Microsoft.Azure.Search.Models.IndexBatch' does not contain a definition for 'Create'
Program.cs(137,99,137,105): error CS0117: 'Microsoft.Azure.Search.Models.IndexAction' does not contain a definition for 'Create'
Program.cs(146,41,146,54): error CS1061: 'Microsoft.Azure.Search.IndexBatchException' does not contain a definition for 'IndexResponse' and no extension method 'IndexResponse' accepting a first argument of type 'Microsoft.Azure.Search.IndexBatchException' could be found (are you missing a using directive or an assembly reference?)
Program.cs(163,13,163,42): error CS0246: The type or namespace name 'DocumentSearchResponse' could not be found (are you missing a using directive or an assembly reference?)
De volgende stap is het oplossen van de buildfouten één voor één. Voor de meeste is het wijzigen van een aantal klasse- en methodenamen vereist die zijn gewijzigd in de SDK. Lijst met belangrijke wijzigingen in versie 1.1 bevat een lijst met deze naamwijzigingen.
Als u aangepaste klassen gebruikt om uw documenten te modelleren en deze klassen eigenschappen hebben van niet-nullable primitieve typen (bijvoorbeeld int
of bool
in C#), is er een foutoplossing in de versie 1.1 van de SDK waarvan u zich bewust moet zijn. Zie Oplossingen voor fouten in versie 1.1 voor meer informatie.
Ten slotte kunt u, zodra u buildfouten hebt opgelost, wijzigingen aanbrengen in uw toepassing om desgewenst te profiteren van nieuwe functionaliteit.
Lijst met belangrijke wijzigingen in versie 1.1
De volgende lijst wordt gerangschikt op basis van de kans dat de wijziging van invloed is op uw toepassingscode.
Wijzigingen in IndexBatch en IndexAction
IndexBatch.Create
is gewijzigd in IndexBatch.New
en heeft params
geen argument meer. U kunt IndexBatch.New
gebruiken voor batches die verschillende soorten acties combineren (samenvoegingen, verwijderingen, enzovoort). Daarnaast zijn er nieuwe statische methoden voor het maken van batches waarbij alle acties hetzelfde zijn: Delete
, Merge
, MergeOrUpload
, en Upload
.
IndexAction
heeft geen openbare constructors meer en de eigenschappen zijn nu onveranderbaar. U moet de nieuwe statische methoden gebruiken voor het maken van acties voor verschillende doeleinden: Delete
, Merge
, MergeOrUpload
, en Upload
.
IndexAction.Create
Verwijderd. Als u de overbelasting hebt gebruikt die alleen een document nodig heeft, moet u in plaats daarvan het document gebruiken Upload
.
Voorbeeld
Als uw code er als volgt uitziet:
var batch = IndexBatch.Create(documents.Select(doc => IndexAction.Create(doc)));
indexClient.Documents.Index(batch);
U kunt dit wijzigen om eventuele buildfouten op te lossen:
var batch = IndexBatch.New(documents.Select(doc => IndexAction.Upload(doc)));
indexClient.Documents.Index(batch);
Als u wilt, kunt u dit verder vereenvoudigen:
var batch = IndexBatch.Upload(documents);
indexClient.Documents.Index(batch);
IndexBatchException-wijzigingen
De naam van de IndexBatchException.IndexResponse
eigenschap is gewijzigd in IndexingResults
en het type is nu IList<IndexingResult>
.
Voorbeeld
Als uw code er als volgt uitziet:
catch (IndexBatchException e)
{
Console.WriteLine(
"Failed to index some of the documents: {0}",
String.Join(", ", e.IndexResponse.Results.Where(r => !r.Succeeded).Select(r => r.Key)));
}
U kunt dit wijzigen om eventuele buildfouten op te lossen:
catch (IndexBatchException e)
{
Console.WriteLine(
"Failed to index some of the documents: {0}",
String.Join(", ", e.IndexingResults.Where(r => !r.Succeeded).Select(r => r.Key)));
}
Wijzigingen in de bewerkingsmethode
Elke bewerking in de .NET SDK van Azure Search wordt weergegeven als een set overbelastingen van methoden voor synchrone en asynchrone bellers. De handtekeningen en factoring van deze methode overbelasten is gewijzigd in versie 1.1.
De bewerking Indexstatistieken ophalen in oudere versies van de SDK heeft bijvoorbeeld deze handtekeningen weergegeven:
In IIndexOperations
:
// Asynchronous operation with all parameters
Task<IndexGetStatisticsResponse> GetStatisticsAsync(
string indexName,
CancellationToken cancellationToken);
In IndexOperationsExtensions
:
// Asynchronous operation with only required parameters
public static Task<IndexGetStatisticsResponse> GetStatisticsAsync(
this IIndexOperations operations,
string indexName);
// Synchronous operation with only required parameters
public static IndexGetStatisticsResponse GetStatistics(
this IIndexOperations operations,
string indexName);
De methodehandtekeningen voor dezelfde bewerking in versie 1.1 zien er als volgt uit:
In IIndexesOperations
:
// Asynchronous operation with lower-level HTTP features exposed
Task<AzureOperationResponse<IndexGetStatisticsResult>> GetStatisticsWithHttpMessagesAsync(
string indexName,
SearchRequestOptions searchRequestOptions = default(SearchRequestOptions),
Dictionary<string, List<string>> customHeaders = null,
CancellationToken cancellationToken = default(CancellationToken));
In IndexesOperationsExtensions
:
// Simplified asynchronous operation
public static Task<IndexGetStatisticsResult> GetStatisticsAsync(
this IIndexesOperations operations,
string indexName,
SearchRequestOptions searchRequestOptions = default(SearchRequestOptions),
CancellationToken cancellationToken = default(CancellationToken));
// Simplified synchronous operation
public static IndexGetStatisticsResult GetStatistics(
this IIndexesOperations operations,
string indexName,
SearchRequestOptions searchRequestOptions = default(SearchRequestOptions));
Vanaf versie 1.1 organiseert de Azure Search .NET SDK verschillende bewerkingsmethoden:
- Optionele parameters worden nu gemodelleerd als standaardparameters in plaats van extra overbelasting van methoden. Dit vermindert het aantal overbelastingen van methoden, soms aanzienlijk.
- De extensiemethoden verbergen nu veel van de overbodige details van HTTP van de aanroeper. Oudere versies van de SDK hebben bijvoorbeeld een antwoordobject geretourneerd met een HTTP-statuscode, die u vaak niet hoeft te controleren omdat bewerkingsmethoden worden gegenereerd
CloudException
voor een statuscode die een fout aangeeft. Met de nieuwe extensiemethoden worden alleen modelobjecten geretourneerd, waardoor u de moeite hebt om ze in uw code uit te pakken. - Omgekeerd bieden de kerninterfaces nu methoden die u meer controle geven op HTTP-niveau als u deze nodig hebt. U kunt nu aangepaste HTTP-headers doorgeven die moeten worden opgenomen in aanvragen en het nieuwe
AzureOperationResponse<T>
retourtype geeft u directe toegang tot deHttpRequestMessage
enHttpResponseMessage
voor de bewerking.AzureOperationResponse
is gedefinieerd in deMicrosoft.Rest.Azure
naamruimte en vervangtHyak.Common.OperationResponse
.
Wijzigingen in ScoringParameters
Er is een nieuwe klasse met de naam ScoringParameter
toegevoegd in de nieuwste SDK, zodat u gemakkelijker parameters kunt opgeven voor scoreprofielen in een zoekquery. Eerder werd de ScoringProfiles
eigenschap van de SearchParameters
klasse getypt als IList<string>
; Nu is het getypt als IList<ScoringParameter>
.
Voorbeeld
Als uw code er als volgt uitziet:
var sp = new SearchParameters();
sp.ScoringProfile = "jobsScoringFeatured"; // Use a scoring profile
sp.ScoringParameters = new[] { "featuredParam-featured", "mapCenterParam-" + lon + "," + lat };
U kunt dit wijzigen om eventuele buildfouten op te lossen:
var sp = new SearchParameters();
sp.ScoringProfile = "jobsScoringFeatured"; // Use a scoring profile
sp.ScoringParameters =
new[]
{
new ScoringParameter("featuredParam", new[] { "featured" }),
new ScoringParameter("mapCenterParam", GeographyPoint.Create(lat, lon))
};
Modelklassewijzigingen
Vanwege de handtekeningwijzigingen die worden beschreven in bewerkingsmethodewijzigingen, zijn veel klassen in de Microsoft.Azure.Search.Models
naamruimte gewijzigd of verwijderd. Bijvoorbeeld:
-
IndexDefinitionResponse
is vervangen doorAzureOperationResponse<Index>
- De naam van
DocumentSearchResponse
is gewijzigd inDocumentSearchResult
- De naam van
IndexResult
is gewijzigd inIndexingResult
-
Documents.Count()
retourneert nu eenlong
met het aantal documenten in plaats van eenDocumentCountResponse
- De naam van
IndexGetStatisticsResponse
is gewijzigd inIndexGetStatisticsResult
- De naam van
IndexListResponse
is gewijzigd inIndexListResult
Om samen te vatten, OperationResponse
zijn -afgeleide klassen die alleen bestonden om een modelobject te verpakken, verwijderd. De resterende klassen hebben hun achtervoegsel gewijzigd van Response
.Result
Voorbeeld
Als uw code er als volgt uitziet:
IndexerGetStatusResponse statusResponse = null;
try
{
statusResponse = _searchClient.Indexers.GetStatus(indexer.Name);
}
catch (Exception ex)
{
Console.WriteLine("Error polling for indexer status: {0}", ex.Message);
return;
}
IndexerExecutionResult lastResult = statusResponse.ExecutionInfo.LastResult;
U kunt dit wijzigen om eventuele buildfouten op te lossen:
IndexerExecutionInfo status = null;
try
{
status = _searchClient.Indexers.GetStatus(indexer.Name);
}
catch (Exception ex)
{
Console.WriteLine("Error polling for indexer status: {0}", ex.Message);
return;
}
IndexerExecutionResult lastResult = status.LastResult;
Antwoordklassen en IEnumerable
Een extra wijziging die van invloed kan zijn op uw code is dat antwoordklassen die verzamelingen bevatten, niet meer worden geïmplementeerd IEnumerable<T>
. In plaats daarvan hebt u rechtstreeks toegang tot de verzamelingseigenschap. Als uw code er bijvoorbeeld als volgt uitziet:
DocumentSearchResponse<Hotel> response = indexClient.Documents.Search<Hotel>(searchText, sp);
foreach (SearchResult<Hotel> result in response)
{
Console.WriteLine(result.Document);
}
U kunt dit wijzigen om eventuele buildfouten op te lossen:
DocumentSearchResult<Hotel> response = indexClient.Documents.Search<Hotel>(searchText, sp);
foreach (SearchResult<Hotel> result in response.Results)
{
Console.WriteLine(result.Document);
}
Speciaal geval voor webtoepassingen
Als u een webtoepassing hebt die rechtstreeks wordt geserialiseerd DocumentSearchResponse
om zoekresultaten naar de browser te verzenden, moet u uw code wijzigen of worden de resultaten niet correct geserialiseerd. Als uw code er bijvoorbeeld als volgt uitziet:
public ActionResult Search(string q = "")
{
// If blank search, assume they want to search everything
if (string.IsNullOrWhiteSpace(q))
q = "*";
return new JsonResult
{
JsonRequestBehavior = JsonRequestBehavior.AllowGet,
Data = _featuresSearch.Search(q)
};
}
U kunt dit wijzigen door de .Results
eigenschap van het zoekantwoord op te halen om de weergave van zoekresultaten op te lossen:
public ActionResult Search(string q = "")
{
// If blank search, assume they want to search everything
if (string.IsNullOrWhiteSpace(q))
q = "*";
return new JsonResult
{
JsonRequestBehavior = JsonRequestBehavior.AllowGet,
Data = _featuresSearch.Search(q).Results
};
}
U moet zelf zoeken naar dergelijke gevallen in uw code; De compiler waarschuwt u niet omdat JsonResult.Data
het type object
is.
Wijzigingen in CloudException
De CloudException
klasse is verplaatst van de Hyak.Common
naamruimte naar de Microsoft.Rest.Azure
naamruimte. Ook is de naam van de Error
eigenschap gewijzigd in Body
.
Wijzigingen in SearchServiceClient en SearchIndexClient
Het type eigenschap Credentials
is gewijzigd van SearchCredentials
de basisklasse, ServiceClientCredentials
. Als u toegang nodig hebt tot een SearchCredentials
SearchIndexClient
of SearchServiceClient
, gebruikt u de nieuwe SearchCredentials
eigenschap.
In oudere versies van de SDK SearchServiceClient
en SearchIndexClient
had constructors die een HttpClient
parameter namen. Deze zijn vervangen door constructors die een HttpClientHandler
en een matrix van DelegatingHandler
objecten gebruiken. Hierdoor kunt u gemakkelijker aangepaste handlers installeren om HTTP-aanvragen vooraf te verwerken, indien nodig.
Ten slotte zijn de constructors die een Uri
en SearchCredentials
ander hebben genomen, gewijzigd. Als u bijvoorbeeld code hebt die er als volgt uitziet:
var client =
new SearchServiceClient(
new SearchCredentials("abc123"),
new Uri("http://myservice.search.windows.net"));
U kunt dit wijzigen om eventuele buildfouten op te lossen:
var client =
new SearchServiceClient(
new Uri("http://myservice.search.windows.net"),
new SearchCredentials("abc123"));
Houd er ook rekening mee dat het type van de parameter referenties is gewijzigd in ServiceClientCredentials
. Dit is onwaarschijnlijk dat dit van invloed is op uw code omdat SearchCredentials
deze is afgeleid van ServiceClientCredentials
.
Een aanvraag-id doorgeven
In oudere versies van de SDK kunt u een aanvraag-id instellen op de SearchServiceClient
of SearchIndexClient
en deze wordt in elke aanvraag opgenomen in de REST API. Dit is handig voor het oplossen van problemen met uw zoekservice als u contact moet opnemen met ondersteuning. Het is echter handiger om een unieke aanvraag-id in te stellen voor elke bewerking in plaats van dezelfde id te gebruiken voor alle bewerkingen. Daarom zijn de SetClientRequestId
methoden van SearchServiceClient
en SearchIndexClient
zijn verwijderd. In plaats daarvan kunt u een aanvraag-id doorgeven aan elke bewerkingsmethode via de optionele SearchRequestOptions
parameter.
Notitie
In een toekomstige release van de SDK voegen we een nieuw mechanisme toe voor het wereldwijd instellen van een aanvraag-id op de clientobjecten die consistent zijn met de benadering die wordt gebruikt door andere Azure SDK's.
Voorbeeld
Als u code hebt die er als volgt uitziet:
client.SetClientRequestId(Guid.NewGuid());
...
long count = client.Documents.Count();
U kunt dit wijzigen om eventuele buildfouten op te lossen:
long count = client.Documents.Count(new SearchRequestOptions(requestId: Guid.NewGuid()));
Wijzigingen in interfacenaam
De interfacenamen van de bewerkingsgroep zijn allemaal gewijzigd zodat ze consistent zijn met de bijbehorende eigenschapsnamen:
- De naam van
ISearchServiceClient.Indexes
het type is gewijzigd inIIndexOperations
IIndexesOperations
. - De naam van
ISearchServiceClient.Indexers
het type is gewijzigd inIIndexerOperations
IIndexersOperations
. - De naam van
ISearchServiceClient.DataSources
het type is gewijzigd inIDataSourceOperations
IDataSourcesOperations
. - De naam van
ISearchIndexClient.Documents
het type is gewijzigd inIDocumentOperations
IDocumentsOperations
.
Deze wijziging is waarschijnlijk niet van invloed op uw code, tenzij u voor testdoeleinden mocks van deze interfaces hebt gemaakt.
Opgeloste fouten in versie 1.1
Er is een fout opgeslagen in oudere versies van de Azure Search .NET SDK met betrekking tot serialisatie van aangepaste modelklassen. De fout kan optreden als u een aangepaste modelklasse hebt gemaakt met een eigenschap van een niet-nullable waardetype.
Stappen om te reproduceren
Maak een aangepaste modelklasse met een eigenschap van niet-nullable waardetype. Voeg bijvoorbeeld een openbare UnitCount
eigenschap van het type int
toe in plaats van int?
.
Als u een document indexeert met de standaardwaarde van dat type (bijvoorbeeld 0 voor int
), is het veld null in Azure Search. Als u vervolgens naar dat document zoekt, zal JsonSerializationException
de Search
oproep klagen dat het niet kan worden geconverteerd null
naar int
.
Filters werken mogelijk niet zoals verwacht, omdat null naar de index is geschreven in plaats van de beoogde waarde.
Details herstellen
Dit probleem is opgelost in versie 1.1 van de SDK. Als u nu een modelklasse als volgt hebt:
public class Model
{
public string Key { get; set; }
public int IntValue { get; set; }
}
en u instelt IntValue
op 0, die waarde wordt nu correct geserialiseerd als 0 op de kabel en opgeslagen als 0 in de index. Retourtrippen werkt ook zoals verwacht.
Er is een mogelijk probleem waar u rekening mee moet houden met deze methode: als u een modeltype met een niet-null-eigenschap gebruikt, moet u garanderen dat er geen documenten in uw index een null-waarde voor het bijbehorende veld bevatten. Met de SDK en de Azure Search REST API kunt u dit afdwingen.
Dit is niet alleen een hypothetische probleem: Stel een scenario voor waarin u een nieuw veld toevoegt aan een bestaande index van het type Edm.Int32
. Na het bijwerken van de indexdefinitie hebben alle documenten een null-waarde voor het nieuwe veld (omdat alle typen null in Azure Search zijn). Als u vervolgens een modelklasse met een niet-nullbare int
-eigenschap voor dat veld gebruikt, ontvangt u een JsonSerializationException
zoals deze bij het ophalen van documenten:
Error converting value {null} to type 'System.Int32'. Path 'IntValue'.
Daarom raden we u nog steeds aan om null-typen in uw modelklassen te gebruiken als best practice.
Zie dit probleem op GitHub voor meer informatie over deze fout en de oplossing.