Microsoft hat es zwar schon lang und breit angekündigt, aber man muss es doch gesehen haben, um es zu glauben: Der Internet Explorer 6 wird mit SharePoint 2010 nicht mehr unterstützt! HTML und JavaScript sind jetzt einfach nicht mehr kompatibel.
Das ist zwar sehr lobenswert, aber einige Firmen werden dennoch Schwierigkeiten mit dieser Tatsache haben. Insbesondere große Konzerne haben oft weltweit noch IE6 im Einsatz.
Unten sind zwei Screenshots einer Standard SharePoint Site zu sehen:

Site mit IE7 geöffnet:




Site mit IE6 geöffnet:





Wie man ganz gut sehen kann, gibt es offenbar keine Chance, dass die Seite doch noch irgendwie mit IE6 benutzbar ist.

Ok, das Thema ist zwar schon alt, aber im Zusammenhang mit dem neuen SharePoint Client OM wieder aktuell: Silverlight Cross Domain Calls.
Silverlight Applets, die auf dem SharePoint Server liegen und per Microsoft.SharePoint.Client auf z.B. Listen zugreifen, funktionieren eigentlich auf Anhieb. Man greift hier auf den aktuellen Kontext zu (sprich, die aktuelle URL):

context = SP.ClientContext.Current;

Wenn man aber eine Silverlight Anwendung nicht als Sandboxed Solution direkt in SharePoint lädt, wird man beim ersten Versuch zu debuggen einen "Security.Error" bekommen, denn man muss jetzt die URL zum Server explizit angeben:

context = new SP.ClientContext("http://devserver001/sites/Jonka/");

Exception {System.Security.SecurityException ... etc

Silverlight versucht hier wieder auf die Datei "clientaccesspolicy.xml" zuzugreifen, um die Berechtigungen zu prüfen - man befindet sich schließlich gerade auf der Domain "localhost".

Also wird clientaccesspolicy.xml mit folgendem Inhalt ganz einfach im root der entsprechenden SharePoint Application abgelegt (z.B. C:\inetpub\wwwroot\wss\VirtualDirectories\80)

<?xml version="1.0" encoding="utf-8" ?>
<access-policy>
<cross-domain-access>
<policy>
<allow-from http-request-headers="*">
<domain uri="http://localhost:53659"></domain>
</allow-from>
<grant-to>
<resource path="/" include-subpaths="true"></resource>
</grant-to>
</policy>
</cross-domain-access>
</access-policy>


Man kann auch <domain uri="*"> eintragen, dann gibt es keine Beschränkung der URL.

Die Datei ist natürlich nicht aufrufbar, da SharePoint das Dateisystem nicht nach außen öffnet. Zum Glück gibt es in SharePoint 2010 immer noch die beliebten "Managed Paths", um solche Inhalte zu veröffentlichen.

In der Central Administration unter "Application Management" - "Manage web applications" im Ribbon kann die Einstellung geöffnet werden:



Hier eine "Explicit inclusion" anlegen, und /clientaccesspolicy.xml als Pfad angeben:



Ein Klick auf "Add Path", und alles sollte funktionieren:



Dann kann auch von der Visual Studio Debug-Umgebung aus auf SharePoint 2010 Listen zugegriffen werden:




Quellen:
http://www.silverlighthack.com/post/200 ... -2%29.aspx
http://timheuer.com/blog/archive/2008/0 ... sense.aspx

Silverlight und SharePoint zu verbinden macht seit Version 2010 und dem Client Object Model (komisch, dass das nicht COM abgekürzt wird... *hust*) auf einmal richtig Sinn. Es gibt auch viele Arten, aus VisualStudio 2010 heraus eine Silverlight Applikation zu deployen. Ich hatte mich zunächst für ein PostBuild Deployment in das SharePoint ClientBin entschieden, mit dem Standard Silverlight-WebPart für die Anzeige.

Leider cached der Internet-Explorer das XAP-File immer, so dass Änderungen nicht Sichtbar werden, und manuell den Cache zu leeren, ist viel zu umständlich. Zum Glück kann man den Cache auch per Commando-Zeile löschen, auch wenn der Befehl sich einem nicht sofort erschließt: (Gilt natürlich nur für den Internet Explorer)

RunDll32.exe InetCpl.cpl,ClearMyTracksByProcess 8


Im Post-Build event steht also folgendes:



copy SilverlightSharePointDemo.* "C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\LAYOUTS\ClientBin"
RunDll32.exe InetCpl.cpl,ClearMyTracksByProcess 8


Danach kann man mit F6 das Projekt kompilieren und mit F5 im Browser neu laden. Alle Änderungen sollten dann sofort sichtbar sein.


Quelle:
http://blogs.techrepublic.com.com/windo ... ows/?p=574

So, endlich mein erster Blogeintrag zu SharePoint 2010:

Für den Anfang wollte ich mit Visual Studio 2010 RC auf SharePoint 2010 Beta2 ein Visual WebPart deployen. Also habe ich VS 2010 RC Premium auf dem bestehenden SharePoint Server installiert. Leider musste ich feststellen, dass die Premium Version von Visual Studio nicht die SharePoint Vorlagen enthielt, obwohl sie eigentlich enthalten sein müssten. Aber für den Release Candidate braucht man offenbar in jedem Falle die Ultimate Variante:

Ich empfehle dafür den Link auf das ISO File, der sich auf der Download-Seite ganz klein versteckt:

http://download.microsoft.com/download/ ... Ult_RC.iso

Nachdem das installiert ist, kann man auch die SharePoint Vorlagen auswählen und eine Site des lokalen SharePoint zum Deployen und Debuggen angeben:



Leider bekam ich immer sofort oder beim Starten mit F5 einen der folgenden Fehler angezeigt:



"Could not load the Web.config configuration file. Check the file for any malformed XML elements, and try again. The following error occurred: The local SharePoint server is not available. Check that the server is running and connected to the SharePoint farm."


oder:



"Cannot connect to the SharePoint site: ... Make sure that the site URL is valid, that the SharePoint site is running on the local computer, and that the current user has the necessary permissions to access the site. [...]"


Unten in der Error List gibt es auch noch eine Meldung:



"Error occurred in deployment step 'Recycle IIS Application Pool': The local SharePoint server is not available. Check that the server is running and connected to the SharePoint farm."

Das ist natürlich nicht sehr aussagekräftig, denn natürlich läuft der lokale SharePoint und lässt sich auch lokal aufrufen. Also habe ich in einer WinForms-Anwendung versucht über das normale Objektmodell (SPSite) auf den Server zuzugreifen und siehe da, der Benutzer hat keine Datenbank-Berechtigungen!

In der neuen Kombination von Windows Server 2008 R2 und SQL Server 2008 R2 hat eben nicht mehr jeder lokale Admin auch gleichzeitig volle Datenbank-Berechtigungen - auch dann nicht, wenn alles auf einem System installiert ist. Auch hilft es offenbar nicht, den Benutzer als SharePoint Farm-Administrator einzutragen.
Das ist insofern komisch, da man hingegen Zugriff auf die SharePoint-Admin und -Search Datenbanken erhält. (Bug oder Feature?)

Gibt man seinem Benutzer, mit dem man am System angemeldet ist, Zugriff auf die entsprechende Content-DB (z.B. SharePoint_Content_1234567890) und die Config-DB (z.B. SharePoint_Config_1234567890) kann man auch wieder auf das Objektmodell zugreifen und das Debugging klappt.

Heute hatte ich mal wieder das alte Problem, dass beim SQL Update eines gerade angelegten Datensatzes dieser nicht aktualisiert wurde, weil die automatisch vergebene ID der Auto-Increment Spalte sich nicht im bestehenden Objekt wiederfand.
Normalerweise muss ich mich ja damit nicht rumärgern, weil ich entweder einen OR-Maper verwende, der das alles regelt, oder GUIDS verwende, die ich ja schon vorher kenne. Aber hier war es mal simples ADO.NET und Auto-IDs. Also wieder recherchieren...
Und damit ich das nicht nochmal raussuchen muss - falls ich es vergessen sollte - hier das einfachste Vorgehen in C# für ein INSERT mit darauffolgendem UPDATE mit ADO.NET auf einem SQL Server:

Um die eben erzeugte ID beim INSERT zu erhalten genügt es, ein SELECT scope_identity() an das INSERT Statement zu hängen.
z.B.:

INSERT INTO Customer (Name, LastName)
VALUES ('Max', 'Mustermann')
SELECT scope_identity()



Dann natürlich nicht mehr ExecuteNonQuery() ausführen, sondern ExecuteScalar():


object ret = command.ExecuteScalar();
int id = Convert.ToInt32(ret);
customer.Id = id;



Dann bekommt man die eben erzeugte ID in einem Command wieder zurück, und dann klappts auch mit dem Update.