Ich hab mal ausnahmsweise ein bisschen Zeit gehabt um ein paar neue / nicht mehr ganz so neue Technologien anzusehen und auszuprobieren.

Da ich ja nun doch schon seit einiger Zeit meine halbwegs aktuelle Position per Virtual Earth auf woist.mwiedemeyer.de visualisiere und es seit kurzem ein Virtual Earth Silverlight Control gibt, ist es wie geschaffen, um endlich einen ernsthafteren Einstieg in Silverlight 2 zu starten.

Das interactive SDK ist wirklich genial und die Bedienung ist super einfach. Zumindest dann, wenn man bereits ein wenig WPF oder Silverlight Erfahrungen gesammelt hat.

Beispiel:

Man möchte in einer Silverlight Anwendung einfach nur die gesamte Karte darstellen. Dazu reicht es das Map Control zur Seite hinzuzufügen:

<UserControl x:Class="VirtualEarthSilverlightTest.Page"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" 
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" 
    xmlns:m="clr-namespace:Microsoft.VirtualEarth.MapControl;assembly=Microsoft.VirtualEarth.MapControl"
    Width="800" Height="600">
    <Canvas x:Name="LayoutRoot" Background="White">
        <m:Map Name="MyMap"></m:Map>
(...)

Um per code einen Pin (oder jedes andere UIElement, z.B. auch Bilder, Videos, etc.) auf der Karte an einer bestimmten Position anzuzeigen, reicht folgender code:

// Neuen MapLayer hinzufügen um Elemente an Locations anzuzeigen
MapLayer mapLayer = new MapLayer();
MyMap.Children.Add(mapLayer);
// Beliebiges UIElement (Canvas, Border, etc) an der Position latitude, longitude anzeigen
mapLayer.AddChild(anyUIElement, new Location(latitude, longitude));

Ich habe für einen ersten Versuch mal den letzten Urlaub in die Silverlight Karte eingefügt. Hier gibts das ganze nun zu sehen:

http://woist.mwiedemeyer.de/silverlight

UPDATE:

Was ich an der Stelle noch vergessen habe zu erwähnen: Es funktioniert nicht nur im Internet Explorer, sondern auch in Opera (und natürlich auch Firefox…)!

If you ever got this message and don’t know where it came from, here is the solution.

I got it if I click on “Edit Page” on a publishing page. So after some investigation it seems to be a problem with the web parts on the page.

My page layout contains some EditModePanels, so the user have different views in display and edit mode of the page. Therefore we also have one web part in a web part zone which is in one of the EditModePanels for display only.

<PublishingWebControls:EditModePanel PageDisplayMode="Display"…>
  <WebPartZone ID="zone1" ...>
      the web part added through the onet.xml site definition

The same web part zone “zone1” does not exists for editing, because I do not want the user to edit the web part. There is another web part zone “zone2” which lives outside of any EditModePanel.

Now comes SharePoint.

If you check out the page and then click on “Edit Page”, everything is working. Except of, that the web part from zone 1 has moved to zone 2! Automatically! Thank you SharePoint…

It seems that SharePoint think it has to show the web part in edit mode. And because the original web part zone is not visible, SharePoint moves the web part to the next available zone which is visible also in edit mode.

So remember:

Never put a web part zone in an EditModePanel which is only visible in display mode.

Maybe the solution is to make the web part not editable, but I didn’t tested this. My fast workaround hack is to create a div instead of the EditModePanel and makes it “runat=server” and give it an ID. Then I wrote this code on top of the page:

<script runat="server">
protected override void OnLoad(EventArgs e)
{
    base.OnLoad(e);
    this.navleftdiv.Visible = (this.SPWebPartManager1.DisplayMode == WebPartManager.BrowseDisplayMode);
}
</script>

Now it works like a charm.

Seit heute habe ich das Service Pack 1 für das .NET Framework 3.5 und den SQL Server 2008 auf meinem Server installiert. Ein paar neue kleine private Projekte warten und können nun mit den neuen Features ausgerüstet werden (z.B. Entity Framework und auch ASP.NET MVC obwohl das nur eine CTP ist).

An der Stelle kann ich das .NET 3.5 Enhancements Training Kit empfehlen! Sehr guter Überblick über alle Neuheiten.

Außerdem werde ich vielleicht die Datenbank von WoIstMarco? auf die neuen SQL Server 2008 Geo Datentypen upgraden. Mal schauen, was das so für Vorteile bringt.

Jetzt brauche ich nur noch viiel Zeit...

So, das wäre geschafft.

Ab sofort bin ich nun Microsoft Certified Professional Developer: Enterprise Applications Developer.

Dementsprechend ein neues Logo rechts. Und weils so schön ist, hier alle Logos mit denen ich mich nun schmücken kann/darf:

Mein zugehöriges MCP Transcript gibt es unter folgender Adresse:

http://www.microsoft.com/learning/mcp/transcripts
Transcript ID: 761136
Passwort: marcowiedemeyer

Heute mussten wir eine sehr fragwürdige Entdeckung machen:
Bei SharePoint/MOSS ist die Reihenfolge der styles im .css file wichtig! Ok genauer gesagt liegt es wahrscheinlich am ASP.NET Menu Control.

Wie kommt man nun zu so einer Erkenntnis?

Dazu fügt man ein neues SharePoint Menu Control zu einer MasterPage hinzu, alternativ auch das Standard ASP.NET Menu Control.
Nun die CSS Klassen für die verschiedenen Level festlegen, und auch die Selected Eigenschaft.

Die Styles liegen dabei in einem extra .css file, was etwa so aussieht:

.NavBarSelected { (...) }

.NavBarLevel1, .NavBarLevel2 { (...) }

Nun werden die MenuItems zwar korrekt dargestellt, aber nur bis man eines selektiert. Das Problem ist hier, dass SharePoint, oder eben das ASP.NET Menu, den HTML code folgendermaßen rendert:

...menuitem class=“NavBarSelected, NavBarLevel1, NavBarLevel2“

Es werden einfach alle styles in die class Eigenschaft gerendert, nur leider in der Reihenfolge in der sie auch im .css file aufgeführt sind.

Vertauscht man im .css file nun einfach die Reihenfolge der class angaben so

.NavBarLevel1, .NavBarLevel2 {} 

.NavBarSelected {} 

...menuitem class=“NavBarLevel1, NavBarLevel2, NavBarSelected“

Dabei sollte man im Normalfall davon ausgehen können, dass wenn man schon das "selected" class property setzt, die style angabe automatisch ans Ende gesetzt wird und man nicht in einem mehrere 1000 Zeilen großen .css file auf die Reihenfolge achten muss...

In einer Document Library gibt es ja ein paar Menüs. Nun möchte man jedoch einige Funktionalitäten nicht jedem User zur Verfügung stellen. In diesem Beispiel möchte ich "Open in Explorer" nicht mehr im Action Menü haben.

Dafür gibt es zwei Vorgehensweisen:

1. Den Usern das UseRemoteAPIs Recht entziehen wenn möglich
2. Eine Anpassung des Action Menüs (nicht offiziell supported!) in dem man folgendes macht:

Die Datei "DefaultTemplates.ascx" im Ordner "C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\CONTROLTEMPLATES" öffnen, nach der Zeichenfolge ID="ToolbarActionsMenu" suchen. Dort finden sich die entsprechenden Einträge als SharePoint:MenuItemTemplate. Nun kann man z.B. das gesamte Item entfernen, aber auch neue hinzufügen.

Ich hatte ja bereits seit einiger Zeit eine Karte hier, wo ich eingetragen habe, wo ich mich so rumtreibe.

Jetzt hat das ganze eine neue Dimension. Ich habe nämlich ein neues Spielzeug, einen GPS Logger. Dies ist ein kleiner Kasten den ich jetzt mit mir rum trage und der in gewissen Zeitintervallen die aktuelle Position speichert. Das ganze wird in einer Microsoft Virtual Earth Karte dargestellt (funktioniert aber leider nicht mit Opera, hoffe Microsoft bessert da demnächst mal nach... mit v6 wird jetzt immerhin Safari unterstützt).

Damit es aber die Stasi 2.0 nicht so leicht hat, ist die Karte nicht öffentlich. Wer dabei sein will, schreibt mir einfach eine Mail oder hinterlässt einen Kommentar, dann lass ich euch gerne das Kennwort zukommen (oder ihr habt es bereits in eurem Postfach).

Abgeguckt hab ich mir die Kartenintegration bei Daniel, es dann aber noch um ein paar neue Features erweitert. Zum Beispiel kann man Kommentieren und auch seinen eigenen Standort hinterlassen. Daniel bietet seine Karte auch öffentlich an, dort kann man sehen wie es aussieht.

Der Link findet sich ab jetzt auch rechts in der Leiste oder direkt: http://woist.mwiedemeyer.de

Wer noch mehr ideen hat, meldet sich per Kommentar.

Setzt man das SharePoint GridView (Microsoft.SharePoint.WebControls.SPGridView) in eigenen Seiten ein, und benutzt man für die Datenquelle die DataSource Eigenschaft

spGridView.DataSource = dataView;

dann zeigt das GridView beim sortieren keine Pfeile neben der sortierten Spalte an.

Dank Reflector stellt man fest, dass das SPGridView leider die Spalten Sortierung nur anzeigt wenn man als Datenquelle "DataSourceID" verwendet... Warum? Ich sehe da keinen Grund. Deshalb hier in etwa die Implementierung wie es das SPGridView auch intern macht:

spGridView.DataBind();

Eigentlich wollte ich warten, bis dasBlog dann endlich in Version 2.0 verfügbar ist, aber heute hatte ich gerad mal ein wenig Zeit... Nun gibts auch ein neues, hübscheres Design.

Allerdings lässt sich die configuration page nicht mehr aufrufen... Hoffe mit Version 2 wird dann alles besser. Diese wird dann auch nur noch auf .NET 2.0 aufsetzen und Medium Trust unterstützen, womit das ganze auch in einer Hosting Environment einsetzbar ist.

Geschafft. Auf dem Web zum MCPD EA habe ich nun etwas Zeit gehabt um schon mal die ersten beiden Prüfungen zu machen. Zum einen die 70-536 (Microsoft .NET Framework 2.0 - Application Development Foundation) und direkt hinterher die 70-528 (Microsoft .NET Framework 2.0 - Web-Based Client Development).

Damit bin ich jetzt also MCTS Web. Beide Prüfungen waren ganz ok, wobei ich bei der Web Prüfung die Möglichkeit der Kommentierung genutzt habe und bei 3-4 unklaren/falschen Fragen meinen Kommentar hinterlassen habe. Ob das jemand liest ist eine andere Frage...

So, es ist geschafft. Der Server Umzug ist weitesgehend ohne Problem abgelaufen. Wurde aber auch dringend Zeit. Jetzt wird dieses Blog (und noch einige andere Dinge) auf einem schnellen Athlon XP 1800+ mit 1 GB RAM ausgeführt. Im Gegensatz zu dem vorigen virtuellen Server mit 1 GHz und geradezu lächerlichen 256 MB RAM ein rasend schnelles Teil.

Natürlich läuft das System auf Windows Server 2003 mit ASP.NET 2.0 und SQL Server 2005. Kein PHP, kein MySQL!

Als Mailserver kommt übrigens der hMailServer zum Einsatz. Sehr zu empfehlen, wird ständig weiterentwickelt und läuft mit MySQL oder SQL Server. Ich glaube der einzige vernünftige kostenlose Mailserver für Windows.

Installiert man zunächst Outlook Web Access (OWA) 2007 in einen frischen IIS auf Windows Server 2003, gibt es noch keine Probleme.
Installiert man nun die WSS 3.0, um z.B. die "öffentlichen Ordner" mit Exchange/Outlook verwenden zu können, kommen die Probleme.

Möglichkeit 1: Man installiert die WSS in eine eigene neue Website. Problem: Port 80 wird nun also von der Standardwebsite und von der SharepointSite verwendet => Nicht möglich (mit nur einer IP).

Möglichkeit 2: Mit dem Sharepoint Administrationstool lassen sich auch die Services in die vorhandene Standardwebsite installieren. Problem: Da beim ersten Einrichten kein Ordner angegeben werden kann wird WSS direkt in die Standardwebsite in "/" eingerichtet. => Das Problem ist bekannt und für Exchange 2003 gibt es hier auch eine Lösung: Microsoft KB 823265 In diesem Artikel werden die von OWA benötigten Ordner einfach der Kontrolle durch WSS entzogen.

Das ganze hilft trotzdem nicht bei Exchange 2007!

Nach diversen Experimenten am heutigen Nachmittag habe ich nun die Lösung gefunden:

1. OWA 2007 muss installiert und funktionsfähig sein. Ordner: http(s)://localhost/owa
Dann so vorgehen wie in Möglichkeit 2 beschrieben, also eine neue Sharepoint "Webanwendung" in die vorhandene Standardwebsite installieren.

2. Testen ob nun die Sharepoint Services laufen. Dazu im Adminstrationstool eine neue "Websitesammlung" erstellen (Ich frage mich wirklich wie das in der englischen Version heißt) und schauen ob diese läuft. Im Beispiel unter http://localhost/websites/test1
(Der Unterordner "websites" war bereits als websitepräfix vorgegeben)

3. "Verwaltete Pfade definieren" wählen, und den Pfad "/" markieren und löschen.

4. Als letztes muss nun die web.config im Root der Standardwebsite geändert werden, denn sonst läuft OWA nicht und quittiert den Aufruf mit einer Sicherheitsfehlermeldung im Eventlog. Also die Web.config öffnen und folgendes hinter den letzten <location> Eintrag anfügen:

  <location path="owa">
    <system.web>
    <trust level="Full" originUrl="" />
    <identity impersonate="false" />
    <authorization>
        <allow users="*" />
    </authorization>
    <httpModules>
           <clear />
     </httpModules>
     <pages enableSessionState="true" enableViewState="true" enableViewStateMac="true" validateRequest="false" />
    </system.web>
  </location>

Wichtig ist vor allem das Trustlevel, denn das Standardtrustlevel für die gesamte Website wurde von WSS auf "WSS_Minimum" festgesetzt. In dieser "Trust-Umgebung" verweigert aber OWA seinen Dienst.

Der <pages> Eintrag ist nicht notwendig, kann aber bei anderen Applikationen notwendig werden, die auf SessionState angewiesen sind. (Z.B. OWAAdmin)

Nach den Änderungen den IIS neu starten und schon laufen die Sharepoint Services gemeinsam mit Outlook Web Access auf einer IIS Website, auf einem Port.

Seit gestern gibt es dasBlog in der Version 1.9. 

Also gerade auch mal upgedated. Jetzt funktioniert auch der Bilder Upload mit dem Windows Live Writer. Außerdem läuft die Anwendung jetzt auf ASP.NET 2.0

Update: Nur das dasBlog automatisch alle vorkommen von dem Wort dasBlog durch einen Link ersetzt und wenn man ein Bild so nennt, wird es nicht korrekt angezeigt...

Nachdem unser kleines Projekt (WeissteNochGestern.de) nun auf ASP.NET 2.0 läuft, hab ich natürlich für den Client (zum Bilder Upload) auch Click-Once verwendet.
Nun bin ich in Leipzig an der FH und wollte mal schauen, ob der Client auch vernünftig läuft, und was muss ich feststellen:
Es läuft nicht!

Problem 1:
Es war kein .NET Framework 2.0 installiert... aber dazu ist auf der publish Seite ein Link, mit dem die Prerequisites installiert werden...ok, klicks ich drauf und denk mir läuft... .NET 2.0 wird installiert, und ich versuchs nochmal. Wieder eine Fehlermeldung: .NET 2.0.xxxx stimmt nicht mit 2.0.50727.42 überein.. es stellt sich raus, dass dieses Setup für die Voraussetzungen auf eine Beta von .NET 2.0 zeigt!!! Hab bisher noch nicht nachgeguckt, aber ist das bereits als Bug gemeldet, oder liegt der Fehler bei mir?

Problem 2:
Nach der Installation der richtigen Framework Version, dachte ich es läuft... aber wieder eine Fehlermeldung.
Da die Verbindung ins Internet in der FH nur über einen Proxy mit Authentication läuft, hacke ich meine Kontodaten ein, und die publish seite öffnet sich. Nach klicks auf Run kommt dann aber die Fehlermeldung, dass die Datei xxx.application nicht runtergeladen werden konnte. Nun ist meine Frage: Gibt es keine Möglichkeit Click-Once zu nutzen, wenn man auf einen Proxy mit Authentifizierung angewiesen ist?

Fazit: Click-Once ist wirklich eine coole Erfindung, aber evtl. noch nicht ganz ausgereift!?

So, nachdem ich nach der Student Technology Conference 2005 zu Hause angekommen war, erstmal die Visual Studio 2005 Beta DVD reingeschoben und in einer VM installiert.
Angeregt durch die Vorträge auf der STC sitze ich nun davor, und stelle erstmal fest: Es handelt sich um die StandardEdition..schade, ich wollte doch besonders auch das UnitTesting und die TS funktionalitäten kennenlernen.
Und auch der SQL Server ist nicht dabei, macht aber nichts, da ich mir den bereits runtergeladen hatte.

Wer übrigens interesse an ASP.NET 2.0 WebSpace hat kann sich gerne melden. Is noch Platz auf meinem Windows Server 2003.