-
ACHTUNG - NEUES BLOG
Ab sofort steht unter http://devtyr.norberteder.com mein neues Blog zur Verfügung. Dieses Blog wird nicht weiter betreut, bleibt aber erhalten. Neue Eintr%auml;ge erfolgen nur mehr im neuen Blog. Kommentare werden ebenfalls nicht mehr behandelt. Wer weiterhin meinen Einträgen und Aktivitäten folgen möchte, möge bitte RSS-Feeds, Verlinkungen etc. an die neue Location anpassen.
|
Windows Dienste mit C# und .NET 2.0 kontrollieren
14.12.06 - .NET, Base Framework Beitrag von Norbert Eder| | Hier eine kleine Demoklasse die den Umgang mit Windows-Diensten zeigt. Die Klasse selbst bietet nur die Möglichkeit den Status eines Dienstes abzufragen und diesen zu Starten bzw. zu Stoppen. Weitere Möglichkeiten kann den Klassen ServiceController entnommen werden.
public class ProcessHandler
{
private string processName = null;
public string ProcessName
{
get { return this.processName; }
set { this.processName = value; }
}
public ServiceControllerStatus GetProcessState()
{
ServiceController sc = new ServiceController(processName);
if (sc != null)
{
return sc.Status;
}
return ServiceControllerStatus.Stopped;
}
public void StartProcess()
{
ServiceController sc = new ServiceController(processName);
if (sc != null)
sc.Start();
}
public void StopProcess()
{
ServiceController sc = new ServiceController(processName);
if (sc != null && sc.CanStop)
sc.Stop();
}
}
| | | Kommentar hinzufügen
- 13 mal angesehen
| 1 Trackbacks
| Permalink | Trackback-URL |
Ist die VB-Community am Sterben?
13.12.06 - Entwicklung, Diskussionen Beitrag von Norbert Eder| | Erst kürzlich hatte ich eine große Diskussion wo sich User beschwert haben, dass zum Thema VB kaum mehr etwas Neues zu lesen ist, die Unterstützung fehlt und viele weitere Vorwürfe.
Woran das wohl liegen mag?
Nun, VB(6) ist anscheinend eben vom Aussterben bedroht. Viele haben auf .NET gewechselt, oder sind zumindest dabei. Kritische Projekte wurden ohnehin nihct in VB umgesetzt. So gesehen sprechen mittlerweile wenig Gründe dafür, VB einzusetzen.
Auf der anderen Seite muss auch erwähnt werden, dass im Internet zu so ziemlich jedem VB-Problem auch eine Lösung zu finden ist. Warum also diese Aufregung? Ist hier eine Google-Schulung notwendig?
Mittlerweile sollte doch jedem Entwickler klar sein, dass VB aktuell fast keine Existenzberechtigung mehr hat. Entweder man steigt auf .NET um, oder man wendet sich anderen Programmiersprachen zu. Für Anwendungen, die mit deinem Framework á la .NET, Java nicht sinnvoll umzusetzen sind, eigenen sich andere Sprachen ohnehin besser. Ich denke hierbei beispielsweise an C++.
Mir stellen sich aber dennoch einige Fragen zu diesem Thema:
1. Kann es in der Tat sein, dass viele Unternehmen noch auf alte (bewährte) Techniken setzen und sich vor neuen Errungenschaften (die mitunter gar nicht mehr so neu sind) verstecken?
2. Fällt es wirklich einigen Entwicklern schwer, sich auf neue Gegebenheiten einzustellen? Selbst wenn die Entwickler altersmäßig < 25 anzusiedeln sind?
3. Liegt es eventuell an der OOP die unter .NET bzw. Java angewendet werden sollte? Ist Software Architektur zu schwer zu verstehen?
Bis zu einem gewissen Grad kann ich Kundgebungen des Unmutes noch verstehen, aber es sollte niemand die Augen vor neuen Techniken verschließen. Eigenes Potential bleibt auf der Strecke und die dahinterstehenden Unternehmen können mit dem Punkt der Zukunftssicherheit nicht wirklich punkten. Und genau das könnte sich fatal auswirken. Vielleicht nicht sofort, aber bald ...
Viele scheuen auch davor zurück, sich externe Berater zuzulegen. Eventuell liegt es an den veranschlagten Honoraren, die doch in gewissen Fällen astronomische Höhen annehmen. Dennoch können auf diese Art und Weise gute Ergebnisse erzielt werden. Die eigene Software auf den aktuellsten Stand der Dinge zu bringen würde definitiv nicht zum eigenen Nachteil sein.
Im Vergleich zu dem was durch eine veraltete Technik an Einnahmen auf der Strasse bleibt, kostet ein Experte eigentlich gar nichts ...
Aber zurück zum Thema: VB stirbt vor sich hin und es wundert mich nicht. Entsprechende Entwickler sollten sich lieber mit der aktuellen Technik beschäftigen und sich selbst auf Vordermann bringen, anstatt ihren Unmut in diversen Foren kund zu tun. Sicher ist sicher.
| | | 6 Kommentare
- 592 mal angesehen
| 0 Trackbacks
| Permalink | Trackback-URL |
ReSharper UnitRun: kostenloser Testdriven.NET Gegenspieler
12.12.06 - .NET, Base Framework, Software Testing, Software Testing Beitrag von Norbert Eder| | Von JetBrains gibt es ein kostenloses Visual Studio Add-In mit dem Unit Tests ausgeführt werden können: ReSharper TestRun [1].
Unterstützt werden folgende Testing-Frameworks:
- NUnit
- csUnit
Ein näherer Blick auf dieses Tool lohnt sich auf jeden Fall.
[1] UnitRun Homepage
via Thomas.
| | | 2 Kommentare
- 794 mal angesehen
| 0 Trackbacks
| Permalink | Trackback-URL |
Neu im Blog-Roll
11.12.06 - Blog-Intern Beitrag von Norbert EderAuf der Suche nach der richtigen Community-Software?
11.12.06 - .NET, Allerlei Beitrag von Norbert Eder| | Ist es nicht oft so, dass man eine Idee hat, aus der eine Community geboren werden soll. Nun entwickeln sich im Laufe der Zeit bestimmte Rahmenbedingungen, die ein derartiges System zu erfüllen haben (abgesehen von den technischen Einschränkungen). Nun, hier eine kleine Liste meiner Punkte:
- Datenbankunabhängigkeit
- Kommerziell nutzbar
- .NET System (C#)
- Forum, RSS, Artikelverwaltung, Userverwaltung
- Erweiterbarkeit
Eigentlich ja gar nicht soviele Anforderungen. Jetzt kommt in der .NET-Welt die große Ernüchterung:
Community Server
Kann anscheinend nur mit einem Microsoft SQL Server. Eine kostenlose Variante ist zwar erhältlich, aber in der Nutzbarkeit sehr eingeschränkt. Die interessanten Versionen kosten eindeutig zuviel. Ergo fällt die Entscheidung dagegen.
DotNetNuke
Das .NET-Pendant zu PhpNuke. Ganz nett, aber schon zuviele Funktionen die angeboten werden. Einiges an Aufwand um das System so anzupassen, dass es meinen Wünschen gerecht ist. Noch dazu nicht wirklich sauber implementiert und VB.NET Code möchte ich dann doch lieber nicht warten müüssen. Fällt also auch aus.
InstantForum.NET
Zwar nur ein Forum, aber kann ja aufgebohrt und erweitert werden. Dann ein Blick auf die Kosten und es folgt ein "Nein, Danke. Dann lieber doch nicht.".
Weitere Lösungen habe ich nicht finden können. Was bleibt? Geld sparen und selbst entwickeln. Da der gewünschte Funktionsumfang nicht allzu hoch ist, sollte dies in annehmbarer Zeit schaffbar sein.
Was mich jedoch an den meisten Systemen die sich .NET bedienen auffällt: Nur weil es sich hier um Produkte handelt, die hauptsächlich auf einer Microsoft Plattform zum Einsatz kommen, sind die Preise noch extra überhöht. Eigentlich ganz schön schlimm. Es muss ja nicht unbedingt für Lau sein, aber für die passende Variante 2000 Euro hinlegen zu müssen (ohne zu wissen, ob die Community dann auch tatsächlich läuft) erscheint mir schon ein wenig unattraktiv.
Für zweckdienliche Hinweise bin ich natürlich - so wie immer - dankbar.
| | | 5 Kommentare
- 557 mal angesehen
| 0 Trackbacks
| Permalink | Trackback-URL |
Adventszeit, Zeit ein wenig mehr zusammenzurücken.
07.12.06 - Blog-Intern Beitrag von Norbert Eder| | Unter diesem Motto haben sich Kai Gloth und meine Wenigkeit zusammengeschlossen, um die .NET Community zukünftig mit Interviews und weiteren Massnahmen zu diversen Themen zu unterstützen. Hier nun eine Vorstellung von Kai selbst, die wir im Rahmen eines ersten kleinen Interviews durchgeführt haben:
Wer ist Kai Gloth?
Weblog: http://blog.veloursnebel.de
Wohnort: Elvershausen, nähe Göttingen, Deutschland
Wie hat sich die Leidenschaft zum Programmieren entwickelt?
Dazu muss ich ein wenig weiter ausholen. Als ich 11 oder 12 Jahre alt war, schenkte mir mein Vater einen Amstrad PC 286. Leider (oder zum Glück) war dieser PC zu der Zeit schon völlig veraltet, so dass es nicht möglich war irgendwelche Spiele zu spielen. Trotzdem interessierte ich mich so sehr für die Technik das ich einfach andere Sachen ausprobiert habe. Erstmals programmiert habe ich dann mit dem im Lieferumfang enthaltenen Basic. Später folgten dann C, Pascal und Cobol. Mit 14 habe ich dann erstmals produktiv in einem Unternehmen gearbeitet und dort projektbezogen programmiert.
Damals und heute finde ich es immer wieder faszinierend, wie Menschen auf neue Programme und die damit verbundenen Möglichkeiten reagieren. Wenn man
seine Arbeit gut gemacht hat, erleichtert man dem User die Arbeit enorm, so daß dieser sich auf wirklich wichtige Sachen konzentrieren kann. Ich denke die Erfüllung von Wünschen (oder Anforderungen) macht für mich die eigentliche Leidenschaft am Programmieren aus.
Seit wann und warum entwickelst du unter .NET?
Die Entwicklung von .NET beobachte ich eigentlich schon von Anfang an. Richtig produktiv habe ich es zum ersten mal mit der Version 1.1 eingesetzt. Bereits zu Beginn habe ich in C# entwickelt, auch wenn VB.NET einige interessante Möglichkeiten eröffnet.
Da ich hauptsächlich Web-basierte Anwendungen schreibe, war der Schritt zu ASP.NET und dem .NET Framework der nächste logische Schritt, welchen ich bis heute nicht bereut habe. Zum ersten Mal war es möglich richtig professionell zu programmieren. Jedem der vorher mit ASP u. VBScript gearbeitet hat, weiß wovon ich spreche.
Für welche Bereiche der Softwareentwicklung interessierst du dich?
Unterm Strich kann man sagen, dass ich mich für alle Bereiche interessiere. Allerdings habe ich bestimmte Vorlieben. Ich arbeite lieber im Hintergrund, sprich, ich schreibe lieber Code, der später von anderen eingesetzt werden kann. Bedingt durch mein Studium beschäftige ich mich jetzt immer mehr mit Architektur und Projektplanung bis hin zu philosophischen Themen rund um die Softwareentwicklung.
Dein Interesse für neue Technologien?
Ich interessiere mich sehr für neue Technologien und versuche mich immer sofort mit eben diesen zu beschäftigen. Es ist spannend die Entwicklung zu beobachten und über zukünftige Möglichkeiten nachzudenken. Ob diese Technologie dann auch wirklich eingesetzt wird, kann ich in meiner beruflichen Position momentan leider nicht direkt bestimmen. Ich versuche deshalb Empfehlungen auszusprechen, die man allerdings nur treffen kann wenn man sich auch wirklich kritisch mit einer neuen Technologie auseinander gesetzt hat.
Engagierst du dich in der .NET Community?
Ich investiere sehr viel Zeit in die Community und habe durch diese schon sehr viele nette Menschen kennengelernt. Wie oben schon geschrieben verfasse ich regelmäßig Beiträge für meinen Weblog, arbeite als Moderator im myCSharp Forum, und versuche die vielen E-Mail Anfragen zu beantworten, die mich täglich erreichen. Vor kurzem habe ich außerdem mit Lars Keller und Karim El Jed eine Usergroup für den Raum Braunschweig gegründet. Jetzt versuche ich natürlich meinen Teil in Form von Vorträgen und kleinen organisatorischen Aufgaben dazu beizutragen.
Grundsätzlich geht es mir darum, interessierten Leuten den Einstieg in das .NET Framework (und insbesondere ASP.NET) so leicht wie möglich zu machen und sie ebenso zu begeistern. Deshalb orientieren sich meine Themen im Weblog besonders an den Fragen, die in Foren, Newsgroups und per E-Mail gestellt werden.
Dein Wunsch an die .NET Community?
Mir macht die Arbeit in der Community Spaß, so dass ich wenig zu bemängeln habe. Dennoch gibt es meiner Meinung nach zu viel Konkurrenzdenken. Hier und da sind die kleine Sticheleien oder Miesmacherei einfach fehl am Platz. Das Motto von myCSharp lautet "gemeinsam mehr erreichen". An genau diesem Motto sollte man sich orientieren.
Abschließend möchte ich mich bei Norbert für das Interview bedanken. Ich bin schon auf die nächsten Themen und Fragen gespannt. Themenvorschläge und Anregungen nehmen Norbert und ich natürlich gerne entgegen.
| | | Kommentar hinzufügen
| 1 Trackbacks
| Permalink | Trackback-URL |
Der Unterschied zwischen const und static readonly!
04.12.06 - .NET, Base Framework Beitrag von Norbert Eder| | const
Mit const definierte Werte werden mit der Kompilierung als Konstanten ausgewiesen und sind danach nicht mehr veränderbar.
static readonly
Diese "Markierung" erfolgt zur Laufzeit. Damit ausgekennzeichnete Werte können zur Laufzeit innerhalb der eigenen Klasse modifiziert werden.
static readonly wird hauptsächlich verwendet, wenn der gewünschte Typ nicht als const deklariert werden darf, oder wenn der Wert erst zur Laufzeit bekannt ist.
| | | 2 Kommentare
- 478 mal angesehen
| 0 Trackbacks
| Permalink | Trackback-URL |
Standard-Windows-Sounds abspielen
04.12.06 - .NET, Base Framework Beitrag von Norbert Eder| | Seit .NET 2.0 gibt es den Namespace System.Media und die Klassen SystemSound sowie SystemSounds. Damit ist es möglich, Standard-Windows-Sounds abzuspielen um den User auf bestimmte Ereignisse, Fehleingaben etc. hinzuweisen.
Der klassische Beep kann mit nachfolgendem Code abgespielt werden.
System.Media.SystemSounds.Beep.Play();
Natürlich stehen noch weitere Möglichkeiten zur Verfügung. Einfach mal die entsprechenden Klassen näher betrachten.
Zusätzliche Assemblies müssen hierzu nicht eingebunden werden.
| | | Kommentar hinzufügen
| 0 Trackbacks
| Permalink | Trackback-URL |
Meine GUI friert während der Ausführung ein, was tun?
04.12.06 - .NET, WPF Beitrag von Norbert Eder| | Ebenfalls eine oft gesehene Frage. Eine Aufgabe wird gerade ausgeführt und dabei friert die Oberfläche der Anwendung ein. Weder ein Fortschrittsbalken wird aktualisiert, noch ein Label, das den Fortschritt anzeigt. Ja selbst beim Verschieben der Form wird diese weiß und zeigt keine Informationen mehr an.
Der Hintergrund liegt einfach daran, dass durch eine ausgeführte Arbeit von dieser Form keine System-Message mehr angenommen wird bzw. diese nicht verarbeitet werden kann. Um dies zu vermeiden (und damit der Benutzer nicht irrtümlich annimmt, die Anwendung sei abgestürzt), bieten sich mehrere Lösungen an:
DoEvents
Durch ein Application.DoEvents() erhält die Anwendung die Möglichkeit, andere Events abzuhandeln und die Form neu zu zeichnen.
Threading
Aufwändige Aufgaben sollten in einem eigenen Thread ausgeführt werden. Dies kann über die Klassen des Namespaces System.Threading geschehen oder über einen BackgroundWorker. Hier ist jedoch zu beachten, dass von Threads nicht direkt auf die GUI-Elemente zugegriffen werden kann. Hierzu muss mit Invoke gearbeitet werden.
Wichtig: Locking
In manchen Fällen ist es wichtig, bestimmte Code-Teile mit einem lock (oder anderen entsprechenden Blockierungs-Maßnahmen) zu versehen. Dadurch kann der gleiche Code nur von einem einzigen Thread aufgerufen und ausgeführt werden. Dies kann mit einem DoEvents nicht ausreichend gelöst werden. In solchen Fällen sollte auf jeden Fall Threading verwendet werden.
| | | Kommentar hinzufügen
| 2 Trackbacks
| Permalink | Trackback-URL |
Die wohl häufigste Ausnahme: NullReferenceException
04.12.06 - .NET, Base Framework Beitrag von Norbert Eder| | Wer kennt sie nicht, die nachfolgenden Meldungen:
System.NullReferenceException: Object reference not set to an instance of an object
System.NullReferenceException: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt
Was ist passiert?
Es wurde versucht auf ein Objekt zuzugreifen, welches null ist. Im Gegensatz zu Wertetypen müssen Referenztypen instanziert werden. Erst dann kann ein Zugriff darauf stattfinden.
Beispiel
MyObject o = null;
o.CallMethod(); // NullReferenceException
Hier wurde das Objekt nicht instanziert und führt daher zu einer NullReferenceException.
MyObject o = new MyObject();
o.CallMethod(); // keine Exception
Da in diesem Beispiel das Objekt instanziert wurde, wird der Methoden-Aufruf ohne Exception ausgeführt.
Um eine NullReferenceException zu vermeiden macht es Sinn (Anm. d. Red.: Anglizismus-Jäger Markus hat zugeschlagen) ist es sinnvoll, vor dem Zugriff auf eine Objekt zu überprüfen ob es null ist. Ist dem nicht so, kann "weitergearbeitet" werden.
MyObject o = null;
if (o != null)
{
o.CallMethod();
}
Damit wird sichergestellt, dass der Code innerhalb der Bedingung nur ausgeführt wird, wenn das Objekt erfolgreich instanziert wurde. Und so ganz nebenbei fliegen dem Benutzer weit weniger Exceptions um die Ohren ;-)
Womit wir schon beim nächsten Thema wären (Danke Frank für den Hinweis): Exception-Handling. Natürlich muss nicht nur abgefragt werden, ob das Objekt null ist, sondern diese Tatsache ist auch entsprechend zu behandeln. So kann beispielsweise die restliche Aufgabe ohne dieses Objekt nicht korrekt ausgeführt werden. Im Falle eine if-Bedingung ist hier ein entsprechender else-Zweig notwendig. Besser eignet sich ein entsprechender try-catch-Block um diese Ausnahme zu behandeln. So ein Block könnte so aussehen:
MyObject o = null;
try
{
o.CallMethod();
}
catch (NullReferenceException nullException)
{
// Fehlerausgabe
// Sonstige Behandlungen
// Zurücksetzen des Workflows
// etc.
}
catch (Exception ex)
{
// eine andere Exception ist aufgetreten
// diese muss entsprechend behandlet werden
}
finally
{
// hier Code für Aufräumarbeiten
}
Vielen Dank an meine Leser für die Anmerkungen, die ich nun glatt in diesen Beitrag (der Vollständigkeit halber) einfließen ließ.
| | | 3 Kommentare
- 4915 mal angesehen
| 0 Trackbacks
| Permalink | Trackback-URL |
Zurück Weiter
|
|
|
|
|
|
|
