Problem 1: Kopiert man einen Ordner, der Unterordner enthält, in Richtung Office365, so wird erst der Hauptordner ordentlich angelegt, dann werden dessen Emails übertragen. Der erste Unterordner wird ebenfalls angelegt. Danach erfolgt leider ein Abbruch mit der Servermeldung, dass der Ordner in Office365 nicht vorhanden sei. Im Nachgang lassen sich die Dateien aber problemlos in den Ordner kopieren. Im Endeffekt bedeutet das aber, dass ich alle Ordner einzeln transferieren muss.

Problem 2: Enthält ein Ordner Zeichen wie beispielsweise einen Slash: “12/2012″, so hat man ein echtes Problem: In Office365 wird nur der Ordner 12 angelegt und unterhalb der Ordner 2012 angezeigt. Scheinbar wird der Slash als Trennzeichen gewertet. Auf dem Server landet also erst einmal nur die 12. Löschen lässt sich der Ordner nicht mehr, es kommt ein Fehler. Die einzige Hilfe ist hier, den übergeordneten (!) Ordner zu löschen, was aber auch nur geht, wenn der Papierkorb nicht bereits vom ersten Versuch einen gleichnamigen Ordner enthält.

Zwischenstand: Ich werde den Transfer direkt mit Mozilla Thunderbird erst einmal abbrechen. Wenn ich jeden Ordner einzeln übertragen muss, werde ich noch Wochen beschäftigt sein, da man mit einer weiteren Aktion immer erst den Abschluss der vorangegangenen Aktion abwarten muss. Wenn ich an die vielfältigen Email-Konfigurationen von Kunden denke, würde ich momentan sicher erst einmal vor einem Wechsel in Office365 warnen, wenn man keinen erprobten Migrationspfad hat. Vielleicht ist ja aber auch Outlook wirklich das Mittel der Wahl. Ich werde meinen Test darum darauf verlagern.

Vom Prinzip her stellt das kleine Paket einen IMAP-Webspace von 25GB zur Verfügung und ermöglicht mir (und hier unterscheidet es sich deutlich von Mitbewerbern), mit Outlook Web Access bequem darauf zuzugreifen. Je nach Paket ist auch noch ein Office-Speicherplatz dabei. Der Komfort einer solchen Lösung ist hoch und meine Endgeräte, im speziellen das WindowsPhone sollten davon profitieren.

Leider steht da noch die Frage im Raum: was mache ich mit meinen lokalen Mails in Thunderbird. Ich habe einige Lösungen gefunden, die alle grob wie folgt gingen: Nutze ein Tool und exportiere oder archiviere Thunderbird. Importiere alles in Outlook und schiebe es dann in die Cloud. Nur leider habe ich kein Outlook installiert und wollte auch nicht erst alle Daten übernehmen. Dann kam mir eine andere Idee: Office 365 stellt mir auch eine IMAP-Schnittstelle zur Verfügung. Diese soll beispielsweise mit Thunderbird genutzt werden. Und somit ist die Lösung extrem einfach:

Ich habe meinen Office 365 Account in Thunderbird angelegt. Nun kann ich alle Ordner (auch mehrere und rekursiv) per Drag&Drop nach Office 365 schieben und muss nur noch warten. Zur Sicherheit schiebe ich mit gedrückter Strg/Ctrl-Taste, somit kann ich nach dem Test entscheiden, welchen Baum ich löschen werden.

Unit SqlExpr wurde mit einer unterschiedlichen Version von SqlConst.SNOERROR compiliert

Leider haben mir der Tipp auf Delphipraxis nur bedingt weitergeholfen. Dazu soll folgender Code:

SNOERROR ='';
SWARNING ='';
SCONNECTIONFAILED ='';
SDRIVERINITFAILED ='';
SOPTLOCKFAILED ='';
SINVALIDREF ='';
SNOTABLE ='';
SDBXError ='';
SNODATA ='';
SSQLERROR ='';
SSQLServerError'';

in der SqlConst.pas im Source\VCL Ordner eingefügt werden und das ganze erzeugt und nach {Delphi}\Lib und {Delphi}\Lib\Debug verteilt werden. Wie man diese Unit aber erzeugt, stand leider nicht dabei und es ist mir auch nicht gelungen, den Code habe ich trotzdem eingefügt, da diese pas-Datei im Suchpfad ist.

In der Entwickler Ecke habe ich dann den nächsten Tipp gefunden:

Das nächste Problem scheint DBExpress zu sein, einige Projekte konnten nicht kompiliert werden, da SqlExpr.dcu mit einer anderen Version kompiliert wurde. Den Fehler konnte ich mittlerweile beheben, das Update hat im Verzeichnis $(DELPHI)\lib\ eine Datei SqlConst.dcu.de angelegt. Ich habe die Datei SqlConst.dcu dann nach SqlConst.dcu.org umbenannt und SqlConst.dcu.de nach SqlConst.dcu. Das gleiche auch nochmal im Verzeichnis $(DELPHI)/lib/debug.

Nachdem ich auch diese Umbenennung durchgeführt habe, klappte es wieder wunderbar. Der Fehler scheint übrigens irgendwie mit der deutschen Lokalisierung vom ServicePack 1 für Delphi 7 im Zusammenhang zu stehen.

Zuerst braucht man das Tool Freemake. Dabei handelt es sich um einen universellen Video-Konverter, der beinahe jedes Videos in mp4 wandeln kann. Dabei kann man für mp4 ein Profil hinterlegen, was den Ton auf Stereo begrenzt und das Video auf 800×480 mit dem H.264 Codec.

Ein so konvertiertes Video kann man einfach im “Eigene Videos” Ordner von Windows ablegen und per Zune übertragen.

Der Workaround ist zum Glück auch gleich angegeben, und kann dann so aussehen:

string filename = string.Copy(filenameForOutput);
if (!string.IsNullOrEmpty(filename))
{   
   TextRenderer.MeasureText(filename, Font, Size,
     TextFormatFlags.PathEllipsis | TextFormatFlags.ModifyString);
   filename = filename.Substring(0, filename.IndexOf('\0'));
}

Der Source zeigt auch gleich noch eine kleine andere Ergänzung: Die Funktion modifiziert den übergebenen String. Man sollte diesen also vorher kopieren, sofern man nicht schon mit einer Kopie des Strings arbeitet.

SELECT [Activity], [Duration] FROM TableName

Die Aufgabenstellung bestand darin, die Zeiten zu addieren. Leider wurde dieser Versuch

SELECT SUM([Duration]) FROM TableName

abgelehnt:

Der Operanddatentyp time ist für den sum-Operator ungültig.

was zwar nicht einleuchtend, aber auch nicht zu ändern war.
Die Lösung war die vorherige Umwandlung der Zeit in eine Datumsdifferenz vom Typ Minuten:

SELECT SUM(DATEDIFF(MINUTE, '00:00:00', [Duration])) FROM TableName

Label1.Text = Request.ApplicationPath;
Image1.ImageUrl = Request.ApplicationPath + "/images/Image1.gif";
Label2.Text = Image1.ImageUrl;

Aber damit steht man schnell vor einem Problem: Liegt die Anwendung im Root, wie es beispielsweise standardmäßig beim Visual Studio 2010 Development Server der Fall ist, so erhält man als Ergebnis nur ein /. Die korrekte Zeile wäre dann also:

Image1.ImageUrl = Request.ApplicationPath + "images/Image1.gif";

Befindet sich die Seite aber in einem virtuellen Verzeichnis, so kommt das Verzeichnis ohne abschließenden / zurück:

Image1.ImageUrl = Request.ApplicationPath + "/images/Image1.gif";

Je nach Speicherort muss man also beim händischen Zusammensetzen der URL’s also den abschließenden Slash berücksichtigen, oder eben auch nicht.

Eine gute Lösung habe ich in einem Blog-Artikel von 2004 gefunden:

VirtualPathUtility.ToAbsolute("~/images/Image1.gif")

Damit überlässt man Asp.NET die korrekte Umsetzung, welche auch tadellos und ohne Experimente funktioniert!

Update:
Manchmal sieht man einfach den Wald vor lauter Bäumen nicht. Die kürzere Lösung ist Url.Content, welche ein vergleichbares Ergebnis liefert und auch in den Templates von Asp.NET MVC3 verwendet wird.

Zum Prüfen der Attribute wurde folgende Funktion verwendet:

static void CheckAttribute(MemberInfo memberInfo)
{
    var attributes = memberInfo.GetCustomAttributes(true);
    if (attributes.Length == 0) return;
 
    foreach (object attribute in attributes)
        Console.WriteLine("The type of the attribute in {1} is {0}.", 
            attribute, memberInfo.Name);
}

Weiterhin wurden zwei Klassen geschrieben, wo einmal eine abgeleitete Methode und eine abgeleitete Propertie mit Attributen versehen wurde:

public abstract class BaseClass
{
    [TestAttribute]
    public virtual String TestProperty { get; set; }
 
    [TestAttribute]
    public virtual void TestMethod() { return; }
}
public class DerivedClass : BaseClass
{
    public override string TestProperty { get; set; }
    public override void TestMethod() { base.TestMethod(); }
}
 
public class TestAttribute : Attribute
{
}

Zu guter Letzt wurde das ganze überprüft:

Console.WriteLine("BaseClass:");
CheckAttribute(typeof(BaseClass).GetProperty("TestProperty"));
CheckAttribute(typeof(BaseClass).GetMethod("TestMethod"));
 
Console.WriteLine("DerivedClass:");
CheckAttribute(typeof(DerivedClass).GetProperty("TestProperty"));
CheckAttribute(typeof(DerivedClass).GetMethod("TestMethod"));

Das Ergebnis fiel überraschend aus:

BaseClass:
The type of the attribute in TestProperty is TestAttrib.TestAttribute.
The type of the attribute in TestMethod is TestAttrib.TestAttribute.
DerivedClass:
The type of the attribute in TestMethod is TestAttrib.TestAttribute.

Wähernd die Methode TestMethod in beiden Klassen als mit dem Attribut ausgezeichnet, erkannt wurde, war dies bei der Eigenschaft TestProperty nicht der Fall. Um die Ursache zu finden, war ein Blick in die IL notwendig. Hier die Umsetzung der BaseClass, welche das Attribute in beiden Fällen korrekt definiert.

.method public hidebysig newslot virtual instance void TestMethod() cil managed
{
    .custom instance void TestAttrib.TestAttribute::.ctor()
}
 
.property instance string TestProperty
{
    .get instance string TestAttrib.BaseClass::get_TestProperty()
    .set instance void TestAttrib.BaseClass::set_TestProperty(string)
    .custom instance void TestAttrib.TestAttribute::.ctor()
}

Die Ableitung war aber überaschend umgesetzt. Während die Methode offensichtlich überschrieben wurde, wurde die Propertie quasi neu angelegt, aber ohne dem zugewiesenen Attribut.

.method public hidebysig virtual instance void TestMethod() cil managed
{
}
 
.property instance string TestProperty
{
    .get instance string TestAttrib.DerivedClass::get_TestProperty()
    .set instance void TestAttrib.DerivedClass::set_TestProperty(string)
}

Damit war das Ergebnis der Untersuchung: GetCustomAttributes hat definitionsgemäß auch die Ableitungen untersucht. Jedoch verlieren sich die Attribute beim Überschreiben von Properties. Eine Erklärung dafür habe ich bis jetzt nicht gefunden, ich konnte den Effekt aber in .NET 2.0 – 4.0 nachstellen.