Dela via

Självstudie: Arbeta med Django-webbramverket i Visual Studio

Den här artikeln är det första steget i en självstudieserie i fem delar som visar hur du arbetar med Django i Visual Studio. Django är ett python-ramverk på hög nivå som är utformat för snabb, säker och skalbar webbutveckling. Visual Studio tillhandahåller projektmallar som du kan använda för att effektivisera skapandet av Django-baserade webbprogram. Den här självstudieserien utforskar Django-ramverket i kontexten för Visual Studio-projektmallarna.

I steg 1 i självstudien lär du dig att:

  • Skapa ett Django-webbappsprojekt med hjälp av mallen Blank Django Web Project
  • Granska boilerplate-koden och kör appen
  • Skapa en Git-lagringsplats för Django-webbappen
  • Arbeta med Git-källkodskontroller
  • Skapa en virtuell miljö för Django-webbappen

Förutsättningar

  • Visual Studio 2022 eller senare i Windows med följande alternativ valda i Visual Studio Installer:

    • På fliken Arbetsbelastningar väljer du alternativet Python-utveckling . Mer information finns i Installera Python-stöd i Visual Studio.

    • På fliken Enskilda komponenter under Kodverktyg väljer du alternativet Git för Windows .

  • Visual Studio 2017 eller senare i Windows med följande alternativ valda i Visual Studio Installer:

    • På fliken Arbetsbelastningar väljer du alternativet Python-utveckling . Mer information finns i Installera Python-stöd i Visual Studio.

    • På fliken Enskilda komponenter under Kodverktyg väljer du alternativen Git för Windows och GitHub-tillägget för Visual Studio .

Django-projektmallar i Visual Studio ingår i alla tidigare versioner av Python Tools för Visual Studio. Mallinformationen kan skilja sig från beskrivningarna i den här självstudieserien, särskilt för tidigare versioner av Django-webbramverket.

Visual Studio för Mac stöds inte. Mer information finns i Vad händer med Visual Studio för Mac? Visual Studio Code på Windows, Mac och Linux fungerar bra med Python via tillgängliga tillägg.

Visual Studio-projekt och Django-projekt

I Django-terminologi har ett Django-projekt flera konfigurationsfiler på platsnivå tillsammans med en eller flera "appar". Om du vill skapa ett fullständigt webbprogram kan du distribuera dessa appar till en webbvärd. Ett Django-projekt kan innehålla flera appar och samma app kan finnas i flera Django-projekt.

Ett Visual Studio-projekt kan innehålla Django-projektet tillsammans med flera appar. I den här självstudieserien refererar termen "projekt" till Visual Studio-projektet. När innehållet refererar till "Django-projektet" i webbappen refererar det specifikt till ett "Django-projekt".

Skapa Visual Studio-projekt och lösning

I steg 1 i den här självstudieserien skapar du en enda Visual Studio-lösning som innehåller flera Django-projekt. Varje projekt innehåller en enda Django-app. Du skapar projekten med hjälp av olika Django-projektmallar som ingår i Visual Studio. Genom att hålla projekten i samma lösning kan du enkelt växla fram och tillbaka mellan olika filer för jämförelse.

När du arbetar med Django från kommandoraden startar du vanligtvis ett projekt genom att django-admin startproject <project_name> köra kommandot . I Visual Studio tillhandahåller mallen Blank Django Web Project samma struktur i ett Visual Studio-projekt och en lösning.

Följ den här proceduren för att skapa lösningen och projektet:

  1. I Visual Studio väljer du Arkiv>Nytt>projekt och söker efter "Django". Välj sedan mallen Tom Django Web Project och välj Nästa.

    Skärmbild som visar hur du väljer mallen Blank Django Web Project i Visual Studio 2022.

  2. Konfigurera ditt nya projekt och din lösning:

    1. Ange Namnet på Visual Studio-projektet till BasicProject. Det här namnet används också för Django-projektet.

    2. Ange plats för Visual Studio för att spara lösningen och projektet.

    3. Avmarkera alternativet Placera lösningen och projektet i samma katalog.

    4. Ange Lösningsnamnet till LearningDjango. Lösningen fungerar som container för flera projekt i den här självstudieserien.

  3. Välj Skapa.

  4. Efter en stund visar Visual Studio meddelandet Python-paketspecifikationsfilen "requirements.txt" identifierades i projektet "BasicProject".:

    Skärmbild av uppmaningen som anger att en kravfil för projektet identifieras i Visual Studio.

    Dialogrutan anger att den valda mallen innehåller en requirements.txt fil som du kan använda för att skapa en virtuell miljö för projektet.

  5. Till höger, välj X för att stänga meddelandet. Senare i den här självstudien skapar du den virtuella miljön och ser till att källkontrollen utesluter miljön. (Miljön kan alltid skapas senare från requirements.txt-filen .)

  1. I Visual Studio väljer du Arkiv>Nytt>Projekt och söker efter "Django". Välj sedan mallen Tomt Django Webbprojekt. (Mallen finns också i dialogrutan under Python>Webb i listan till vänster.)

    Skärmbild som visar hur du väljer mallen Blank Django Web Project i Visual Studio 2019.

  2. Längst ned i dialogrutan konfigurerar du det nya projektet och lösningen:

    1. Ange Namnet på Visual Studio-projektet till BasicProject. Det här namnet används också för Django-projektet.

    2. Ange plats för Visual Studio för att spara lösningen och projektet.

    3. Ange Lösningsnamnet till LearningDjango. Lösningen fungerar som container för flera projekt i den här självstudieserien.

    4. Välj alternativet Skapa katalog för lösning (standard).

    5. Välj alternativet Skapa ny Git-lagringsplats . Visual Studio skapar en lokal Git-lagringsplats när lösningen skapas.

      Om du inte ser det här alternativet kör du Installationsprogrammet för Visual Studio. På fliken Enskilda komponenter under Kodverktyg lägger du till alternativen Git för Windows och GitHub-tillägget för Visual Studio .

  3. Välj OK.

  4. Efter en stund visar Visual Studio uppmaningen Det här projektet kräver externa paket:

    Skärmbild av uppmaningen som anger att projektet kräver externa Django-paket i Visual Studio.

    Dialogrutan anger att den valda mallen innehåller en requirements.txt fil som refererar till det senaste Django 1.x-paketet. Du kan välja Visa nödvändiga paket för att se de exakta beroendena.

  5. Välj alternativet Jag ska installera dem själv för att stänga dialogrutan. Senare i den här självstudien skapar du den virtuella miljön och ser till att källkontrollen utesluter miljön. (Miljön kan alltid skapas senare från requirements.txt-filen .)

Granska Git-kontroller

I nästa procedur bekantar du dig med Visual Studio-stöd för Git-källkontroll.

Viktigt!

I Visual Studio 2019 och senare är Git-versionskontrollfunktionen aktiverad som standard. Om du vill veta mer om hur det jämförs med Team Explorer kan du läsa jämförelsen sida vid sida av Git och Team Explorer .

Om du föredrar att fortsätta att använda Team Explorer i tidigare versioner av Visual Studio går du till Verktyg>alternativ>Miljöförhandsgranskningsfunktioner> och växlar kryssrutan Ny Git-användarupplevelse.

  1. Om du vill checka in projektet i din lokala källkontroll väljer du Lägg till i källkontroll längst ned till höger i Visual Studio-huvudfönstret och väljer sedan Git:

    Skärmbild som visar hur du skapar en Git-lagringsplats i Visual Studio 2022.

    Fönstret Skapa Git-lagringsplats öppnas, där du kan skapa och push-överföra en ny lagringsplats.

  2. När du har skapat en lagringsplats visas Git-kontrollfältet längst ned till höger i Visual Studio-huvudfönstret:

    Skärmbild som visar Git-kontrollerna längst ned till höger i Visual Studio-huvudfönstret.

    Från vänster till höger visar Git-kontrollfältet antalet utgående/inkommande incheckningar (pilar #/#), antalet ogenomförda ändringar (penna #), det aktuella grennamnet och det aktuella lagringsplatsens namn. Git-kontroller är också tillgängliga på Git-menyn i huvudverktygsfältet.

  3. I fältet Git-kontroller väljer du ändringarna (pennan #) för att öppna fönstret Git-ändringar . Du kan också välja Visa Git-ändringar> (Ctrl+O, Ctrl+G):

    Skärmbild av fönstret Git-ändringar i Visual Studio som visar aktuella incheckningar, ändringar och häften.

    Det här fönstret visar information om eventuella icke-bakåtkompatibla ändringar, inklusive undangömda ändringar. Eftersom det nyligen skapade projektet redan har checkats in till källkontrollen automatiskt ser du inga väntande ändringar.

  4. I git-kontrollfältet väljer du incheckningarna (pilarna #/#) och väljer sedan Visa alla incheckningar:

    Skärmbild som visar hur du öppnar Git-lagringsplatsen från Git-kontrollfältet med kommandot Visa alla incheckningar.

    Git-lagringsplatsfönstret öppnas. Du kan också välja Visa>Git-lagringsplats (Ctrl+O, Ctrl+R):

    Skärmbild som visar Git-lagringsplatsens fönster i Visual Studio.

    Det här fönstret visar detaljer för det aktuella repositoriet i den vänstra panelen och den nuvarande grenen med utgående/inkommande commitmenter i den högra panelen.

    För att se skillnadsvyn för filen, välj en commit i mittenfönstret. Den tidigare versionen visas till vänster och den ändrade versionen visas till höger. Informationen innehåller också ändringsförfattaren, ändringsutföraren och committeringsmeddelandet.

Eftersom du valde alternativet Skapa ny Git-lagringsplats i dialogrutan Nytt projekt har projektet redan checkats in på den lokala källkontrollen så snart skapandeprocessen är klar. I den här proceduren bekantar du dig med Git-kontrollerna i Visual Studio och fönstret Team Explorer där du arbetar med källkontroll.

  1. Granska Git-kontrollerna i det nedre hörnet av Visual Studio-huvudfönstret. Från vänster till höger visar dessa kontroller okomprifierade incheckningar (pil #), ogenomförda ändringar (penna #), namnet på lagringsplatsen och den aktuella grenen:

    Skärmbild av verktygsfältet Git-kontroller i Visual Studio-fönstret.

    Anmärkning

    Om du inte väljer skapa en ny Git-lagringsplats i dialogrutan Nytt projekt visar Git-kontrollerna endast kommandot Lägg till i källkontroll som skapar en lokal lagringsplats.

    Skärmbild som visar hur kommandot Lägg till i källkontroll visas i Visual Studio om du inte har skapat en lagringsplats.

  2. Välj ändringarna (pennan #) och Visual Studio öppnar fönstret Team Explorer på sidan Ändringar . Eftersom det nyligen skapade projektet redan har checkats in i versionshanteringen automatiskt ser du inga väntande ändringar.

    Skärmbild av fönstret Team Explorer på sidan Ändringar.

  3. På Visual Studios statusfält väljer du kommandon (pilen #) för att öppna sidan Synkronisering i Team Explorer. Eftersom du bara har en lokal lagringsplats ger sidan enkla alternativ för att publicera lagringsplatsen till olika fjärranslutna lagringsplatser.

    Skärmbild av fönstret Team Explorer som visar tillgängliga Git-lagringsplatsalternativ för källkontroll.

    Du kan välja vilken tjänst du vill för dina egna projekt. Den här självstudien visar användningen av GitHub, där den färdiga exempelkoden för självstudien underhålls på lagringsplatsen Microsoft/python-sample-vs-learning-django.

  4. När du väljer någon av kontrollerna Publicera uppmanar Team Explorer dig att ange mer information. När du till exempel publicerar exemplet för den här självstudien skapas själva lagringsplatsen först, där alternativet Push to Remote Repository används med lagringsplatsens URL.

    Skärmbild som visar fönstret Team Explorer för push-överföring till en befintlig fjärrlagringsplats.

    Om du inte har någon befintlig lagringsplats kan du med alternativen Publicera till GitHub och Push-överföra till Azure DevOps skapa en direkt från Visual Studio.

Tips/Råd

Om du snabbt vill navigera i Team Explorer väljer du rubriken Ändringar eller Push för att se en popup-meny med tillgängliga sidor.

När du går igenom den här självstudieserien får du för vana att regelbundet använda Git-kontrollerna i Visual Studio för att checka in och skicka ändringar. Självstudiekursen Steg påminner dig om lämpliga punkter.

Använda källkontroll från början

Det finns flera fördelar med att använda källkontroll från början av ett projekt. När du använder källkontroll från början av ett projekt, särskilt om du även använder en fjärrlagringsplats, får du regelbunden säkerhetskopiering på annan plats av projektet. Till skillnad från att underhålla ett projekt bara i ett lokalt filsystem ger källkontrollen också en fullständig ändringshistorik och enkel möjlighet att återställa en enskild fil eller hela projektet till ett tidigare tillstånd. Ändringshistoriken hjälper till att fastställa orsaken till regressioner (testfel).

Källkontroll är viktigt om flera personer arbetar med ett projekt, eftersom det hanterar överskrivningar och ger konfliktlösning. Källkontroll är i grunden en form av automatisering, som gör att du kan automatisera byggen, testning och versionshantering. Det är det första steget i att använda Azure DevOps för ett projekt, och eftersom inträdeshindren är så låga finns det egentligen ingen anledning att inte använda källkontroll från början.

Mer information om källkontroll som automatisering finns i Sanningens källa: Lagringsplatsernas roll i DevOps, en artikel i MSDN Magazine som skrivits för mobilappar som även gäller för webbappar.

Förhindra att Visual Studio genomför projekt automatiskt

Följ de här stegen för att förhindra att Visual Studio automatiskt genomför ett nytt projekt:

  1. Välj Verktyg>Alternativ>Källkontroll>Globala inställningar för Git.

  2. Avmarkera alternativet Genomför ändringar efter sammanslagning som standard och välj OK.

  1. Öppna sidan Inställningar i Team Explorer och välj Globala Git-inställningar>.

  2. Avmarkera alternativet Checka in ändringar efter sammanfogning som standard och välj Uppdatera.

Skapa en virtuell miljö och exkludera källkontroll

När du har konfigurerat källkontroll för projektet kan du skapa den virtuella miljön med nödvändiga Django-paket som projektet kräver. Du kan sedan använda fönstret Git-ändringar för att undanta miljöns mapp från källkontrollen.

  1. Högerklicka på noden Python-miljöer i Solution Explorer och välj Lägg till miljö.

    Skärmbild som visar hur du väljer kommandot Lägg till miljö i Solution Explorer.

  2. I dialogrutan Lägg till miljö väljer du Skapa för att acceptera standardvärdena. (Du kan ändra namnet på den virtuella miljön om du vill, vilket ändrar namnet på dess undermapp, men env är en standardkonvention.)

    Skärmbild som visar dialogrutan Lägg till miljö med standardvärden för en ny miljö för Projektet Learning Django.

  3. Om Visual Studio uppmanar till administratörsbehörighet anger du ditt medgivande. Vänta några minuter medan Visual Studio laddar ned och installerar paket. För Django och dess beroenden kan processen kräva att nästan 1 000 filer utökas i över 100 undermappar. Du kan visa förloppet i Visual Studios utdatafönster Output.

  4. I git-kontrollfältet väljer du de icke-bakåtkompatibla ändringarna (som nu visar 99+) för att öppna fönstret Git-ändringar :

    Skärmbild som visar hur du kan se de ej sparade ändringarna för skapandet av den virtuella miljön i fönstret Git-ändringar.

    Skapandet av den virtuella miljön medför tusentals ändringar, men du behöver inte inkludera dem i källkontrollen. Du eller någon annan som klonar projektet kan alltid återskapa miljön med hjälp av filenrequirements.txt .

  5. Om du vill undanta den virtuella miljön från källkontrollen högerklickar du på mappen env i fönstret Git-ändringar och väljer Ignorera dessa lokala objekt:

    Skärmbild som visar hur du ignorerar en virtuell miljö i källkontrolländringar.

    När du har exkluderat den virtuella miljön är de enda återstående ändringarna i projektfilen (.py) och .gitignore-filen, som innehåller en ny post för mappen för den virtuella miljön.

    Om du vill se skillnader för .gitignore-filen dubbelklickar du på filen i fönstret Git-ändringar .

  6. I fönstret Git-ändringar anger du ett incheckningsmeddelande, till exempel "Inledande projektändringar":

    Skärmbild som visar hur du redigerar incheckningsmeddelandet och genomför och push-överför de mellanlagrade incheckningarna i fönstret Git-ändringar.

  7. I listrutan Kommittera väljer du Kommittera mellanlagrad och Push.

Du kan öppna Git-förvarsfönstret och bekräfta att de mellanlagrade incheckningarna visas i den lokala historiken för den aktuella grenen.

När du har konfigurerat källkontroll för projektet kan du skapa den virtuella miljön med nödvändiga Django-paket som projektet kräver. Du kan sedan använda Team Explorer för att undanta miljöns mapp från källkontrollen.

  1. Högerklicka på noden Python-miljöer i Solution Explorer och välj Lägg till virtuell miljö:

    Skärmbild som visar hur du använder kommandot Lägg till virtuell miljö i Solution Explorer.

  2. Dialogrutan Lägg till virtuell miljö öppnas och visar meddelandet Vi hittade en requirements.txt fil. Meddelandet anger att Visual Studio använder filen för att konfigurera den virtuella miljön:

    Skärmbild av dialogrutan Lägg till virtuell miljö med textfilmeddelandet för identifierade krav i Visual Studio.

  3. Välj Skapa för att acceptera standardinställningarna. (Du kan ändra namnet på den virtuella miljön om du vill, vilket ändrar namnet på dess undermapp, men env är en standardkonvention.)

  4. Om Visual Studio uppmanar till administratörsbehörighet anger du ditt medgivande. Vänta några minuter medan Visual Studio laddar ned och installerar paket. För Django och dess beroenden kan processen kräva att nästan 1 000 filer utökas i över 100 undermappar. Du kan visa förloppet i Visual Studios utdatafönster Output.

  5. I git-kontrollfältet väljer du de ogenomförda ändringarna (som nu visar 99+) för att öppna sidan Git-ändringar i Team Explorer:

    Skapandet av den virtuella miljön medför tusentals ändringar, men du behöver inte inkludera dem i källkontrollen. Du eller någon annan som klonar projektet kan alltid återskapa miljön med hjälp av filenrequirements.txt .

  6. Om du vill undanta den virtuella miljön från källkontrollen högerklickar du på mappen env på sidan Ändringar och väljer Ignorera dessa lokala objekt:

    Skärmbild som visar hur du ignorerar en virtuell miljö i källkontrolländringar i Visual Studio.

    När du har exkluderat den virtuella miljön, är de enda återstående ändringarna i projektfilen (.py) och .gitignore-filen som innehåller en tillagd post för mappen för den virtuella miljön.

    Om du vill se skillnader för .gitignore-filen dubbelklickar du på filen.

  7. Ange ett incheckningsmeddelande, välj Checka in alla och skicka sedan incheckningarna till fjärrlagringsplatsen om du vill.

Förstå syftet med virtuella miljöer

En virtuell miljö är ett bra sätt att isolera programmets exakta beroenden. Den här isoleringsmetoden undviker konflikter i en global Python-miljö och underlättar både testning och samarbete. Med tiden, när du utvecklar en app, tar du alltid in många användbara Python-paket. Genom att behålla paket i en projektspecifik virtuell miljö kan du enkelt uppdatera projektets requirements.txt fil som beskriver den miljön, som ingår i källkontrollen. När du kopierar projektet till andra datorer, inklusive byggservrar, distributionsservrar och andra utvecklingsdatorer, är det enkelt att återskapa miljön. Du kan återskapa miljön genom att bara använda requirements.txt fil, vilket är anledningen till att miljön inte behöver finnas i källkontrollen. Mer information finns i Använda virtuella miljöer.

Ta bort virtuell miljö under källkontroll

Du kan ta bort en virtuell miljö när den är under källkontroll. Följ dessa steg:

  1. Redigera .gitignore-filen för att exkludera mappen:

    1. Öppna filen genom att välja Fil>Öppna>Fil.

      Du kan också öppna filen från Team Explorer. På sidan Inställningar väljer du Lagringsplatsinställningar. Gå till avsnittet Ignorera och attributfiler och välj länken Redigera bredvid .gitignore.

    2. Leta upp avsnittet i slutet som har kommentaren # Python Tools for Visual Studio (PTVS).

    3. Efter det avsnittet lägger du till en ny rad för mappen för den virtuella miljön, till exempel /BasicProject/env.

  2. Öppna ett kommandofönster och gå till mappen (till exempel BasicProject) som har mappen för den virtuella miljön, till exempel env.

  3. git rm -r env Kör kommandot för att ta bort den virtuella miljön som för närvarande är under källkontroll.

  4. Kommittéra dina ändringar med git commit -m 'Remove venv' kommandot eller kommittéra dem från sidan Ändringar i Team Explorer.

Granska standardkod

I det här avsnittet undersöker du exempelkoden i projektfilen (.py) som Visual Studio skapar baserat på ditt mallval.

Anmärkning

Exempelkoden är densamma oavsett om du skapar projektet i Visual Studio från Django-mallen eller genererar projektet med hjälp av CLI-kommandot django-admin startproject <project_name>.

  1. Öppna Solution Explorer för att visa din lösning och dina projektfiler. Det första projektet innehåller bara två filer, manage.py och requirements.txt:

    Filen requirements.txt anger Beroenden för Django-paket. Förekomsten av den här filen är det som inbjuder dig att skapa en virtuell miljö när du först skapar projektet.

    Den manage.py filen är kommandoradsverktyget Django som Visual Studio automatiskt anger som startfil för projektet. Du kör verktyget på kommandoraden med hjälp python manage.py <command> [options] av kommandot .

    För vanliga Django-uppgifter tillhandahåller Visual Studio praktiska menykommandon. Högerklicka på projektet i Solution Explorer och välj Python för att se listan med kommandon. Du använder flera av dessa kommandon i den här självstudieserien.

  2. Förutom de två filerna har projektet även en undermapp med samma namn som projektet. Den här mappen innehåller de grundläggande Django-projektfilerna:

    • __init__.py: En tom fil som talar om för Python att den här mappen är ett Python-paket.
    • settings.py: Inställningarna för Django-projektet som du ändrar när du utvecklar en webbapp.
    • urls.py: En innehållsförteckning för Django-projektet som du ändrar när du utvecklar din webbapp.
    • wsgi.py: En startpunkt för WSGI-kompatibla webbservrar för ditt projekt. Du brukar lämna den här filen as-is eftersom den erbjuder gränssnitt för produktionswebbservrar.

Generera krav efter paketinstallation

Visual Studio kan generera en requirements.txt fil från en virtuell miljö när du har installerat andra paket.

  • I Solution Explorer expanderar du noden Python-miljöer, högerklickar på den virtuella miljön och väljer Generera requirements.txt.

Det är en bra idé att använda det här kommandot regelbundet när du ändrar miljön. Kommittera ändringar i requirements.txt-filen till källkontrollen tillsammans med alla andra kodändringar som är beroende av den specifika miljön. Om du konfigurerar kontinuerlig integrering på en byggserver bör du generera filen och genomföra ändringar när du ändrar miljön.

Kör projektet

Nu är du redo att köra projektet i Visual Studio genom att följa den här proceduren:

  1. I Visual Studio väljer du Felsöka>Starta felsökning (F5) eller välj Webbserver i huvudverktygsfältet (webbläsaren kan variera):

    Skärmbild som visar webbserverkommandot i huvudverktygsfältet i Visual Studio.

  2. Båda kommandona kör servern med hjälp av kommandot manage.py runserver <port>, som startar den inbyggda webbservern i Django.

    Koden startar programmet med den angivna porten på Django-utvecklingsservern.

    Om Visual Studio publicerar meddelandet Det gick inte att starta felsökningsprogrammet och anger att ingen startfil hittas högerklickar du på filen manage.py i Solution Explorer och väljer Ange som startfil.

  3. När servern startar öppnas ett konsolfönster för att visa serverloggen. Visual Studio öppnar automatiskt en webbläsare till http://localhost:<port>. Eftersom Django-projektet inte har några appar visar Django bara en standardsida för att bekräfta att den aktuella koden fungerar som förväntat.

    Skärmbild som visar standardvyn för Django-projektet i webbläsarfönstret.

  4. När du är klar stänger du konsolfönstret, vilket stoppar Django-utvecklingsservern. Du kan också välja Felsökning>Sluta felsöka.

Använda Django-webbserver och ramverk

Django har en inbyggd webbserver som du kan använda i utvecklingssyfte. När du kör django-webbappen lokalt använder du den inbyggda Webbutvecklingsservern för Django. Ett exempel på det här scenariot är när du felsöker din Django-webbapp i Visual Studio.

När du distribuerar din Django-webbapp till en webbvärd använder du webbservern på värden i stället för den inbyggda Django-webbservern. Modulen wsgi.py i Django-projektet tar hand om anslutning till produktionsservrarna.

Jämför felsökningskommandon med Project Python-kommandon,

Det finns en skillnad mellan att använda kommandona för felsökningsmenyn och de serverkommandon som anges i projektets Python-undermeny .

Förutom kommandona för felsökningsmenyn och verktygsfältsknapparna kan du även starta servern med hjälp av Python>Start-servern eller Python>Start-felsökningsserverkommandona på projektets snabbmeny.

Skärmbild som visar Python-kommandona för det valda projektet i Solution Explorer i Visual Studio.

Förutom kommandona för felsökningsmenyn och verktygsfältsknapparna kan du även starta servern med hjälp av Python>Run-servern eller Python>Run-felsökningsserverkommandona på projektets snabbmeny.

Båda kommandona öppnar ett konsolfönster där du ser den lokala URL:en (localhost:port) för den server som körs. Du måste dock öppna en webbläsare manuellt med den URL:en, och om du kör felsökningsservern startas inte Visual Studio-felsökningsprogrammet automatiskt. Du kan koppla ett felsökningsprogram till körningsprocessen senare, om du vill med hjälp av kommandot Debug>Attach to Process (Koppla till process ).

Nästa steg

Steg 2: Skapa en Django-app med vyer och sidmallar