Sorry, we found 0 results. Please try another query.
Showing max 10 of results

Deploy global resources in a SharePoint Farm

Mikhail Dikov has written a very good article about how to use and deploy global resources within SharePoint.
He uses a Feature Receiver and creates a one-time scheduled job which copies the resource files from the feature folder to the App_GlobalResources folder under Inetpub\wwwroot\wss\VirtualDirectories[port].

Now, why I’m writing about this?

Because there is one little thing within his code, that makes this solution unusable for a farm with more than one WFE (Web front-end server).
The resource files were copied only on one WFE each time I activated the feature. After searching the web a while, I found that the parameter SPJobLockType is the problem.

In Mikhails solution this parameter is set to “Job”, which defines that this job executes only on one machine at a time. In a farm, I want to execute this job on each WFE. So set this parameter to “None” and it works!

Another solution is the article from Maxime Bombardier “Deploying resource files across a farm“. For me it seems to be a little bit difficult and more complex than the solution from Mikhail.

CMS mit SharePoint 2007 - Teil 1: Das SharePoint Variation System

Ich weiß, dass es einige Webseiten gibt, die insgesamt wahrscheinlich eine Menge Gründe nennen können, warum man Variations mit SharePoint 2007 nicht einsetzen sollte.

Im aktuellen Projekt war die Entscheidung für Variations bereits lange vor Beginn gefallen…

Daher ein paar nützliche Hinweise die man evtl. vorher beachten sollte oder die im Nachhinein vielleicht noch was retten können. ;-)

  1. Insgesamt ist das Variationsystem leider sehr instabil, auch mit installiertem SP1.
    Beispiel: Für die Migration von einem vorhandenen alten System haben wir u.a. ein Tool geschrieben, um aus Einträgen einer SharePoint Liste Sites und Pages auf einem Zielsystem zu erstellen. Sei es über as SP Objektmodell oder über stsadm, stellenweise und aus unerfindlichen Gründen knallt es beim Anlegen der Variations. Da die Sourcesprache aber (durch unseren code) (meistens) korrekt angelegt wird, ist der dahinterliegende Timerjob des Variationsystems das Problem.
    Eine wirkliche Lösung gibt es offensichtlich bisher nicht, daher führen wir das Erstellen der Sites und Pages nun verzögert aus, um jeweils nach ein paar Sites erstmal auf den SharePoint Timerjob zu warten…
  2. Variations per SharePoint Solution/Feature deployen bereitete uns ebenfalls einige Kopfschmerzen.
    Die Labels der Variationen die man anlegen möchte, lassen sich noch relativ leicht über ein paar Zeilen code in einem Feature Receiver anlegen. Um nun die Hierarchien zu erstellen, kann man entweder über die GUI gehen und auf den Button “Create Hierarchies” klicken oder man macht auch das per Code. Sinnvoll ist es, damit man später das ganze wirklich ohne manuelle Eingriffe von einem Administrator installieren lassen kann. Leider will Microsoft das wohl nicht, denn die zugehörige Klasse, bzw. Methode ist als internal deklariert und somit nicht verfügbar. Da das inakzeptabel ist, half nur ein Artikel von Codeplex, in dem beschrieben wird, wie man mittels Reflection doch noch zum gewünschten Ergebnis kommt. Und ja, die Alternative die Seite per WebRequest aus dem Code raus anzustoßen und vorher entsprechend zu manipulieren funktioniert nur bedingt und natürlich schon gar nicht zusammen mit Mehrsprachigkeit ;-)
  3. Custom ASP.NET 2.0 WebParts und Variations vertragen sich leider gar nicht! Beispiel: Eine Page erstellen, ein (selbst geschriebenes) WebPart hinzufügen und Publish klicken. Das Ergebnis ist ein leerer Eintrag im Variation Log, wo dann zwar Datum und Uhrzeit, aber weder Success, noch Failure Meldungen stehen. Weiterhin passiert dann einfach nichts mehr. Entfernt man das WebPart und klickt erneut auf Publish, funktioniert alles wieder wie es sollte. Nach einiger Recherche gibt es dazu offensichtlich 2 Lösungen: 1\. Man erbt von Microsoft.SharePoint.WebPartPages.WebPart anstatt von System.Web.UI.WebControls.WebParts.WebPart, was jedoch laut Microsoft nicht empfohlen ist, oder 2\. Installiert neben den [Post-SP1 Hotfixes vom 31\. Januar 2008](http://support.microsoft.com/kb/941274/en-us) auch noch das [21\. Februar 2008 Hotfix Package](http://support.microsoft.com/kb/948947/en-us), was genau dieses Problem behebt. Somit können dann auch bereits vorhandene ASP.NET WebParts verwendet werden.

Weitere Teile folgen, denn noch ist das Projekt nicht zu Ende… Im nächsten Beitrag geht es dann um das ebenfalls allseits beliebte Content Deployment und warum  ich das ganze nahezu komplett neu Entwickelt habe…

Proxy Switcher v1.2.0

Der Proxy Switcher ist nun in einer neuen Version verfügbar.
Neben einer grundlegenden Änderung am Switcher PlugIn Interface, gab es noch ein paar weitere Änderungen und Neuerungen.

Das wichtigste dürfte für die meisten jedoch sein: Der Proxy Switcher bringt nun ein *Firefox Switcher PlugIn *mit. Leider muss Firefox geschlossen sein, da Firefox keine API mitbringt um eine laufende Instanz zu benachrichtigen, dass sich die Proxy Einstellungen geändert haben. Sollte jemand dazu Informationen haben, bitte melden.

DOWNLOAD HIER

Changelog:

  • Automatische Prüfung auf neue Versionen
  • Verbessertes PlugIn Interface (Bietet nun laden/speichern von Konfigurationen)
  • Minimiert starten funktioniert nun auch zuverlässig auf Windows XP und ist explizit konfigurierbar
  • Neues PlugIn für Firefox 2 und 3 (außerdem kann bei mehreren Profilen gewählt werden, für welches Profil die Einstellungen gelten sollen)

English:

DOWNLOAD HERE

Changelog:

  • Auto check for updates
  • Enhanced PlugIn interface (now an abstract base class with load/save configuration functions)
  • Start minimized now configurable and working on Windows XP
  • New PlugIn for Firefox 2 and 3; works also with different Firefox profiles