Exportieren (0) Drucken
Alle erweitern

Bewährte Vorgehensweisen zum Ausführen von nicht verwaltetem Code in Azure-Anwendungen

Letzte Aktualisierung: Juni 2014

Das Schreiben von .NET-Code für Azure-Anwendungen entspricht größtenteils dem Schreiben von .NET-Code für Windows-Anwendungen. Beim Schreiben von .NET-Code für die einzelnen Plattformen sind feine Unterschiede zu beachten. In diesem Dokument finden Sie Empfehlungen zum Ausführen von nicht verwaltetem/systemeigenem Code in Azure-Anwendungen.

Autoren Christian Martinez, Trace Young und Mark Simms

In den folgenden Abschnitten finden Sie Empfehlungen zum Sicherstellen, dass systemeigener Code beim Entwickeln von Azure-Anwendungen, die systemeigenen Code aufrufen, ordnungsgemäß ausgeführt wird.

Um systemeigenen Code so zu konfigurieren, dass er im Versionsmodus kompiliert wird, klicken Sie mit der rechten Maustaste auf das Projekt mit dem systemeigenen Code, wählen Sie Eigenschaften aus, um die Seite Eigenschaften anzuzeigen, und wählen Sie auf der Registerkarte Erstellen auf der Eigenschaftenseite die Konfigurationsoption Version:

Projekteigenschaften, Buildoption Releasemodus

noteHinweis
An Laufzeitfehlern, die auf das Fehlen von DLLs, z. B. msvcr100d.dll oder msvcp100d.dll, hinweisen, lässt sich erkennen, dass der bereitgestellte systemeigene Code im Debugmodus kompiliert wurde. Die Dateien msvcr100d.dll und msvcp100d.dll sind DDLs, die nicht weitergegeben werden dürfen. Weitere Informationen zum Bestimmen, welche C++-DLL-Dateien weitergegeben werden dürfen, finden Sie unter Ermitteln der neu zu verteilenden DLLs (http://go.microsoft.com/fwlink/p/?LinkId=236016).

Führen Sie folgende Schritte aus, um sicherzustellen, dass die Azure-Anwendung beim Ausführen in Azure-Serveremulator jeden systemeigenen Code, auf den verwiesen wird, finden kann:

  1. Festlegen von geeigneten Eigenschaften für kompilierte systemeigene Codedateien in Visual Studio

    Schließen Sie die kompilierte systemeigene Codedatei als Projektelement ein, und setzen Sie im Dialogfeld Eigenschaften für die Datei die Option In Ausgabeverzeichnis kopieren auf Immer kopieren und die Option Buildvorgang auf Keiner.

    Dadurch wird die kompilierte systemeigene Codedatei in das BIN-Verzeichnis kopiert und sichergestellt, dass die Azure-Anwendung die kompilierte systemeigene Codedatei beim Ausführen in Azure-Serveremulator finden kann.



    Buildaktionen für nicht verwalteten Code (Dialogfeld)
  2. Bei der Fehlersuche im Rahmen der RoleEntry-Implementierung im Azure-Serveremulator können Sie das Debuggen von Problemen vereinfachen, indem Sie die kompilierte systemeigene Codedatei in das Laufzeitverzeichnis devfabric kopieren.

    • Wenn Sie beispielsweise Azure SDK, Version 1.5 oder früher, verwenden, kopieren Sie die kompilierte systemeigene Codedatei in das folgende Verzeichnis:


      C:\Program Files\Azure SDK\[SDK Version]\bin\devfabric\x64\


    • Verwenden Sie Azure SDK, Version 1.6 oder höher, kopieren Sie die kompilierte systemeigene Codedatei in das folgende Verzeichnis:


      C:\Program Files\Azure SDK\[SDK Version]\bin\runtimes\base\x64\

  3. Sicherstellen, dass Azure-Anwendungen, die in einer Webrolleninstanz ausgeführt werden, jeden systemeigenen Code, auf den verwiesen wird, finden können

    Wenn eine Azure-Anwendung auf systemeigenen Code verweist, der mit C++/CLI umschlossen wird, und die Azure-Anwendung in einer Webrolleninstanz ausgeführt wird, stellen Sie über eine der folgenden Methoden sicher, dass die Azure-Anwendung den systemeigenen Code, auf den verwiesen wird, finden kann:



    noteHinweis
    Die unten stehenden Schritte verweisen auf das Projekt CppCliWebRole, das mit dem Beispielcode in der Datei PinvokeCppCliInAzure.zip bereitgestellt wird. Diese Datei steht unter http://azureunmanagedcode.codeplex.com/ zum Download bereit. Weitere Informationen zu diesem Beispiel finden Sie unter Codebeispiel: Ausführen von systemeigenem Code in Azure-Anwendungen.

    Methode 1: Bearbeiten Sie die PATH-Umgebungsvariable, und starten Sie dann Azure-Serveremulator und IIS neu:

    1. Beenden Sie Azure-Serveremulator.

    2. Bearbeiten Sie die PATH-Umgebungsvariable so, dass sie auf ein Verzeichnis mit dem systemeigenen kompilierten Code zeigt.

    3. Geben Sie iisreset von einer Eingabeaufforderung mit erweiterten Berechtigungen aus ein.

    4. Drücken Sie F5, um den Beispielcode auszuführen.

    Methode 2: Verwenden Sie einen Startbefehl

    In den unten stehenden Schritten befindet sich der systemeigene Code in der Datei ExampleNativeCode.dll.

    1. Beenden Sie Azure-Serveremulator.

    2. Öffnen Sie die im CppCliWebRole-Projekt enthaltene indist.cmd-Datei.

    3. Ändern Sie die folgende Zeile:

      REM copy "%~dps0ExampleNativeCode.dll" "%windir%\system32\inetsrv"
      
      An:



      copy "%~dps0ExampleNativeCode.dll" "%windir%\system32\inetsrv"
      
    4. Speichern Sie das Projekt.

    5. Drücken Sie F5, um den Beispielcode auszuführen.

    noteHinweis
    Die Verwendung eines Startbefehls funktioniert auch bei tatsächlichen Bereitstellungen. Wenn Sie Verweise auf das IIS-Systemverzeichnis vermeiden möchten, könnten Sie alternativ ein Skript erstellen und ausführen, um folgende Aktionen zu bewirken:

    1. Ändern der PATH-Umgebungsvariable, sodass sie auf das Verzeichnis mit dem systemeigenen kompilierten Code zeigt

    2. Neustarten von IIS und allen davon abhängigen Prozessen

Azure ist – wie die Azure-Anwendungshosts (Worker- und Webrolle) – eine 64-Bit-Plattform. Wenn Sie keine reine 64-Bit-Entwicklungsumgebung verwenden und die Anwendung auf systemeigenen Code verweist, löst die Anwendung Fehler aus. Mit einem einfachen Test können Sie überprüfen, ob der gesamte systemeigene Code, auf den verwiesen wird, 64 Bit besitzt. Dafür testen Sie den systemeigenen Code über Konsolentestanwendungen, die für die Ausführung als 64 Bitanwendungen hartcodiert sind.

Standardmäßig sind nur die Visual C++-Laufzeitbibliotheken für Visual C++ 2008 auf Azure-Worker- und -Webrollen installiert. Daher wird systemeigener Code, der für die Visual C++-Laufzeitbibliothek für andere Versionen von Visual C++ kompiliert wurde, nicht in Worker- und Webrolleninstanzen geladen. Wenn sowohl Visual Studio 2008 als auch eine höhere Version von Visual Studio auf demselben Computer installiert sind, können Sie anhand der systemeigenen Funktion zur Festlegung von Zielversionen von Visual Studio systemeigene Bibliotheken für die Anwendung mit dem Visual Studio 2008-Plattformtoolset (Compiler, Linker, Header und Bibliotheken) erstellen. Weitere Informationen zum Verwenden von Visual Studio zum Erstellen einer Anwendung mit dem Plattformtoolset von Visual Studio 2008 finden Sie unter -Gewusst wie: Ändern des Zielframeworks und des Plattformtoolsets(http://go.microsoft.com/fwlink/?LinkId=324964).

Sie können dem Worker- oder Webrollenprojekt einen Starttask mit erweiterten Berechtigungen hinzufügen, um die erforderliche Version der Laufzeitbibliotheken zu kopieren und installieren. In den folgenden Schritten wird beschrieben, wie Sie einen Starttask mit erweiterten Berechtigungen erstellen, um die 64-Bit-Version des verteilbaren Microsoft Visual C++ 2010-Pakets in eine Worker-/Webrolle zu kopieren und das verteilbare Paket auszuführen, damit die Visual C++-Bibliotheken für Visual C++ 2010 auf den Worker-/Webrolleninstanzen installiert werden. Andere Versionen von Visual C++ erfordern ein spezielles verteilbares Paket für die jeweilige Version:

  1. Erstellen Sie einen Ordner Start für das Worker- oder Webrollenprojekt.

  2. Kopieren Sie vcredist_x64.exe (http://go.microsoft.com/fwlink/p/?LinkId=225987) in den Startordner.

  3. Erstellen Sie eine startup.cmd-Datei im Startordner.

  4. Bearbeiten Sie startup.cmd, und fügen Sie die folgende Zeile hinzu:


    "%~dps0vcredist_x64.exe" /q /norestart


  5. Ändern Sie die Eigenschaften von vcredit_x64.exe und startup.cmd im Visual Studio-Projektmappen-Explorer. Setzen Sie die Option Buildvorgang auf Inhalt und die Option In Ausgabeverzeichnis kopieren auf Kopieren, wenn neuer.

  6. Bearbeiten Sie die Datei ServiceDefinition.csdef für die Rolle, indem Sie die folgende erhöhte Startaufgabe für die Ausführung von startup.cmd hinzufügen:


    < Task commandLine ="Startup\Startup.cmd" executionContext ="elevated" taskType ="simple" />

Die Fehlermeldung, die generiert wird, wenn eine Assembly nicht von Azure-Computeremulator geladen werden kann, ist möglicherweise nicht intuitiv. Um Probleme beim Laden von Dateien in eine Worker- oder Webrollen-Hostinstanz zu beheben, verwenden Sie den Prozessmonitor folgendermaßen:

  1. Laden Sie den Prozessmonitor von Prozessmonitor v2.96 (http://go.microsoft.com/fwlink/p/?LinkID=137175) herunter.

  2. Starten Sie den Prozessmonitor, um Probleme mit Azure-Anwendungen beim Laden von Dateien während des Ausführens in Azure-Serveremulator zu beheben.

  3. Legen Sie wie unten dargestellt Filterparameter für den Azure-Serveremulator-Host fest. Wenn Sie Probleme mit Azure-Anwendungen beheben, die in einem Workerrollenprojekt ausgeführt werden, ändern Sie den Filter so, dass Einträge mit dem Prozessnamen WaWorkerHost.exe anstatt WaWebHost.exe angezeigt werden.



    Screenshot des Prozess-Explorers



  4. Suchen Sie nach Meldungen des Typs NAME_NICHT_GEFUNDEN. Dadurch können Sie die fehlenden Bibliotheksdateien isolieren. Sobald Sie die fehlende Datei bestimmt haben, können Sie den Bereich der Suche durch das Anwenden eines Filters eingrenzen, damit nur auf diese Datei bezogene Meldungen isoliert werden.

Damit Azure-Anwendungen einen systemeigenen 64-Bit-Code mit P/Invoke ausführen können, müssen Sie zunächst für die zugeordneten Worker- oder Webrollen die .NET-Vertrauensebene 'Full' konfigurieren. Weitere Informationen zum Aufrufen von systemeigenem Code in Anwendungen, die in Azure-Worker- oder -Webrollen ausgeführt werden, finden Sie unter den folgenden Ressourcen:

In diesem Abschnitt wird der Beispielcode in der Datei PinvokeCppCliInAzure.zip (http://go.microsoft.com/fwlink/p/?LinkId=236170) beschrieben, die unter http://azureunmanagedcode.codeplex.com/ zum Download bereitsteht.

noteHinweis
Wenn zum Durcharbeiten des Beispielcodes der Azure-Serveremulator von Visual Studio verwendet wird, muss der Teil des Startbefehls, mit dem die Visual C++-Laufzeitbibliotheken installiert werden, nicht ausgeführt werden. Daher sollten Sie in diesem Fall die folgende Zeile in der Datei startup.cmd auskommentieren:

REM "%~dps0vcredist_x64.exe" /q /norestart

Das Codebeispiel stellt ein Projekt dar, dass eine systemeigene DLL mit dem Namen "ExampleNativeCode.dll" erstellt. Es wurde der Empfehlung folgend als 64-Bit-Bibliothek im Freigabemodus compiliert.

noteHinweis
Beenden und starten Sie Azure-Serveremulator jedes Mal neu, wenn Sie irgendeinen Beispielcode ausführen und irgendwelche Änderungen am Code oder an Windows-Umgebungsvariablen vorgenommen werden. Dadurch wird sichergestellt, dass jeder systemeigene Code, auf den verwiesen wird, vom Arbeitsspeicher freigegeben wird, damit er neu kompiliert werden kann und sämtliche Änderungen an Umgebungsvariablen bei der nächsten Ausführung von Azure-Serveremulator abgerufen werden.

Der Beispielcode ExampleNativeCode.dll wird mit P/Invoke in einem Projekt mit dem Namen ManagedUsingPinvoke und mit C++/CLI in einem Projekt mit dem Namen ManagedUsingCppCLI umschlossen.

Der Code in der systemeigenen DLL ist eine geänderte Version der Standard-Projektvorlage Win32 mit Exporten und enthält eine einzige Funktion, die alle bekannten Fragen im Universum beantwortet, solange die Antwort auf die entsprechenden Fragen die Zahl 42 ist:

EXAMPLENATIVECODE_API int fnExampleNativeCode(void)
{
    return 42;
}

Der P/Invoke-Code und der C++-/CLI-Code, die diese Funktion verwenden, sind sehr ähnlich:

P/Invoke

public class Class1
{
    [DllImport("ExampleNativeCode.dll")]
    static extern int fnExampleNativeCode();

    public int GetTheAnswerToEverything()
    {
        return fnExampleNativeCode();
    }
}

C++/CLI

public ref class Class1
{
public:

    int GetTheAnswerToEverything()
    {
        return fnExampleNativeCode();
    }
};

Beide Workerrollenbeispiele (PInvokeWorkerRole und CppCliWorkerRole) in der Projektmappe rufen den Code in der gleichen Weise auf:

try
{
    Trace.WriteLine(new Class1().GetTheAnswerToEverything());
}
catch (Exception ex)
{
    Trace.WriteLine(ex);
}

Beide Workerrollenbeispiele schließen den systemeigenen kompilierten Code ein und werden so konfiguriert, dass der systemeigene kompilierte Code immer in das Ausgabeverzeichnis kopiert wird.

Wenn Sie F5 drücken, um den Code in Azure-Serveremulator auszuführen, sollten Sie die folgende Ausgabe sehen:

Konsolenausgabe für Beispielcode

Beim Aufrufen von systemeigenem Code in Azure-Anwendungen, die in einer Webrolleninstanz ausgeführt werden, gelten verglichen mit der Ausführung in einer Workerrolleninstanz bestimmte Überlegungen. Die Projekte PInvokeWebRole und CppCliWebRole enthalten den folgenden Code in einer leicht geänderten Version der standardmäßigen ASP.NET-Projektvorlage:

P/Invoke

<p>
    This is PInvoke <br />
        <%=Environment.GetEnvironmentVariable("PATH") %> <br />
        <%=new Class1().GetTheAnswerToEverything() %>
</p>

C++/CLI

<p>
    This is C++/CLI <br />
        <%=Environment.GetEnvironmentVariable("PATH") %> <br />
        <%=new Class1().GetTheAnswerToEverything() %>
</p>

Das Ausführen des PInvokeWebRole-Projekts führt zur erwarteten Ausgabe, die dem folgenden Beispiel ähnelt:

PInvoke-Konsolenausgabe von systemeigenem Code

Wird das CppCliWebRole-Projekt jedoch ohne Änderung ausgeführt, ergibt sich der folgende Fehler:

Von Webrolle zurückgegebene Fehlermeldung
noteHinweis
Dieser Fehler tritt selbst dann auf, wenn zum Kopieren des systemeigenen kompilierten Codes in das Ausgabeverzeichnis die richtigen Projekteinstellungen übernommen werden.

Verwenden Sie zum Beheben dieses Fehlers eine der unter Ensure that Azure Applications Running in a Web Role Instance can Locate any Referenced Native Code beschriebenen Methoden. Nach Anwendung einer dieser Methoden sollten Sie die erwartete Ausgabe für die Seite CppCliWebRole sehen, die dem folgenden Beispiel ähnelt:

C++/CLI-Konsolenausgabe von systemeigenem Code

Anzeigen:
© 2015 Microsoft