Ich habe drei Webanwendungsprojekte, die eine gemeinsame Bibliothek benutzerdefinierter Serversteuerelemente verwenden. Den Code hinter Dateien zu teilen ist einfach - sie werden in eine DLL kompiliert, die ich in den anderen Projekten unter Verwendung einer Projektreferenz referenziere. Aber wie gehe ich mit Dateien wie JavaScript, Stylesheets und Bildern um? Ich versuche das "Visual Studio" so zu machen, dass es so einfach wie möglich ist zu verstehen und zu debuggen.
Das aktuelle Setup sieht ungefähr so aus:
%Vor%*) Virtuelles Verzeichnis in IIS.
Das virtuelle Verzeichnis jeder Webanwendung verweist auf das Ressourcenverzeichnis in meiner CommonControlsWebApp. Dies ist in IIS konfiguriert. Visual Studio ist nicht in der Lage, diesen Link zu verstehen. Daher muss ich beim Debuggen manuell an den IIS-Prozess anhängen.
Eine andere Lösung könnte darin bestehen, jede Ressource mit WebResourceAttribute in die common dll aufzunehmen. Aber das würde src -Links in etwas wie WebResource.axd? D = GUID verwandeln, wenn ich die Quelle meiner Webseiten ansehe, und ich befürchte, dass dies das Debuggen ziemlich verwirrend macht.
Eine dritte Lösung wäre, Subversion zu verwenden, um die gleichen Dateien in alle drei Lösungen aufzunehmen. Niemand im Team hat das schon einmal versucht, also sind wir uns nicht sicher, wie gut das funktionieren würde.
Ich habe das Gefühl, dass mir eine großartige, offensichtliche Lösung für die Einrichtung der Projekte fehlt. Irgendwelche Vorschläge?
Viele Steuerungsentwickler bündeln ihre Webressourcen mit der zweiten Methode, die Sie beschreiben - indem Sie sie als eingebettete Ressourcen in die DLL einfügen. Auf diese Weise können Sie die Steuerelemente verteilen, ohne eine Reihe von Ordnern und Dateien in jede Website kopieren zu müssen, die sie verwenden möchten, und stellen Sie sicher, dass die Ordnerpfade alle übereinstimmen, etc. Sie profitieren auch von der viel einfacheren Lokalisierung / Internationalisierung von Ihre Ressourcen.
Allerdings ist die WebResource.axd-Sache ein Nachteil. Sie können die URLs normalerweise mit etwas wie Firebug "debuggen", um zu sehen, was tatsächlich von der Anfrage zurückgegeben wurde, aber ich stimme zu, es kann ein Schmerz sein, wenn etwas nicht richtig funktioniert. Ein weiterer Nachteil ist, wenn Sie Dutzende von Ressourcen für ein Server-Steuerelement haben, insbesondere wenn sie jeweils mehrfach referenziert werden (denken Sie an eine Baumansicht mit Hunderten von kleinen Bildern auf den Knoten) - dann können die URLs dem Finale eine Tonne tatsächlicher Bytes hinzufügen HTML-Ausgabe.
Wenn Ihre Verteilung / Lokalisierung Ihre Optimierungs- / Debugging-Anforderungen überwiegt, würde ich die Ressourcen einbetten.
Wenn nicht, dann könntest du definitiv # 3 machen - alles mit Subversion in deine Website kopieren. Sehen Sie sich SVN Externals an, um es einzurichten. Ein bisschen Zeit, um in das Lernen zu investieren, könnte dir jetzt die Nerven sparen!
Ich habe den einfachen Ausweg genommen und alle meine Projekte in einer einzigen Lösung zusammengefasst. Dann habe ich ein WebUserControlLibrary-Projekt erstellt, in das ich alle freigegebenen Steuerelemente einfüge.
Um sie in das andere Projekt zu bekommen, habe ich dann das Build-Ereignis für jedes Projekt konfiguriert, um die UC in einen speziellen Ordner zu kopieren:
%Vor%Und natürlich verweisen Sie die WebUserControlLibrary von den Projekten, die es brauchen.
Vorteile dieses Ansatzes:
Nachteile:
Ich habe ein paar Optionen in den Eimer zu werfen:
Option 1: Verwenden Sie ein freigegebenes Projekt für Ihre Ressourcen: Ссылка
Optionen 2 Konvertieren Sie Ihre Klassenbibliothek in ein NuGet-Paket. Ich glaube nicht, dass Sie beim Verpacken viel anderes tun müssen als das Folgende, um alle Ordner und Dateien mit dem NuGet-Projektordner einzubeziehen:
c: \ nuget.exe pack DEINPROJ.csproj -IncludeReferencedProjects -Prop Platform = AnyCPU -Exclude **. Tt -Exclude **. Txt
Tags und Links asp.net resources visual-studio-2008 web-applications