Dela via


Problem med säkerhet, versionshantering och manifest i ClickOnce-distributioner

Det finns en mängd olika problem med ClickOnce-säkerhet, programversionshantering och manifestsyntax och semantik som kan leda till att en ClickOnce-distribution inte lyckas.

ClickOnce och Windows User Account Control

I Windows Vista och senare versioner av Windows körs program som standard som standardanvändare, även om den aktuella användaren är inloggad med ett konto som har administratörsbehörighet. Om ett program måste utföra en åtgärd som kräver administratörsbehörighet, meddelar det operativsystemet, som sedan uppmanar användaren att ange sina administratörsautentiseringsuppgifter. Den här funktionen, som heter User Account Control (UAC), förhindrar att program gör ändringar som kan påverka hela operativsystemet utan en användares uttryckliga godkännande. Windows-program deklarerar att de kräver den här behörighetshöjningen genom att ange [requestedExecutionLevel] attributet i [trustInfo] avsnittet i programmanifestet.

På grund av risken för att exponera program för säkerhetshöjningsattacker kan ClickOnce-program inte begära behörighetshöjning om UAC är aktiverat för klienten. Alla ClickOnce-program som försöker ange sitt requestedExecutionLevel-attribut till requireAdministrator eller highestAvailable kommer inte att installeras på Windows Vista och senare versioner.

I vissa fall kan ditt ClickOnce-program försöka köras med administratörsbehörighet på grund av installationsidentifieringslogik i Windows. I det här fallet kan du ange requestedExecutionLevel attributet i programmanifestet till asInvoker. Detta gör att själva programmet körs utan utökade privilegier. Visual Studio lägger automatiskt till det här attributet i alla programmanifest.

Om du utvecklar ett program som kräver administratörsbehörighet under hela programmets livslängd bör du överväga att distribuera programmet med hjälp av MSI-teknik (Windows Installer) i stället. Mer information finns i Grunderna för Windows Installer.

Programkvoter online och program med partiellt förtroende

Om ditt ClickOnce-program körs online i stället för via en installation måste det passa in i den kvot som har reserverats för onlineprogram. Dessutom kan ett nätverksprogram som körs i delvis förtroende, till exempel med en begränsad uppsättning säkerhetsbehörigheter, inte vara större än hälften av kvotstorleken.

Anmärkning

I ClickOnce för .NET Core och .NET 5 eller senare stöds inte partiellt förtroende, som kräver kodåtkomstsäkerhet. I .NET Framework är användningen av Code Access Security inte en bra metod och rekommenderas inte.

Mer information och instruktioner om hur du ändrar kvoten för onlineprogram finns i Översikt över ClickOnce-cache.

Problem med versionshantering

Du kan få problem om du tilldelar starka namn till din sammansättning och ökar sammansättningsversionsnumret så att det återspeglar en programuppdatering. Alla sammansättningar som kompileras med en referens till en stark namngiven sammansättning måste omkompileras, annars försöker sammansättningen referera till den äldre versionen. Sammansättningen provar detta eftersom sammansättningen använder det gamla versionsvärdet i sin bindningsbegäran.

Anta till exempel att du har en starknamngiven assembly i ett eget projekt med version 1.0.0.0. När du har sammanställt sammansättningen lägger du till den som en referens till projektet som innehåller huvudprogrammet. Om du uppdaterar sammansättningen, ökar versionen till 1.0.0.1 och försöker distribuera den utan att även kompilera om programmet, kommer programmet inte att kunna läsa in sammansättningen vid körning.

Det här felet kan bara inträffa om du redigerar ClickOnce-manifesten manuellt. Du bör inte uppleva det här felet om du genererar distributionen med Hjälp av Visual Studio.

Ange enskilda .NET Framework-sammansättningar i manifestet

Din applikation kommer att misslyckas att läsa in om du har redigerat en ClickOnce-distribution manuellt för att referera till en äldre version av en .NET Framework-sammansättning. Om du till exempel har lagt till en referens till System.Net-sammansättningen för en version av .NET Framework innan den version som anges i manifestet uppstår ett fel. I allmänhet bör du inte försöka ange referenser till enskilda .NET Framework-sammansättningar, eftersom versionen av .NET Framework som programmet körs mot anges som ett beroende i programmanifestet.

Problem med att tolka manifestet

Manifestfilerna som används av ClickOnce är XML-filer, och de måste vara både välformulerade och giltiga: de måste följa XML-syntaxreglerna och endast använda element och attribut som definierats i relevant XML-schema.

Något som kan orsaka problem i en manifestfil är att välja ett namn för ditt program som innehåller ett specialtecken, till exempel ett enkelt eller dubbelt citattecken. Programmets namn är en del av dess ClickOnce-identitet. ClickOnce parsar för närvarande inte identiteter som innehåller specialtecken. Om programmet inte kan aktiveras kontrollerar du att du bara använder alfabetiska och numeriska tecken för namnet och försöker distribuera det igen.

Om du har redigerat distributions- eller programmanifesten manuellt kan du oavsiktligt ha skadat dem. Ett skadat manifest förhindrar en korrekt ClickOnce-installation. Du kan felsöka sådana fel vid körning genom att klicka på Information i dialogrutan ClickOnce-fel och läsa felmeddelandet i loggen. Loggen visar ett av följande meddelanden:

  • En beskrivning av syntaxfelet och radnumret och teckenpositionen där felet inträffade.

  • Namnet på ett element eller attribut som används i strid med manifestets schema. Om du har lagt till XML manuellt i manifesten måste du jämföra dina tillägg med manifestschemana. Mer information finns i ClickOnce-distributionsmanifestet och ClickOnce-programmanifestet.

  • En ID-konflikt. Beroendereferenser i distributions- och programmanifest måste vara unika i både deras name attribut och publicKeyToken attribut. Om attributen matchar mellan två element i ett manifest kommer manifestparseringen inte att lyckas.

Försiktighetsåtgärder vid manuellt ändring av manifest eller program

När du uppdaterar ett programmanifest måste du signera om både programmanifestet och distributionsmanifestet. Distributionsmanifestet innehåller en referens till programmanifestet som innehåller den filens hash och dess digitala signatur.

Försiktighetsåtgärder vid användning av distributionsprovider

ClickOnce-distributionsmanifestet har en deploymentProvider egenskap som pekar på den fullständiga sökvägen till platsen där programmet ska installeras och underhållas:

<deploymentProvider codebase="http://myserver/myapp.application" />

Den här sökvägen anges när ClickOnce skapar programmet och är obligatoriskt för installerade program. Sökvägen pekar på den standardplats där Installationsprogrammet ClickOnce installerar programmet från och söker efter uppdateringar. Om du använder xcopy-kommandot för att kopiera ett ClickOnce-program till en annan plats, men inte ändrar deploymentProvider egenskapen, refererar ClickOnce fortfarande tillbaka till den ursprungliga platsen när det försöker ladda ned programmet.

Om du vill flytta eller kopiera ett program måste du också uppdatera deploymentProvider sökvägen så att klienten faktiskt installeras från den nya platsen. Att uppdatera den här sökvägen är främst ett problem om du har installerat program. För onlineprogram som alltid startas via den ursprungliga URL:en är inställningen deploymentProvider valfri. Om deploymentProvider anges kommer det att respekteras. Annars används den URL som används för att starta programmet som bas-URL för att ladda ned programfiler.

Anmärkning

Varje gång du uppdaterar manifestet måste du också signera det igen.

Felsöka ClickOnce-distributionerSäkra ClickOnce-programVälj en ClickOnce-distributionsstrategi