Anteckning
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
Alla utvecklare som skapar ClickOnce-distributioner planerar inte att distribuera själva programmen. Många av dem paketerade bara sitt program med Hjälp av ClickOnce och lämnar sedan ut filerna till en kund, till exempel ett stort företag. Kunden blir ansvarig för att vara värd för programmet i nätverket. I det här avsnittet beskrivs några av de problem som är förknippade med sådana distributioner i versioner av .NET Framework före version 3.5. Den beskriver sedan en ny lösning som tillhandahålls med hjälp av den nya funktionen "use manifest for trust" i .NET Framework 3.5. Slutligen avslutas den med rekommenderade strategier för att skapa ClickOnce-distributioner för kunder som fortfarande använder äldre versioner av .NET Framework.
Problem med att skapa distributioner för kunder
Flera problem uppstår när du planerar att tillhandahålla en distribution till en kund. Det första problemet gäller kodsignering. För att kunna distribueras i ett nätverk måste både distributionsmanifestet och programmanifestet för en ClickOnce-distribution signeras med ett digitalt certifikat. Detta väcker frågan om du vill använda utvecklarcertifikatet eller kundens certifikat när du signerar manifesten.
Frågan om vilket certifikat som ska användas är kritisk eftersom ett ClickOnce-programs identitet baseras på den digitala signaturen för distributionsmanifestet. Om utvecklaren signerar distributionsmanifestet kan det leda till konflikter om kunden är ett stort företag och mer än en avdelning i företaget distribuerar en anpassad version av programmet.
Anta till exempel att Adventure Works har en ekonomiavdelning och en personalavdelning. Båda avdelningarna licensierar ett ClickOnce-program från Microsoft Corporation som genererar rapporter från data som lagras i en SQL-databas. Microsoft förser varje avdelning med en version av programmet som är anpassat för deras data. Om programmen är signerade med samma Authenticode-certifikat skulle en användare som försöker använda båda programmen stöta på ett fel, eftersom ClickOnce skulle betrakta det andra programmet som identiskt med det första. I det här fallet kan kunden uppleva oförutsägbara och oönskade biverkningar som inkluderar förlust av data som lagras lokalt av programmet.
Ytterligare ett problem som rör kodsignering är elementet deploymentProvider i distributionsmanifestet, som talar om för ClickOnce var du ska söka efter programuppdateringar. Det här elementet måste läggas till i distributionsmanifestet innan det signeras. Om det här elementet läggs till efteråt måste distributionsmanifestet signeras igen.
Kräv att kunden signerar distributionsmanifestet
En lösning på det här problemet med icke-unika distributioner är att låta utvecklaren signera programmanifestet och kunden signerar distributionsmanifestet. Även om den här metoden fungerar introducerar den andra problem. Eftersom ett Authenticode-certifikat måste förbli en skyddad tillgång kan kunden inte bara ge certifikatet till utvecklaren för att signera distributionen. Kunden kan signera distributionsmanifestet med hjälp av verktyg som är fritt tillgängliga med .NET Framework SDK, men detta kan kräva mer teknisk kunskap än kunden vill eller kan tillhandahålla. I sådana fall skapar utvecklaren vanligtvis ett program, en webbplats eller en annan mekanism genom vilken kunden kan skicka sin version av programmet för signering.
Effekten av kundsignering på ClickOnce-programsäkerhet
Även om utvecklaren och kunden är överens om att kunden ska signera programmanifestet uppstår det andra problem som omger programmets identitet, särskilt när det gäller distribution av betrodda program. (Mer information om den här funktionen finns i Översikt över distribution av betrodda program.) Anta att Adventure Works vill konfigurera sina klientdatorer så att alla program som tillhandahålls av Microsoft Corporation körs med fullständigt förtroende. Om Adventure Works signerar distributionsmanifestet använder ClickOnce Adventure Work säkerhetssignatur för att fastställa programmets förtroendenivå.
Skapa distributioner till kunder med hjälp av programmanifest för pålitlighet
ClickOnce i .NET Framework 3.5 innehåller en ny funktion som ger utvecklare och kunder en ny lösning på scenariot med hur manifesten ska signeras. ClickOnce-programmanifestet stöder ett nytt element med namnet <useManifestForTrust> som gör det möjligt för en utvecklare att ange att den digitala signaturen för programmanifestet är det som ska användas för att fatta förtroendebeslut. Utvecklaren använder ClickOnce-paketeringsverktyg – till exempel Mage.exe, MageUI.exeoch Visual Studio – för att inkludera det här elementet i programmanifestet, samt för att bädda in både sitt Publisher-namn och namnet på programmet i manifestet.
När du använder <useManifestForTrust>behöver distributionsmanifestet inte signeras med ett Authenticode-certifikat som utfärdats av en certifikatutfärdare. I stället kan den signeras med det som kallas ett självsignerat certifikat. Ett självsignerat certifikat genereras av antingen kunden eller utvecklaren med hjälp av standardverktygen för .NET Framework SDK och tillämpas sedan på distributionsmanifestet med hjälp av standarddistributionsverktygen för ClickOnce. Mer information finns i MakeCert.
Att använda ett självsignerat certifikat för distributionsmanifestet medför flera fördelar. Genom att eliminera behovet av att kunden skaffar eller skapar ett eget Authenticode-certifikat förenklar <useManifestForTrust> du distributionen för kunden, samtidigt som utvecklaren kan behålla sin egen varumärkesidentitet i programmet. Resultatet är en uppsättning signerade distributioner som är säkrare och har unika programidentiteter. Detta eliminerar den potentiella konflikt som kan uppstå när samma program distribueras till flera kunder.
Stegvis information om hur du skapar en ClickOnce-distribution med <useManifestForTrust> aktiverad finns i Genomgång: Distribuera ett ClickOnce-program manuellt som inte kräver återsignering och som bevarar varumärkesinformation.
Så här fungerar programmanifestet för förtroende vid körning
Om du vill få en bättre förståelse för hur användning av programmanifestet för förtroende fungerar vid körning bör du överväga följande exempel. Ett ClickOnce-program som riktar sig till .NET Framework 3.5 skapas av Microsoft. Programmanifestet använder elementet <useManifestForTrust> och signeras av Microsoft. Adventure Works signerar distributionsmanifestet med hjälp av ett självsignerat certifikat. Adventure Works-klienter är konfigurerade för att lita på alla program som signerats av Microsoft.
När en användare klickar på en länk till distributionsmanifestet installerar ClickOnce programmet på användarens dator. Certifikat- och distributionsinformationen identifierar programmet unikt för ClickOnce på klientdatorn. Om användaren försöker installera samma program igen från en annan plats kan ClickOnce använda den här identiteten för att fastställa att programmet redan finns på klienten.
Därefter undersöker ClickOnce det Authenticode-certifikat som används för att signera programmanifestet, som avgör den förtroendenivå som ClickOnce kommer att bevilja. Eftersom Adventure Works har konfigurerat sina klienter att lita på alla program som har signerats av Microsoft beviljas det här ClickOnce-programmet fullständigt förtroende. Mer information finns i Översikt över distribution av betrodda program.
Skapa kunddistributioner för tidigare versioner
Vad händer om en utvecklare distribuerar ClickOnce-program till kunder som använder äldre versioner av .NET Framework? I följande avsnitt sammanfattas flera rekommenderade lösningar, tillsammans med fördelarna och nackdelarna med var och en.
Signera utplaceringar för kundens räkning
En möjlig distributionsstrategi är att utvecklaren skapar en mekanism för att signera distributioner för sina kunders räkning med hjälp av kundens egen privata nyckel. Detta förhindrar att utvecklaren behöver hantera privata nycklar eller flera distributionspaket. Utvecklaren tillhandahåller bara samma distribution till varje kund. Det är upp till kunden att anpassa den för sin miljö med hjälp av signeringstjänsten.
En nackdel med den här metoden är den tid och kostnad som krävs för att implementera den. Även om en sådan tjänst kan skapas med hjälp av de verktyg som tillhandahålls i .NET Framework SDK, lägger den till mer utvecklingstid i produktens livscykel.
Som tidigare nämnts i det här avsnittet är en annan nackdel att varje kunds version av programmet har samma programidentitet, vilket kan leda till konflikter. Om detta är ett problem kan utvecklaren ändra fältet Namn som används när distributionsmanifestet genereras för att ge varje program ett unikt namn. Detta skapar en separat identitet för varje version av programmet och eliminerar eventuella identitetskonflikter. Det här fältet motsvarar -Name argumentet för Mage.exeoch fältet Namn på fliken Namn i MageUI.exe.
Anta till exempel att utvecklaren har skapat ett program med namnet Application1. I stället för att skapa en enda distribution med fältet Namn inställt på Application1 kan utvecklaren skapa flera distributioner med en kundspecifik variant för det här namnet, till exempel Application1-CustomerA, Application1-CustomerB och så vidare.
Distribuera med hjälp av ett installationspaket
En andra möjlig distributionsstrategi är att generera ett Microsoft Setup-projekt för att utföra den första distributionen av ClickOnce-programmet. Detta kan anges i ett av flera olika format: som en MSI-distribution, som en körbar installation (.EXE) eller som en kabinettfil (.cab) tillsammans med ett batchskript.
Med den här tekniken skulle utvecklaren ge kunden en distribution som innehåller programfilerna, programmanifestet och ett distributionsmanifest som fungerar som en mall. Kunden skulle köra installationsprogrammet, vilket skulle uppmana dem att ange en distributions-URL (den server- eller filresursplats som användarna ska installera ClickOnce-programmet från) samt ett digitalt certifikat. Installationsprogrammet kan också välja att fråga efter ytterligare ClickOnce-konfigurationsalternativ, till exempel uppdateringskontrollintervall. När den här informationen har samlats in genererar installationsprogrammet det verkliga distributionsmanifestet, signerar det och publicerar ClickOnce-programmet på den avsedda serverplatsen.
Det finns tre sätt som kunden kan signera distributionsmanifestet på i den här situationen:
Kunden kan använda ett giltigt certifikat utfärdat av en certifikatutfärdare (CA).
Som en variant av den här metoden kan kunden välja att signera sitt distributionsmanifest med ett självsignerat certifikat. Nackdelen med detta är att det gör att programmet visar orden "Okänd utgivare" när användaren tillfrågas om att installera den. Fördelen är dock att det hindrar mindre kunder från att behöva spendera den tid och de pengar som krävs för ett certifikat som utfärdats av en certifikatutfärdare.
Slutligen kan utvecklaren inkludera ett eget självsignerat certifikat i installationspaketet. Detta introducerar potentiella problem med programidentiteten som beskrevs tidigare i det här avsnittet.
Nackdelen med installationsprojektmetoden är den tid och kostnad som krävs för att skapa ett anpassat distributionsprogram.
Låta kunden generera distributionsmanifest
En tredje möjlig distributionsstrategi är att endast lämna ut programfilerna och programmanifestet till kunden. I det här scenariot ansvarar kunden för att använda .NET Framework SDK för att generera och signera distributionsmanifestet.
Nackdelen med den här metoden är att det kräver att kunden installerar .NET Framework SDK-verktygen och har en utvecklare eller systemadministratör som är skicklig på att använda dem. Vissa kunder kan kräva en lösning som kräver lite eller ingen teknisk ansträngning från deras sida.