.NET und PDF Software

Glaubt man der Dokumentation von HttpRequest.ApplicationPath, so ist es recht einfach, einen Link in einer eigenen Asp.NET Seite zu verwenden:

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.

Die Webseite dotnet-snippets.de wird 5 Jahre alt. Herzlichen Glückwunsch!

Wer die Seite noch nicht kennt, aber mit Microsoft .NET entwickelt, sollte einfach mal vorbeischauen. Es gibt viele kurze hilfreiche Codeschnipsel zu den meisten Problemchen, die man so im täglichen Leben hat.

Für eine Funktionalität auf einem Buildserver wurde ein Skript benötigt, dass in der Lage ist, Archive zu erstellen. Ein idealer Anwendungsfall für Powershell, wenn man erst einmal ein paar wichtige Sachen erkannt hat.

Das Skript soll zwei Parameter empfangen. Der erste Parameter $destname enthält lediglich den Zielnamen des Archiv’s. Der zweite Parameter $source ist der Ordner, wo alle zu packenden Dateien abgelegt sind. {dest} und {temp} sind Platzhalter fester Pfade für das zu erstellende Archiv und temporäre Dateien.

param ([string] $destname, [string] $source)
$path = "{dest}\" + $destname  + ".zip"
$temp = "{temp}"

Um das Skript einfach einsetzen zu können, sollte in Powershell kein Modul mehr nachinstalliert werden müssen. Darum wurde auf die Funktionalität der gepackten Ordner von Windows zurückgegriffen. Diese gibt es schon geraume Zeit im Standard-Lieferumfang. Um diesen Ordner nutzen zu können, erstellt man ein leeres Archiv mittels einer kleinen Bytefolge, dass dann einfach wie ein Ordner angesprochen wird (mittels des COM-Objektes Shell.Application):

Set-Content $path ("PK" + [char]5 + [char]6 + ("$([char]0)" * 18))
$ShellApp = New-Object -ComObject Shell.Application
$ZipPackage = $ShellApp.Namespace($path)

Dieser Zwischenschritt löscht dem temporären Ordner und kopiert eine Auswahl von Dateien aus dem Quellverzeichnis in den frisch erstellen temporären Ordner:

rmdir $temp -Recurse -Force
 
mkdir $temp
$files = Get-ChildItem -Path $($source + "\*") -Include *.exe,*.dll  | Copy-Item -Destination $temp
mkdir $($temp + "\Data")
$files = Get-ChildItem -Path $($source + "\Data\*") -Include *.*  | Copy-Item -Destination $($temp + "\Data")

Der letze Schritt war der schwerste: Als erstes wird der komplette temporäre Ordner einfach in das Archiv kopiert. Leider ist dieser Vorgang asynchron. Beendet man jetzt das Skript und die Powershell, so wird der Vorgang auch mit abgebrochen. Also muss man mittels Sleep solange warten, bis das Archiv garantiert erstellt ist. Diese Krücke ist zwar unbefriedigend, aber leider ist mir dafür keine alternative Lösung eingefallen:

$ZipPackage.CopyHere($temp, 4)
Start-Sleep -s 15

In einem Backup-Ordner stand die Aufgabe an, alte Dateien automatisch löschen zu lassen. Dazu wurde folgendes Skript eingesetzt:

Get-ChildItem -Path . |
  Where-Object -FilterScript {($_.LastWriteTime -lt [DateTime]::Now.AddDays(-7))} |
  Remove-Item -force

Zuerst werden alle relevanten Dateien ermittelt. Danach wird auf diese Liste ein Filter gesetzt, der nur Dateien ermittelt, die älter als 7 Tage sind. Hierzu wird eine Rückgriff auf DateTime aus dem Net-Framework genutzt. Es bietet mit Now und AddDays die gewünschte Funktionalität, von jetzt 7 Tage nach hinten zu gehen. Als letzten Schritt muss die ermittelte Liste lediglich an Remove-Item weitergereicht werden.

Beim Ausführen einer Powershell-Datei erhielt ich im Protokoll neulich folgende bekannte Fehlermeldung, obwohl Set-ExecutionPolicy auf RemoteSigned gesetzt war:

Die Datei "...test.ps1" kann nicht geladen werden, da die Ausführung
 von Skripts auf diesem System deaktiviert ist. Weitere
 Informationen erhalten Sie mit "get-help about_signing".
Bei Zeile:1 Zeichen:2
+ . <<<<  '...test.ps1'
    + CategoryInfo          : NotSpecified: (:) [], PSSecurityException
    + FullyQualifiedErrorId : RuntimeException

Die Lösung lag letztendlich darin, dass das entsprechende Skript auf einem 64Bit-System als 32Bit-Task aufgerufen wurde. Es war ausreichend, Set-ExecutionPolicy unter Powershell (x86) ebenfalls aufzurufen und entsprechend zu setzen.

Seit einigen Tagen versuche ich das Servicepack 1 (KB976932) von Windows 7 zu installieren. Immer ohne Erfolg. Der Vorgang startet ganz normal, aber beim Neustart des Rechners läuft die Konfiguration zügig auf 99% hoch, bevor ein Fehler auftritt und alles wieder rückgängig gemacht wird.

Da das ganze ca. eine Stunde dauert, ist jeder Test schwierig und einfach aufwändig. Im Ereignisprotokoll oder WindowsUpdate.log waren leider keine sinnvollen Hinweise zu finden, lediglich kurz nach dem Hochfahren wird der Fehlercode 8004402F angezeigt. Ein ähnliches Problem brachte dann auch noch die Installation vom Internet-Explorer 9.

Glücklicherweise habe ich heute einen recht alten Blog-Beitrag für Windows Vista gefunden, der dann auch half. Mein %TEMP% Ordner war auf Laufwerk D umgestellt. Dieses Laufwerk ist aber ein verschlüsseltes TrueCrypt-Laufwerk, was beim Neustart nicht zur Verfügung steht. Ich habe diesen Ordner wieder auf eine unverschlüsselte Festplatte umgelenkt, und die Installation war erfolgreich.

Schade, dass hier nirgends ein entsprechender Fehler ausgegeben wird. Beim Starten der Installation hätte mir der Hinweis auf einen nicht verfügbaren Temp-Ordner viele Stunden der Suche erspart.

Im Rahmen einer Datensicherung mit Acronis sollte das Sicherungsarchiv auf Wechselmedien gespiegelt werden. Dazu bietet sich das Kommandozeilentool Robocopy an, das seit Jahren zum Lieferumfang von Windows gehört und extrem mächtig ist. Grundsätzlich hat es funktioniert, aber der Abschlusstask mit Robocopy wurde von Acronis immer als fehlerhaft bewertet. Nach einer Weile war die Ursache klar: Kommandozeilenbefehle liefern als Rückgabewert üblicherweise

= 0: kein Fehler
> 0: Fehler

Robocopy belegt aber die Codes 0-7 mit Erfolgsmeldungen. Um diesem Verhalten gerecht zu werden, Acronis im Erfolgsfalle aber Null zurückzugeben, wurde eine kleine Batchdatei geschrieben, welche die ErrorLevel 0-7 in 0 umwandelt und in allen anderen Fällen die 8 zurückgibt (der reale Rückgabewert ist bei Fehlern egal, da Robocopy eine Logdatei schreiben kann).

robocopy "Quellpfad" "Zielpfad" "*.TIB" /PURGE
if NOT errorlevel 8 (EXIT /B 0)
EXIT /B 8

Interessant ist hier besonders die Abfrage

if NOT errorlevel 8

, welche quasi für

if errorlevel < 7

steht. Wer nicht so oft Batch-Dateien schreibt, wird von diesem Verhalten oft überrascht.

Vor kurzem habe ich mein Microsoft Office auf die Version 2010 umgestellt. Wie ich einige Tage später festgestellt habe, war seit dem der HTML/Aspx-Editor von Visual Studio 2008 nicht mehr stabil. Entweder blieb Visual Studio hängen oder es wurde automatisch neu gestartet.

Eine Lösung findet sich in einem MSDN Blog:
Die Installation Microsoft Visual Studio Web Authoring Component muss einfach nur repariert werden, danach funktioniert Visual Studio wieder ohne Probleme.

Dieses Wochenende fand in Karlsruhe der .NET Open Space Süd 2010 statt. Für mich war es das erste Mal, das ich an so einer Veranstaltung teilgenommen habe. Die Veranstaltung wurde in den Räumen von bluehands ausgerichtet.
Die Themen wurden durch die ca. 50 Teilnehmer selbst bestimmt. Dabei legte sich automatisch ein großer Fokus auf die Schnittstelle zwischen Kunden und Entwickler. Hier stecken wohl für alle die größten Probleme bzw. es ist einfach der meiste Handlungsbedarf. Es gab einige Sessions in Richtung BDD und DDD. Diese Sessions waren sehr informativ und es fand eine angeregte Diskussion ab. Ein Fazit der Veranstaltung war für viele, dass wir Entwickler mit Tools für die Entwicklung selbst, gut versorgt sind. Wo es mangelt, ist eine sinnvolle Unterstützung durch Software, Anforderungen des Kunden zu erfassen und umzusetzen bzw. deren Umsetzung zu prüfen.
Ein Highlight der Veranstaltung war ein kleines DoJo, initiert durch Ilker. Thema war die Umsetzung von arabischen Zahlen in das römische Zahlensystem.

Auf einem Windows 2008 Server führen wir die Datensicherung mit Acronis Backup & Recovery 10 durch. Diese Sicherung funktionierte wunderbar, bis das Kennwort des Administrators gewechselt wurde. Die Fehlermeldung deutet auch auf genau dieses Problem hin:

Typ:            Fehler
Datum und Zeit: 30.04.2010 11:51:45
Backup-Plan:    Backup 10.03.2010 21:03:53
Task:           Inkrementelles Backup
Code:           11.863.304(0xB50508)
Modul:          181
Besitzer:       Administrator@S1???????
Nachricht:      
  Task 'Inkrementelles Backup' fehlgeschlagen: 'Ausführen des Tasks fehlgeschlagen: Unerwartete Bedingungen.
Zusätzliche Info: 
--------------------
Fehlercode: 110
Module: 9
LineInfo: 652a61e599f14d6a
Felder: 
Nachricht: Ausführen des Tasks fehlgeschlagen: Unerwartete Bedingungen.
--------------------
Fehlercode: 65520
Module: 0
LineInfo: bd28fdbd64edb8bc
Felder:  code : 2147943726
Nachricht: Logon failure: unknown user name or bad password
--------------------'.
Acronis Knowledge Base: http://kb.acronis.com/errorcode

Ereignis-Code: 0x0009006E+0x0000FFF0

Leider musste ich ziemlich lange suchen, bis ich das Benutzerkonto des Tasks gefunden hatte. Hierzu muss man in Acronis den Task bearbeiten und dann einfach dieser Grafik folgen.

Danach laufen die Sicherungstask wieder ohne jegliche Probleme.