.NET Blog   ·   .NET Casts   ·   .NET GUI Foren   ·   .NET BlogBook   ·   WPF Blogger   ·   visual studio one   ·   ASP.NET professional

  • 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.
Download .NET Essentials Installer
Trickkiste

Artikel: Techniken miteinander verbinden

17.03.08 - .NET, Grundlagen, Base Framework, WPF, Datenverwaltung
Beitrag von Norbert Eder
  Wie die Zeit vergeht. So habe ich doch glatt vergessen, meinen letzten Artikel in der visual studio one anzukündigen. Das Thema: Techniken miteinander verbinden.

Einzelne Technologien und Techniken sind oft schnell verinnerlicht und werden anfänglich für kleinere Projekte eingesetzt. Meist jedoch getrennt voneinander, um etwaige Fehlerquellen oder ›Blocker‹ zu minimieren. Dieser Artikel zeigt, wie LINQ mit der Windows Presentation Foundation zusammen spielt.

Der gesamte Artikel ist in der Ausgabe 02/08 der Zeitschrift visual studio one zu finden.

Eine Liste der von mir verfassten Artikel ist in der Rubrik Zeitschriften-Artikel zu finden.
  Kommentar hinzufügen   |  0 Trackbacks   |  Permalink  |  Trackback-URL


Mitschnitte vom Microsoft Launch Event

16.03.08 - .NET, Grundlagen, Base Framework, WPF, ASP.NET, Silverlight, Mobile Devices, Datenverwaltung, Visual Studio, Allerlei, SQL Server
Beitrag von Norbert Eder
 Unter dem nachfolgenden Link sind einige Livemitschnitte vom Lauchevent 2008 in Frankfurt zu finden. Zum Ansehen wird das Silverlight-Plugin benötigt.

Hier der Link: Mitschnitte Launch 2008

Und hier die Themen:

- Keynote
- Neu in Visual Studio 2008
- SQL Server 2008
- Überblick Windows Server 2008 Management
- Internet Information Server 7
- Virtualisieren mit dem Windows Server

Viel Spass beim Gucken.
  Kommentar hinzufügen   |  0 Trackbacks   |  Permalink  |  Trackback-URL


Aber mit Windows Forms bin ich doch viel schneller …

14.03.08 - Entwicklung, Diskussionen, Grundlagen, WPF
Beitrag von Norbert Eder
 Genau diese Aussage ist mir bei Diskussionen rund um die Windows Presentation Foundation immer wieder untergekommen. Gerade wenn es um kleine Anwendungen geht, wird immer noch hauptsächlich auf Windows Forms gesetzt. Hier kommen natürlich einige Punkte zu tragen, die ich schon an diversen Stellen aufgeführt habe:
  • Gewohnheit: Windows Forms kennt man und weiß sie auch einzusetzen. Probleme sind genauso bekannt wie die möglichen Umsetzungsvarianten. Der Umstieg zu einer deklarativen Form (obwohl das ja auch nur ein Teil der WPF ist) ist somit nicht einfach zu bewerkstelligen, zumal bei kleinen Anwendungen, Tools, Hilfen die Vorteile bei weitem nicht so klar auf der Hand liegen.
  • Es ist neu. Neues verursacht immer wieder Angst. Man weiß nicht, womit genau man’s zu tun hat, wie es reagiert, was man damit alles machen kann. Im ersten Schritt werden daher grundlegende Informationen besorgt, welche dann natürlich aber auch sehr schnell zeigen können, dass etwas eventuell aufwändiger ist, als man es bisher gewohnt war. In einigen Fällen (und hier zähle ich die WPF dazu) wirkt dies jedoch nur auf den ersten Blick so. Allerdings muss hier auch die Größe der Anwendung berücksichtigt werden.
  • Es ist anders. Ganz klar, es ist natürlich anders, weil es neu ist. Bei neuen Techniken werden oft neue (oder aufgewärmte) Wege gegangen. Im Falle der WPF handelt es sich dabei um den Einsatz einer deklarativen Programmierung, soweit es zumindest XAML betrifft. Dies mag auf den ersten Blick etwas aufwändig erscheinen, dennoch ermöglicht gerade dies ungeahnte Möglichkeiten in der Trennung zwischen Design und Logik.

Zusätzlich zu diesen Punkten wird oftmals der im Visual Studio integrierte WPF Designer (Cider) kritisiert. Es wird bemängelt, dass Oberflächen nun nicht mehr so einfach und schnell erstellt werden können, wie dies unter Windows Forms der Fall ist. Das ist grundsätzlich schon richtig. Für diese Fälle gibt es Tools á la Expression Blend (dazu kommen wir noch). Auch unterscheidet sich hier ein bestimmter Punkt ganz gewaltig: Gestaltungsfreiheit.

War ich unter den Windows Forms noch an die angebotenen Gestaltungsmöglichkeiten des entsprechenden Steuerelements gebunden, ist dies unter WPF großteils so nicht mehr der Fall. Durch die Möglichkeit, beliebige Steuerelemente ineinander zu verschachteln, kann ich als Designer/Entwickler gänzlich neue Steuerelemente erzeugen, ohne wirklich programmieren zu müssen. Unter den Windows Forms musste ich für eine eigene Konstellation eben mal schnell ableiten und meinen Wunsch implementieren. Aber auch dieses gilt wieder nur für größere Anwendungen, da hier dieser Fall wahrscheinlicher auftritt, als bei einem kleinen Tool, welches ich als Entwickler nur für mich selber zusammenstricke.

Ein häufiges Argument, welches ebenfalls oft angewandt wird: Expression Blend ist zwar toll, kostet aber auch entsprechend. Ein kurzer Blick auf eine Homepage die etwas mit kriegerischen Frauen zu tun hat, zeigt: Expression Blend schlägt mit über 500 Euronen zu Buche. Dies ist in der Tat ein Betrag, den sich ein Hobbyentwickler, oder jemand der OpenSource-Software entwickelt, kaum leisten kann, bzw. vielmehr will. Ist auch verständlich. Gehen wir hier also nicht von einem professionellen Rahmen aus (hier sollte dieser Betrag aufzutreiben sein), sondern wenden wir uns diesbezüglich den Hobbyentwicklern zu. Wo sind also die Alternativen. Ja, da gibt es den Aurora XAML Designer, der jedoch auch nicht kostenfrei ist (jedoch mit unter 200 Euro noch erträglich) und zudem auch nicht so wirklicht gut abschneidet (siehe Aurora XAML Designer Schnelltest).
Weitere Alternativen sind rar und oft finden sich nur kleinere Tools, die den einen oder anderen Schritt automatisieren oder vereinfachen. Hier muss also noch auf jeden Fall nachgebessert werden, denn der „kleine Entwickler“ muss sehr viel zu Fuß erledigen und verliert damit dann schon Zeit, die vielleicht besser in die Logik investiert wäre.

Es muss jedoch auch hinzugefügt werden, dass sich der Aufwand durchaus in Grenzen hält und man auch sehr schnell zu Ergebnissen kommt. Fakt ist jedoch, dass gewisse Schritte nicht gemacht werden wollen, wenn man ganz genau weiß, dass es grundsätzlich Tools gibt, die das viel schneller erledigen, oder es Alternativen gibt, die das auch für mich machen. Windows Forms eben. Und solange die Unterstützung auf diesem Gebiet nicht besser ist, wird sich WPF, vor allem in der großen Gemeinde, der „kleinen Entwickler“, nicht durchsetzen. Stattdessen werden weiterhin die Windows Forms zum Einsatz kommen. Da zählen die Vorteile die durch die WPF geboten werden, eigentlich nicht wirklich …

  6 Kommentare - 3990 mal angesehen   |  0 Trackbacks   |  Permalink  |  Trackback-URL


Undo und Redo implementieren

12.03.08 - Entwicklung, Diskussionen, Patterns, .NET, Grundlagen, Base Framework, WPF, ASP.NET
Beitrag von Norbert Eder
 Es kommt ja doch häufig vor, dass eine Anwendung ein Undo bzw. ein Redo unterstützen muss. Wird diese Funktionalität gefordert wird immer wieder nach einer Umsetzungsmöglichkeit gefragt. Hier eine kleine Lösung, die für diese Zwecke verwendet werden kann.

Hinweis: In diesem Beispiel werden keine Fehlerabfragen gemacht. Es empfiehlt sich, einen Ausführungsstatus zu integrieren, der das Verhalten entsprechend beeinflusst.

Design


Um diese Funktionalität umzusetzen, wird das Command-Pattern verwendet. Dieses eignet sich sehr gut dazu, Aktionen auszuführen und diese auch wieder zurück zu nehmen. Erweitert wird das Command-Pattern um einen CommandManager, der für die Ausführung und Verwaltung der einzelnen Commands zuständig ist.



Implementierung


Zuerst wird eine Basisklasse für den Command implementiert, welche die Methoden Execute(), Undo und Redo zur Verfügung stellt.

public abstract class Command
{
    public abstract void Execute();

    public abstract void Undo();

    public abstract void Redo();
}


Als weiteren Schritt wird der CommandManager implementiert. Dieser ist in diesem Fall ein Singleton (damit er nur einmal pro Instanz vorhanden sein kann) und bietet nach aussen hin die selbe Funktionalität wie ein Command an. Intern werden die einzelnen Commands jedoch in einem Stack behalten, um den Verlauf der einzelnen Commands nachvollziehen zu können. Darüber kann nun ein Undo bzw. ein Redo abgebildet werden.

public class CommandManager
{
    #region Static Attributes

    private static object _lockObject = new object();
    private static CommandManager _instance = null;

    #endregion Static Attributes

    #region Attributes

    private Stack<Command> _commandStack = new Stack<Command>();
    private Stack<Command> _undoneStack = new Stack<Command>();

    #endregion Attributes

    #region ctor

    private CommandManager() { }

    #endregion ctor

    #region Static Methods

    public static CommandManager GetInstance
    {
        get
        {
            if (_instance == null)
            {
                lock (_lockObject)
                {
                    _instance = new CommandManager();
                }
            }
            return _instance;
        }
    }

    #endregion Static Methods

    #region Public Methods

    public void Execute(Command command)
    {
        command.Execute();
        _commandStack.Push(command);
    }

    public void Redo()
    {
        Command redoCommand = _undoneStack.Pop();
        redoCommand.Redo();
        _commandStack.Push(redoCommand);
    }

    public void Undo()
    {
        Command undoCommand = _commandStack.Pop();
        undoCommand.Undo();
        _undoneStack.Push(undoCommand);
    }

    #endregion Public Methods
}


Damit ist die eigentliche Implementierung bereits abgeschlossen und wir können zu einem ersten Test schreiten. Hierzu benötigen wir ein paar kleinere Klassen, die nicht wirklich etwas aufregendes machen.

Hier eine Klasse Person, die zwei Eigenschaften zur Verfügung stellt, anhand derer getestet wird. Zudem implementiert sie das Interface ICloneable (wird im nachfolgenden Command benutzt) und überschreibt die ToString-Methode.

public class Person : ICloneable
{
    #region Properties

    public String Firstname { get; set; }
    public String Lastname { get; set; }

    #endregion Properties

    #region ICloneable Members

    public object Clone()
    {
        Person p = new Person();
        p.Firstname = this.Firstname;
        p.Lastname = this.Lastname;
        return p;
    }

    #endregion ICloneable Members

    #region Overrides

    public override string ToString()
    {
        return String.Format("{0}, {1}", Lastname, Firstname);
    }

    #endregion Overrides
}


Als nächsten Schritt müssen wir noch einen konkreten Command implementieren, der eine Aktion durchführt. Dieser wird sich lediglich ein wenig mit den Eigenschaften der Person spielen:

public class PersonCommand : Command
{
    private Person _person;
    private Person _personStateBefore;

    public PersonCommand(Person person)
    {
        _person = person;
    }

    public override void Execute()
    {
        _personStateBefore = _person.Clone() as Person;

        _person.Firstname = "Norbert";
        _person.Lastname = "Eder";
    }

    public override void Undo()
    {
        _person.Firstname = _personStateBefore.Firstname;
        _person.Lastname = _personStateBefore.Lastname;
    }

    public override void Redo()
    {
        Execute();
    }
}


Wichtig ist an dieser Stelle nur, dass sich der Command den ursprünglichen Status des übergebenen Objektes merkt und somit eine Undo bzw. Redo-Funktionalität anbieten kann.

Schlussendlich ein Stück Code, welches bei mir in einer Konsolen-Anwendung direkt in der static void Main ausgeführt wird:

CommandManager manager = CommandManager.GetInstance;

Person p = new Person();
p.Firstname = "<not set>";
p.Lastname = "<not set>";
Console.WriteLine(
    String.Format("Before first execution: " + p.ToString()));

manager.Execute(new PersonCommand(p));
Console.WriteLine(
    String.Format("After first execution : " + p.ToString()));

manager.Undo();
Console.WriteLine(
    String.Format("After undo            : " + p.ToString()));

manager.Redo();
Console.WriteLine(
    String.Format("After redo            : " + p.ToString()));

Console.Read();


Und nun möchte ich das Ergebnis nicht vorenthalten:



Fazit


Wie zu sehen ist, ist ein Undo bzw. Redo-Mechanismus sehr einfach zu implementieren. Abhängig der Umgebung in welcher diese Methode zu tragen kommt, müssen eventuell weitere Mechanismen eingefügt werden.
  9 Kommentare - 2585 mal angesehen   |  0 Trackbacks   |  Permalink  |  Trackback-URL


WPF: Performance messen und verbessern

08.03.08 - .NET, WPF
Beitrag von Norbert Eder
 Hier und hier habe ich ja bereits zum Thema WPF und Performance etwas geschrieben bzw. auf etwas hingewiesen.

Nun möchte ich auf den MSDN Artikel Performance Profiling Tools for WPF verweisen. Dieser Artikel beschäftigt sich mit WPFPerf aus dem Windows SDK und beschreibt die inkludierten 5 Performance Profiling Tools:

- Perforator
- Visual Profiler
- Working Set Analyzer
- Event Trace
- ETW Trace Viewer

Auf jeden Fall ein sehr hilfreicher Artikel, der eine gute Übersicht der Tools aus dem SDK bietet. Damit ist man durchaus in der Lage, sich mit Performancetests rund um WPF Applikationen zu beschäftigen.

  Kommentar hinzufügen   |  0 Trackbacks   |  Permalink  |  Trackback-URL


Februar 2008 im Rückblick

03.03.08 - .NET, Grundlagen, Base Framework, WPF, ASP.NET, Silverlight, Datenverwaltung, Visual Studio, Allerlei
Beitrag von Norbert Eder
 Mensch, die Zeit vergeht. Schon wieder ist ein Monat um und dieses Mal bin ich ja wirklich kaum zu neuen Einträgen gekommen. Das lag wohl an der vielen Arbeit die unbedingt erledigt werden wollte. Dennoch hier eine kleine Übersicht der wichtigsten Beiträge:

Design Patterns


Verhalten einer Anwendung per Konfiguration bzw. Laufzeit verändern

Windows Presentation Foundation


Über die Wichtigkeit der Windows Presentation Foundation
Image aus einem WPF-Control erzeugen

Windows Forms


PropertyGrid löst Event PropertyValueChanged bei Collections nicht aus

Sonstiges


Service-Oase Österreich - Internetprovider unleashed

  Kommentar hinzufügen   |  0 Trackbacks   |  Permalink  |  Trackback-URL


Verhalten einer Anwendung per Konfiguration bzw. Laufzeit verändern

27.02.08 - Entwicklung, Diskussionen, Patterns, .NET, Grundlagen
Beitrag von Norbert Eder
 

Abgrenzung


In diesem Artikel wird folgendes gezeigt:
  • Austauschen von Verhaltensweisen via Konfiguration als auch zur Laufzeit
  • Austauschen von einzelnen Methoden via Konfiguration als auch zur Laufzeit

Einführung


In vielen Fällen ist es notwendig, Verhaltensweisen über die Konfiguration oder per Laufzeit zu steuern. Als Beispiel: Nehmen wir eine Anwendung, die unterschiedliche Listen zur Verfügung stellt. Nun müssen die Daten für diese Listen geladen werden, damit sie angezeigt werden können. Unter der Annahme, dass alle Daten aus einer Datenbank kommen ist es kaum notwendig, dieses Verhalten zu verändern. Nun kann es aber sein, dass Inhalte für bestimmte Listen nicht aus der Datenbank kommen, sondern aus anderen Quellen. Das Standardverhalten würde nun nicht mehr funktionieren und muss daher ausgetauscht werden.
Ein weiterer häufig auftretender Punkt ist, dass zwar grundsätzlich das Standardverhalten verwendet werden soll, bis auf einen kleinen Teil, beispielsweise eine bestimmte Methode.

Strategy Pattern hilft bei Verhaltensänderungen


Da Verhaltensweisen getauscht werden können, liegt es nahe, sich im Bereich der Behavioral Patterns umzusehen. Darunter ist das Strategy-Pattern zu finden. Dieses ermöglicht, das gesamte Verhalten auszutauschen. Hier eine UML-Übersicht dieses Patterns:



Im Diagramm ist der Aufbau einfach zu erkennen. Grundsätzlich wird ein Interface IStrategy zur Verfügung gestellt. Dieses schreibt die Methode DoWork vor, welche dann die tatsächliche Aufgabe ausführt. Dieses Interface wird von zwei konkreten Klassen implementiert: ConcreteStrategy1 und ConcreteStrategy2. Beide Klassen besitzen also die Methode DoWork. Allerdings unterscheiden sich diese beiden Implementierungen voneinander, sprich das Verhalten ist ein unterschiedliches (sonst würde auch die Erstellung von zwei konkreten Klassen wenig sinnvoll sein). Schließlich gibt es noch einen StrategyContext. Dieser bekommt über den Konstruktor ein IStrategy übergeben. Dieses bestimmt nun das Verhalten. Die Aufrufe erfolgen über den StrategyContext, wodurch die Funktionalität aus dem übergebenen Strategy-Objekt aufgerufen wird. Eine Beispiel-Implementierung sieht so aus:
public interface IStrategy
{
    void DoWork();
}

public class ConcreteStrategy1 : IStrategy
{
    #region IStrategy Members

    public void DoWork()
    {
        Console.WriteLine("ConcreteStrategy1");
    }

    #endregion
}

public class ConcreteStrategy2 : IStrategy
{
    #region IStrategy Members

    public void DoWork()
    {
        Console.WriteLine("ConcreteStrategy2");
    }

    #endregion
}

public class StrategyContext
{
    private IStrategy _strategy;

    public StrategyContext(IStrategy strategy)
    {
        _strategy = strategy;
    }

    public void DoWork()
    {
        _strategy.DoWork();
    }
}

Der Aufruf des Konstruktes geschieht folgendermaßen:
class Program
{
    static void Main(string[] args)
    {
        StrategyContext context = new StrategyContext(new ConcreteStrategy1());
        context.DoWork();
    }
}

Austausch von einzelnen Methoden


Bisher haben wir gesehen, wie gesamte Verhaltensweisen ausgetauscht werden können. Wie sieht es jedoch aus, wenn nur einzelne Methoden getauscht werden und das restliche Verhalten gleich bleiben soll? Hier bietet sich ein Structural Pattern an, das Proxy Pattern. Dieses Pattern beschreibt einen möglichen Weg, wie Aufrufe an ein Ziel weitergeleitet werden können. Dies ist genau das was wir benötigen. Zuerst jedoch das UML Diagramm, um einen ersten Überblick zu erlagen:



Wie zu sehen ist, wird der StrategyContext gegen einen Proxy ersetzt. Dieser erhielt zusätzlich zur eigentlichen DoWork-Methode eine weitere Überladung, dem ein ICommand übergeben werden kann. Damit kann entweder das Standardverhalten (welches durch die konkrete Strategy-Implementierung vorgegeben wird) oder aber ein beliebiges eigenes Verhalten ausgeführt werden. Dies wirft natürlich die Frage auf, warum man nicht trotzdem ausschließlich mit dem Strategy-Pattern arbeiten kann. Der Einfachheit wegen hat dieses Beispiel nur eine einzige Methode, diese Variante kommt jedoch erst bei mehreren angebotenen Methoden zu tragen.
Hier eine Beispielimplementierung (IStrategy und die konkreten Implementierungen haben sich nicht geändert und sind im obigen Sourcecode zu finden):
public interface ICommand
{
    void Execute();
}

public class CustomWorker1 : ICommand
{
    #region ICommand Members

    public void Execute()
    {
        Console.WriteLine("CustomWorker1");
    }

    #endregion
}

public class CustomWorker2 : ICommand
{
    #region ICommand Members

    public void Execute()
    {
        Console.WriteLine("CustomWorker2");
    }

    #endregion
}

public class StrategyProxy
{
    private IStrategy _usedStrategy;

    public StrategyProxy(IStrategy usedStrategy)
    {
        _usedStrategy = usedStrategy;
    }

    public void DoWork()
    {
        _usedStrategy.DoWork();
    }

    public void DoWork(ICommand customWorker)
    {
        customWorker.Execute();
    }
}

Fazit


Dieser Beitrag hat gezeigt, wie gesamte Verhalten innerhalb einer Anwendung einfach ausgetauscht werden können bzw. einen Weg aufgezeigt, wie dies auf Basis von Methoden realisiert werden kann. Wer dies nun über eine Konfigurationsdatei konfigurieren möchte, der kann sich beispielsweise einen Builder basteln, welcher die Konfiguration ausliest und die darin angegebenen Typen mit Hilfe der Klasse Activator instanziert, den Proxy mit den notwendigen Instanzen füllt und ihn anschließend fertig konfiguriert zurück liefert.
  4 Kommentare - 1787 mal angesehen   |  0 Trackbacks   |  Permalink  |  Trackback-URL


Das schwierige Los eines Entwicklers

23.02.08 - Entwicklung, Diskussionen
Beitrag von Norbert Eder
 Jeder Softwareentwickler muss mal klein beginnen. Viele Fragen tun sich auf und oft ist es schwierig, den richtigen Startpunkt zu finden. Wer bereits seit Jahren erfolgreich Software entwickelt, um die Fallen weiß, Patterns kennt und sich auf die Erfahrung verlassen kann, verliert oft die Anfangsschwierigkeiten aus den Augen, mit denen ein „Neuling“ konfrontiert wird.

Durch meine Lektorentätigkeit wurde ich vor allem in den letzten Tagen wieder darauf aufmerksam gemacht, worin tatsächlich die Probleme liegen bzw. sehr wahrscheinlich. Paradigmen wie die objektorientierte Programmierung sehe ich hier gar nicht so als tragisch an. Vielmehr stellen die wirklich zahlreich verfügbaren Möglichkeiten Einsteiger vor ein Problem. Wie vor 10, 15 Jahren stehen auch heute noch Programmiersprachen im Vordergrund, obwohl sie eigentlich nur ein Werkzeug zur Verfügung stellen. Hinter diesen Werkzeugen lauern zahlreiche Techniken/Frameworks, die verwendet werden wollen. Egal, in welche Ecke man guckt, alles und jeder verspricht, dass es damit noch viel viel einfacher geht. Um welchen Preis? Genau, man muss schon teilweise recht hart arbeiten, um am Laufenden zu bleiben. Ganz davon zu schweigen, dass man auch wirklich alles kennen und können kann. Nicht bei dieser Vielfältigkeit. Dass dabei Einsteiger den Überblick verlieren und den Wald vor lauter Bäumen nicht mehr sehen kann nicht verwundern.

Früher hat es gereicht, die CPU mitsamt der ALU und allem was sonst noch so dazu gehört zu kennen und ein paar Register (es mussten nur die richtigen sein) zu schupfen und schon konnte man sein Ergebnis (das was davor lag, lasse ich nun einfach einmal weg). Die Programmiersprache als solches war also auf ein Minimum ausgelegt und konnte so auch einfach benutzt werden. Heute hat ein Neuling schon viel zu tun, um überhaupt alle Möglichkeiten der Sprache zu lernen, mal abgesehen vom dahinterliegenden Framework bzw. den sonstigen verfügbaren Bibliotheken. Hier wundere ich mich ja selbst, wie man das denn selber alles immer irgendwie unter einen Hut bekommt.

Zusätzlich zur Thematik Programmiersprache/Framework kommt noch hinzu, dass ein heutiger Entwickler keineswegs mehr im dunklen Kämmerlein sitzt, sondern durchaus auch soziale Kompetenz mitbringen muss. Der Kunde möchte gut aufgehoben sein und dazu ist Kontakt einfach notwendig (verständlicherweise). Was genau resultiert daraus? Genau! Es bleibt nicht bei der Forderung nach sozialer Kompetenz, sondern der Softwareentwickler sollte sich grundsätzlich in sämtlich angesprochenen Bereichen auskennen. Dies können diverse Prozesse im Unternehmen des Kunden sein, das kann die Branche betreffen, in der sich der Kunde bewegt, betrifft jedoch auch die speziellen Technologie-Wünsche. Nicht oft kommt es vor, dass ein bestimmtes DBMS verwendet werden muss, der Datenaustausch zwischen Client und Server muss via XML passieren und schließlich möchte der Kunde auch noch die Oberfläche selbst anpassen können, wo wir dann wieder bei unterschiedlichsten Bereichen angekommen wären: Für Web hätten wir dann beispielsweise CSS, oder XAML für WPF Windows Anwendungen. Reporting darf auch nicht fehlen, wodurch dann Kenntnisse in XSLT recht hilfreich sind und schlussendlich sollen bestimmte Dokumente als XPS geschrieben werden. Dieses Spielchen könnte man nun schon ziemlich lange spielen.

Jetzt ist die IT Branche aber durchaus noch als eine junge Branche anzusehen, dennoch muss man feststellen, dass sie wohl vielseitiger kaum sein könnte. Rechnen wir noch mal 10 Jahre hinzu, dann möchte ich gar nicht wissen, welche neuen Techniken und Technologien bis dahin zusätzlich Einzug gehalten haben und über welche der heutigen man noch durchaus Know-How mitbringen muss. Ich denke … es wird nicht einfacher für uns und auch nicht für diejenigen, die in diese Branche einsteigen möchten …
  5 Kommentare - 1141 mal angesehen   |  0 Trackbacks   |  Permalink  |  Trackback-URL


Microsoft hat es auch nicht leicht die Tage ...

20.02.08 - Internet, Community, Kunterbunt
Beitrag von Norbert Eder
 Also nicht nur, dass Yahoo irgendwie nicht so recht will, dann auch noch ein ganz hochoffizieller Red Ring of Death (RRoD) auf der 2008 Game Developers Conference und schließlich auch noch das Aus für HD-DVD.

Daher bin ich jetzt grundsätzlich mal sehr froh, doch zu einer PS3 gegriffen zu haben, was vermutlich auch viele andere tun werden. Abgesehen davon, dass dein HD-DVD-Laufwerk bei der 360er per default gar nicht dabei ist. Das läßt aber durchaus auch vermuten, dass hier hauptsächlich auf Downloads gesetzt wurde und weniger auf HD-DVD selbst. Genau das wird wohl auch ein größerer Schlag in die Magengrube Toshiba's gewesen sein, die ja teilweise mit Dumping-Preise in den US-Markt gegangen sind und nun ihr Format zu Grabe tragen können. Schade eigentlich, gefällt mir grundsätzlich BD+ ja nicht besonders.

Bezüglich des RRoDs fällt mir auch noch etwas ein: Betrachtet man die Bilder unter dem angegebenen Link, dann dürften die Bedingungen für die dortigen XBoxen auch nicht unbedingt den Idealbedingungen für elektronische Geräte entsprechen ... da wird wohl jemand gewaltig eine auf's Dach bekommen haben ...
  Kommentar hinzufügen   |  0 Trackbacks   |  Permalink  |  Trackback-URL


Unable to find manifest signing certificate in the certificate store

14.02.08 - .NET, Visual Studio, Allerlei
Beitrag von Norbert Eder
 Heute bekam ich diese Meldung und wusste im ersten Moment auch nicht so ganz genau, was es damit auf sich hat. Hier nun die Aufklärung:

Gegeben ist ein Projekt, welches über einen TFS verwaltet wird. Für dieses Projekt wurde ClickOnce aktiviert und somit die ClickOnce Manifests signiert. Dafür wurde ein temporärer Key (pfx) angelegt, welcher nicht eingecheckt wurde. Daraus resultiert nun dieser Fehler. ABER:

In den Projekteigenschaften kann nun in der Lasche Sign der Haken von Sign the ClickOnce manifests entfernt werden, was jedoch dieses "Problem" nicht behebt. Der Fehler erscheint weiterhin. Um diesen Fehler los zu werden, muss manuell die Projekt-Datei (csproj, vbproj, etc.) geöffnet werden, um folgende Tags zu entfernen:
<ManifestCertificateThumbprint>
<ManifestKeyFile>
<GenerateManifests>
<SignManifests>

Nun das Projekt bzw. die Solution neu laden und es kann wieder gebuildet werden.

Daher:
  • Derartige Änderungen an einem Projekt unbedingt mit den Kollegen absprechen
  • Key-Dateien ins Source Control einchecken
  • Bei einem Test nichts einchecken

  2 Kommentare - 3510 mal angesehen   |  0 Trackbacks   |  Permalink  |  Trackback-URL



Zurück Weiter