SharePointCommunity
Die deutschsprachige Community für SharePoint, Office 365 und mit Azure

Development Debugging SharePoint 2013 Farm (Visual Studio 2015)

bewertet von 0 Usern
Nicht beantwortet Dieser Beitrag hat 0 Geprüfte Antworten | 2 Antworten | 1 Follower

Ohne Rang
2 Beiträge
SPDeveloperRunner erstellt in 3 Jul 2017 8:37

Hallo Leute,

 

mich beschäftigt folgendes das ich von einem externen Partner erhalten habe:

 

Ich arbeite mittels Visual Studio 2015 mit einem DEV Server wo ich einige Event Receiver entwickelt habe. Dabei handelt es sich um einen virtuellen Server wo SP2013 komplett installiert ist. Nun gut. Hier habe ich debugged, deployed - ohne Probleme und alles funkt.

 

Unser produktiver SharePoint 2013 befindet sich auf einer Farm, mit 2 Applikation-Servern und 2 Frontend-Servern. SQL Datenbanken sind gespiegelt und laufen mit Load Balancern. Auch gut.

 

Nun versuche ich mittels debugging die EVR (Event Receivers) den (Custom)Lists anzuhängen - dies geschieht meinerseits wie vom DEV System gewohnt, mittels Breakpoint setzen, Debug starten, Item erstellen, speichern, Debug springt zurück in das VS Fenster, wird gelb und ich beende. Danach deployen und die EVR`s sollten dann an der Liste hängen, die Features sind erstellt (auch alle technischen Objekte im Hintergrund (lokal)) und aktiviert. So nur mal zur Info was hier passiert.

 

OK es gibt nun auf dem Farm deployment andere Unstimmigkeiten, aber um die geht es mir nicht.

 

SONDERN:  Ich bekomme nun die Aussage von dem externen SW Partner, daß DIESER Vorgang mittels debugging auf der Farm absoluter Unsinn ist, da der SharePoint massivst beinträchtigt, behindert wird.

 

So zur Umgebung:  Ich habe hier eigene Webapplikationen - sagen wir einmal:

 

Webapplikation_A

Webapplikation_B

Webapplikation_C  (und so weiter)

 

In (A) und (B) wird gearbeitet. In (C) debugge ich gerade und versuche einen neuen Event Receiver anzuhängen, daß Feature zu deployen. Die Frage und der Grund meines Postings hier:

 

Wie kann es sein, daß wenn ich in der Webapplikation_C ich arbeite (dort befindet sich noch kein User - ich richte einmal für das kommende GoLive die Umgebung ein) ich lt. Aussage unseres externen Partners, nun die Webapplikation_A und Webapplikation_B massivst stören, behindern o.ä. sollte ???

 

Das sind doch drei voneinander getrennte Seiten - Webapplikation - SQL Datenbanken usw.

 

Klar über die SP Ressource kann man diskutieren, aber grundsätzlich greife ich doch Datentechnisch (sind ja getrennte SQL DB`s & IIS) und auch Performance bezogen nicht in deren Arbeitsbereich - Grundsätzlich!

 

Ich kann es einfach nicht glauben, daß diese Vorgehensweise alle Webapplikationen betrifft, oder noch schlimmer, die komplette Farm beeinträchtigt.

 

So nebenbei:  Wenn meine Vorgehensweise jemandem nicht gefällt, ich bin für jeden bessere Vorgehensweise offen ;-)

 

Ich hoffe das einmal so gesamt richtig rüber gebracht zu haben und würde mich freuen, von euch eine technisch kompetente Antwort zu dieser Behauptung zu bekommen.

 

Vielen herzlichen Danke und nette Grüße,

DeveloperHasi

Alle Antworten

Top-10-Beitragsschreiber
Männlich
18.168 Beiträge

Euer externer Partner hat vollkommen Recht. Laß das sein. Man debugged nicht auf einem produktiv genutzten System. Mal abgesehen davon, daß Du nicht weißt, auf welchem Server Dein Request landet und Du den Debugger deshalb an alle Server hängen müßtest...

So ganz voneinander getrennt sind die Komponenten nicht. Es werden immer gemeinsame Dienste genutzt und die legst Du beim Debuggen lahm. Und natürlich beeinträchtigt man damit auch einfach die Gesamtperformance eines Server.

Genau deshalb hat man ein Entwicklungssystem. Auf dem kannst Du Dich austoben so viel Du willst, aber wenn Du fertig bist, geht nur die entstandene WSP-Datei ins Produktivsystem. Und die wird bitte als Release kompiliert - keine Debugversion!

Viele Grüße
Andi
af @ evocom de
Blog
Ohne Rang
2 Beiträge

Das alles ist mir so im großen und ganzen auch klar. Die Frage zielte einmal auf die Aussage hin. Danke für den Input und werde dies auch berücksichtigen.

 

;-)

 

LG

Seite 1 von 1 (3 Elemente) | RSS