2017-01-07 3 views
0

Wir implementieren die Bereitstellung von azure automatisch von Github über ein Kudu-Skript. Es funktionierte in Ordnung, bis ich DevExpress XtraReports zu einem Projekt hinzufügen wollte.Bereitstellen einer externen Assembly (DevExpress) für einen azure App-Dienst

Ich habe einige DevExpress Referenzen in meiner csproj Datei wie folgt:

<Reference Include="DevExpress.XtraReports.v16.2, Version=16.2.3.0, Culture=neutral, PublicKeyToken=b88d1754d700e49a, processorArchitecture=MSIL"> 
     <SpecificVersion>False</SpecificVersion> 
     <HintPath>..\Resources\DevExpress.XtraReports.v16.2.dll</HintPath> 
    </Reference> 

Alles toll laufen und arbeitet auf meinem lokalen Rechner in Ordnung, aber wenn es baut auf azur ich die folgende Fehlermeldung erhalten: „Der Typ oder Namespace name 'DevExpress' konnte nicht gefunden werden (fehlt eine using-Direktive oder eine Assembly-Referenz?) ". Die DevExpress-DLLs werden in die Quellcodeverwaltung eingecheckt und so eingestellt, dass sie den lokalen Wert true kopieren.

Alle Pakete, die Nuget-Pakete sind gut funktionieren. DevExpress muss jedoch eine binäre Referenz sein, und ich bin mir nicht sicher, wie man sie in das richtige Verzeichnis kopieren kann, um aufgenommen zu werden, wenn alles in azurblau ist.

Gedanken? Ich habe das Gefühl, dass mir etwas offensichtlich fehlt, aber ich kann nicht herausfinden, was es ist.

+0

Fwiw, das sollte "einfach funktionieren", das habe ich bei einigen Projekten gemacht. Ich würde damit beginnen, alle deine Annahmen zu überprüfen; Verwenden Sie SCM, um zu überprüfen, dass die Datei in der Repo auf Azure ist, versuchen Sie eine saubere Kasse auf Ihrem eigenen Computer zu versuchen, etc. – Frans

+0

@Frans Siehe meine Antwort. Es ist mir peinlich, es zu sagen, aber es war die typischen Dateien sind nicht in der Quellcodeverwaltung Fehler. (seufz.) – zgirod

+0

Wir waren alle dort;) – Frans

Antwort

1

Dies war Ei auf meinem Gesicht, ID10T Fehler, was auch immer Sie es nennen wollen. Es war typisch, dass die Dateien nicht im Fehler der Quellcodeverwaltung waren. Während der späten Nachtarbeit sah ich die * .xml-Dateien in der Quellcodeverwaltung und angenommen es waren die DLL-Dateien. Mit frischen Augen habe ich es gefangen. Es hat mich verrückt gemacht.

+0

Das würde es tun. :) In https://github.com/projectkudu/kudu/wiki/Make-sure-site-correctly-deploys-locally empfehle ich immer lokal von einem sauberen Klon des Repos zu testen, um diese Möglichkeiten zu eliminieren. –

+0

@DavidEbbo das ist ein guter Vorschlag, und ich werde jetzt lokal testen beginnen. – zgirod

Verwandte Themen