# Debugowanie Azure Functions lokalnie z IronPDF
## Problemy przy uruchamianiu Azure lokalnie
Typowym wyjątkiem, który można zobaczyć w przypadku napotkania tego problemu, jest "Błąd podczas lokalizowania pliku konfiguracyjnego wdrażania IronPdf.Native.Chrome.deployment.json."
**Zalecane:** Uruchom Aplikacje Funkcji Azure na Windows, które celują w .NET Core 3.1 `<TargetFramework>netcoreapp3.1</TargetFramework>`
**Wymagane:** Użyj domyślnej konfiguracji **"in-process"** podczas tworzenia funkcji Azure w Visual Studio. Najnowsza wersja IronPDF obsługuje Azure Functions uruchamiane 'out-of-process' lub w 'izolowanym procesie', jak opisano w "[Przewodnik po uruchamianiu Azure Functions w C# w modelu izolowanego pracownika](https://docs.microsoft.com/en-us/azure/azure-functions/dotnet-isolated-process-guide#differences-with-net-class-library-functions)." Jednak starsze wersje mogą nie obsługiwać tych typów Azure Functions.
## Problem z zależnościami przy uruchamianiu Azure Functions lokalnie
Podczas uruchamiania Azure lokalnie, używając Azurite (VS2022) lub Emulatora Azure Storage (VS2019), tworzony jest dodatkowy katalog bin, który Emulator Storage używa do wdrażania. Do tego katalogu kopiowane są tylko pliki DLL, więc oprogramowanie, które wymaga dodatkowych plików, nie będzie działać i może rzucać powyższym wyjątkiem.
Można rozwiązać ten problem, kopiując katalog runetimes do oddzielnego katalogu bin używanego przez Emulator Storage. Zalecamy wykonanie tego jako **zdarzenie post-build** (patrz poniżej instrukcje) podczas uruchamiania lokalnego (ponowne rekompilowanie/budowanie przywróci katalog bin do jego pierwotnego stanu). Nie napotkasz tego problemu podczas wdrażania do chmury.
- **Problem:** Podczas lokalnego uruchamiania projektu funkcji Azure, tworzy on dodatkowy folder _bin_, z którego uruchamia funkcję. Jednakże nie kopiuje do wspomnianego folderu _bin_ wszystkich niezbędnych plików.
- **Przykład:** Projekt w _C:\code\azure-functions-test_, który buduje do _C:\code\azure-functions-test\bin\Debug\netcoreapp3.1_
- **Rozwiązanie:** Sklonuj katalog _C:\code\azure-functions-test\bin\Debug\netcoreapp3.1\runtimes_ aby także istniał w _C:\code\azure-functions-test\bin\Debug\netcoreapp3.1\bin_
- Nadpisz wszystkie istniejące pliki, jeśli zostaniesz poproszony o potwierdzenie
## Zdarzenie Post-Build
Aby zautomatyzować proces kopiowania niezbędnych plików do lokalnego katalogu bin funkcji Azure, postępuj zgodnie z tymi instrukcjami, aby ustawić *zdarzenie post-build* w Visual Studio:
1. Kliknij prawym przyciskiem myszy na projekcie Azure Functions, wybierz **Właściwości**.
2. Przewiń do sekcji **Zdarzenia**.
3. Wprowadź **zdarzenie post-build** jak pokazano poniżej:
```shell
XCOPY "$(TargetDir)runtimes" "$(TargetDir)bin\runtimes" /S /E /Y /I /R /D
```
Ta komenda wykonuje:
- Kopiuje zawartość katalogu _runtimes_ do katalogu _bin/runtimes_.
- Przełączniki `/S` i `/E` zapewniają uwzględnienie wszystkich podkatalogów i pustych katalogów.
- Przełącznik `/Y` tłumi monitowanie o potwierdzenie, że chcesz nadpisać istniejący plik docelowy.
- Przełącznik `/I` zakłada, że cel to katalog, jeśli nie istnieje.
- Przełącznik `/R` nadpisuje pliki tylko do odczytu.
- Przełącznik `/D` kopiuje pliki zmienione w dniu lub po określonej dacie.
Typowym wyjątkiem, który można zobaczyć w przypadku napotkania tego problemu, jest "Błąd podczas lokalizowania pliku konfiguracyjnego wdrażania IronPdf.Native.Chrome.deployment.json."
Zalecane: Uruchom Aplikacje Funkcji Azure na Windows, które celują w .NET Core 3.1 <TargetFramework>netcoreapp3.1</TargetFramework>
Wymagane: Użyj domyślnej konfiguracji "in-process" podczas tworzenia funkcji Azure w Visual Studio. Najnowsza wersja IronPDF obsługuje Azure Functions uruchamiane 'out-of-process' lub w 'izolowanym procesie', jak opisano w "Przewodnik po uruchamianiu Azure Functions w C# w modelu izolowanego pracownika." Jednak starsze wersje mogą nie obsługiwać tych typów Azure Functions.
Problem z zależnościami przy uruchamianiu Azure Functions lokalnie
Podczas uruchamiania Azure lokalnie, używając Azurite (VS2022) lub Emulatora Azure Storage (VS2019), tworzony jest dodatkowy katalog bin, który Emulator Storage używa do wdrażania. Do tego katalogu kopiowane są tylko pliki DLL, więc oprogramowanie, które wymaga dodatkowych plików, nie będzie działać i może rzucać powyższym wyjątkiem.
Można rozwiązać ten problem, kopiując katalog runetimes do oddzielnego katalogu bin używanego przez Emulator Storage. Zalecamy wykonanie tego jako zdarzenie post-build (patrz poniżej instrukcje) podczas uruchamiania lokalnego (ponowne rekompilowanie/budowanie przywróci katalog bin do jego pierwotnego stanu). Nie napotkasz tego problemu podczas wdrażania do chmury.
Problem: Podczas lokalnego uruchamiania projektu funkcji Azure, tworzy on dodatkowy folder bin, z którego uruchamia funkcję. Jednakże nie kopiuje do wspomnianego folderu bin wszystkich niezbędnych plików.
Przykład: Projekt w C:\code\azure-functions-test, który buduje do C:\code\azure-functions-test\bin\Debug\netcoreapp3.1
Rozwiązanie: Sklonuj katalog C:\code\azure-functions-test\bin\Debug\netcoreapp3.1\runtimes aby także istniał w C:\code\azure-functions-test\bin\Debug\netcoreapp3.1\bin
Nadpisz wszystkie istniejące pliki, jeśli zostaniesz poproszony o potwierdzenie
Zdarzenie Post-Build
Aby zautomatyzować proces kopiowania niezbędnych plików do lokalnego katalogu bin funkcji Azure, postępuj zgodnie z tymi instrukcjami, aby ustawić zdarzenie post-build w Visual Studio:
Kliknij prawym przyciskiem myszy na projekcie Azure Functions, wybierz Właściwości.
Przewiń do sekcji Zdarzenia.
Wprowadź zdarzenie post-build jak pokazano poniżej:
Curtis Chau posiada tytuł licencjata z informatyki (Uniwersytet Carleton) i specjalizuje się w front-endowym rozwoju, z ekspertką w Node.js, TypeScript, JavaScript i React. Pasjonuje się tworzeniem intuicyjnych i estetycznie przyjemnych interfejsów użytkownika, Curtis cieszy się pracą z nowoczesnymi frameworkami i tworzeniem dobrze zorganizowanych, atrakcyjnych wizualnie podręczników.
