Programmierung « COTEC-IT-Systeme GmbH – Blog
Zurück zum Start

Archiv für die Kategorie ‘Programmierung’

Textfetzen in Dateien finden (grep für Windows 7)

Montag, 07. Februar 2011

Die Windows PowerShell machte es „relativ einfach“ möglich, nach Textfetzen in Dateien zu suchen ohne Index-Dienste oder ähnliches bemühen zu müssen. Der Befehl dafür ist zwar etwas lang, aber durchaus verwendbar.

Beispielsweise ist es mit dem nachfolgenden Konstrukt möglich aspx- und ascx-Dateien des aktuellen Verzeichnisses und der Unterwerzeichnisse nach dem Auftreten eines ASP-Repeaters zu durchsuchen:

Get-ChildItem .\ -include *.as?x -recurse | select-string -pattern ":Repeater"

IceWarp mit SQL Server auf Windows Server 2008 64-Bit

Dienstag, 09. November 2010

Soll ein Icewarp Mailserver auf einem aktuellen Windows Server 2008 64-Bit Betriebssystem eingesetzt werden und als Datenbank einen Microsoft SQL Server (ebenfalls 64-Bit) nutzen, muss darauf geachtet werden, die „richtige“ ODBC-Datenquelle einzurichten.

Das Problem ist, dass die 32-Bit Anwendung Icewarp auch 32-Bit-Treiber für ODBC benötigt und die unter „Datenquellen  (ODBC)“ aufrufbare Konfiguration 64-Bit-Treiber verwendet/verknüpft.

Allerdings existiert auch eine Variante von „Datenquellen  (ODBC)“ für die 32-Bit-Welt. Auf diese kann jedoch nur über das direkte Starten der Datei %system_root%\sysWOW64\odbcad32.exe zugegriffen werden.

Der Verweis in der Verwaltung hingegen zeigt auf %system_root%\system32\odbcad32.exe, mit welchem nur Datenquellen für 64-Bit-Anwendungen konfiguriert werden können.

Im Beispiel des Icewarp-Servers muss demnach eine ODBC-Datenquelle mittels %system_root%\sysWOW64\odbcad32.exe angelegt werden.

Kurz:

  • 64-Bit-Datenquellen: %system_root%\system32\odbcad32.exe
  • 32-Bit-Datenquellen: %system_root%\sysWOW64\odbcad32.exe

Stacktrace während der Laufzeit

Mittwoch, 29. September 2010

Vielleicht nicht die schönste Methode, aber doch mitunter hilfreich beim Debuggen von .Net-Anwendungen:

Die Framework-Klasse System.Diagnostics.StackTrace stellt nützliche Funktionalität zur Verfügung. So gibt folgendes Beispiel im Debug-Fenster von Visual Studio bei jedem Aufruf, die 3 letzten Zeilen des aktuellen Stacktraces zurück.

[code language=“csharp“]

StackTrace trace = new StackTrace();
Debug.WriteLine(string.Format("->{0}",trace.GetFrame(0).GetMethod()));
Debug.WriteLine(string.Format("—>{0}",trace.GetFrame(1).GetMethod()));
Debug.WriteLine(string.Format("—–>{0}",trace.GetFrame(2).GetMethod()));

[/code]

(Das Beispiel ist mit Vorsicht zu genießen, da nicht geprüft wird, ob überhaupt so viele Frames verfügbar sind)

Jet für 64bit verfügbar

Donnerstag, 27. Mai 2010

Lange Zeit war es nicht möglich den JET-Datenbank-Treiber unter x64-Windows (64 Bit) zu nutzen.

Mit diesem Treiber konnte einfach auf Access-Datenbanken (MDB-Dateien) zugegriffen werden. Sehr praktisch, da es im Grunde auf nahezu jedem Windows funktionierte ohne bspw. eine Version des SQL Servers zu installieren.

Leider lieferte Microsoft diesen Treiber für 64 Bit Systeme nicht mehr aus. So dass bspw. Programme basierend auf der CLR (.Net-Framwork) unter 64-Bit-Windows (und der „Any CPU“-Platform) nicht mehr korrekt funktionierten, weil der Datenbankzugriff über JET nicht mehr möglich war.

Dieses Problem dürfte seit kurzen der Vergangenheit angehören, da Microsoft jetzt endlich auch für 64 Bit den JET-Treiber im Rahmen der „Microsoft Access Database Engine 2010 Redistributable“ zur Verfügung stellt.

Das Paket kann im  Downloadbereich von www.microsoft.com geladen werden.

Workaround: Linq .designer.cs-Datei verschwindet

Donnerstag, 01. April 2010

Heute hat Visual Studio 2008 damit genervt, dass die zu einer Linq-To-SQL-Class gehörige (automatisch erzeugte) .designer.cs-Datei nach eine Änderung im einfach von der Platte verschwand.

Der Versuch die Datei mittels des „Run Custom Tool“ neu zu erzeugen mündete in der Fehlermeldung:

The custom tool ‘MSLinqToSQLGenerator’ failed. Unbekannter Fehler

Es existierte eine zum Linq-DataContext  gehörige weitere .cs-Datei mit Erweiterungen der partial classes um eigene Funktionen (operator ==, etc.).

Der Fehler scheint grundsätzlich an den using-Einträgen zu liegen, die nicht außerhalb des namespace auftauchen dürfen.

[code lang=“csharp“]
using System;
using System.Linq;
using System.Xml;
using System.Xml.Linq;

namespace Libraries.Data
{

}
[/code]

ändern in

[code lang=“csharp“]
namespace Libraries.Data
{

}
[/code]

Ein wenig Suchen im Netz führte zu dieser durchaus verwendbaren Lösung: The custom tool ‘MSLinqToSQLGenerator’ failed

JKDefrag wird zu MyDefrag 4.0

Freitag, 17. Juli 2009

Das leistungsstarke und kostenlose Defragmentierprogramm liegt jetzt in der überarbeiteten Version 4.0 vor (siehe Artikel Software zum Defragmentieren…)

Zudem wurde für diesen Release auch der Name geändert: Aus JKDefrag wird MyDefrag.

Die Software ist jetzt unter www.mydefrag.com erhältlich.

.NET / C#: COM Objekt freigeben

Donnerstag, 11. Juni 2009

Bei Verwendung von COM-Objekten in .NET ist es häufig notwendig, die referenzierten Objekte freizugeben. Dies funktioniert am sichersten mittels:

[csharp wraplines=“true“ light=“true“]
System.Runtime.InteropServices.Marshal.ReleaseComObject(object o)
[/csharp]

Das einfache Auf-Null-Setzen des entsprechenden Objekts reicht nicht aus.

(Siehe MSDN-Doku zu ReleaseComObject)