| 

.NET C# Java Javascript Exception

1
Hallo,



[... sorry habe Grund das zu löschen]


Danke vorab
News:
17.02.2011
Maria Simlinger 1,1k 1 9
5 Antworten
1
Disclaimer: mit VB kenne ich mich nicht aus. Kann also nur eine High-Level-Meinung dazu abgeben.

Aber ich würde da auch nabuchodonossor zustimmen und nicht in Panik verfallen. Die System.Enum-Klasse enthält auch in .NET 4.0 noch ToString-Methoden, die schon in .NET 2.0 als veraltet markiert waren. Ganz sicher wird da nichts mit dem nächsten Service Pack verschwinden, und wann wird Eure Anwendung auf das nächste .NET-Release umgestellt?

Der Schwenk von 32bit auf 64bit, den Du andeutest, könnte da schon eher kommen, aber sicher auch nicht nächsten Monat, oder?

Ich würde erst mal den Versions-Upgrade vollziehen, ohne die Compatibility-Themen anzugehen. Die könnt ihr vielleicht nach und nach mit in die Sprints einplanen? Am Anfang könnt ihr die Compiler-Warnungen ja auch erst mal ausblenden. (mit #pragma disable oder in den Projekteinstellungen)

Ansonsten ist mir die Trennung von Code mit fachlichem und technichem Schwerpunkt so in Fleisch und Blut übergegangen, dass ich auch bei der Sprint-Planung eher dazu tendieren würde, nicht gleichzeitig den Upgrade und neue fachliche Funktionen einzuplanen.
17.02.2011
Matthias Hlawatsch 13,2k 4 9
Ja, die Trennung in fachlichen und technischen Sprint wäre auch aus meiner Sicht am sinnvollsten. Leider lässt sich so etwas unter Umständen "organisatorisch" nicht durchsetzen: Warum gibt es eine neue Version wenn sich nichts ändert? *seufz*
Maria Simlinger 17.02.2011
Tja, das leidige "Verkaufen"... Vielleicht findet ihr ja etwas in den .NET-4-Neuerungen, was Eurer Anwendung ohne großen eigenen Aufwand hilft und sich als Nutzen darstellen läßt? Oder gibt es noch andere technische Baustellen oder nicht-funktionale Anforderungen, für die jetzt ein guter Zeitpunkt wäre?
Matthias Hlawatsch 17.02.2011
Es sind ja nicht alle Projekte der Solution davon betroffen. Aber die älteren strotzen nur so von VB6 Konstrukten. Wahrscheinlich ist es am besten, diese schrittweise auszumerzen, wenn eines der Projekte von fachlichen Änderungen betroffen ist und den Rest dann mal so "mitzunehmen". Ein Problem ist ja auch der Regressionstest, der für die jeweils geänderten Teile stattzufinden hat.
Maria Simlinger 17.02.2011
Bitte stell mal ein Beispiel für so ein "VB6" Konstrukt rein, bin neugierig.
nabuchodonossor 17.02.2011
@nabuchodonossor, ich verstehe die Frage nicht, umso weniger als du ja bereits als Experte auf meine Frage geantwortet hast. Aber bitte: DateDiff (Intervall, Date1, Date2, [FirstDayOfWeek, [FirstWeekOfYear]] )
Maria Simlinger 17.02.2011
Da Du mich bei meiner Ehre als Experte genommen hast, siehe neue Antwort unten *g*
nabuchodonossor 17.02.2011
1
Hi,

ach schön, das leidige Thema VB 6 Anwendungsmigration / Portierung nach .NET.
Grundsätzlich denke ich auch nicht, dass die Funktionen "abgeschaltet" werden.

Was wird denn aus dem Microsoft.VisualBasic.Compatibility-Namespace eingebunden?

Sind die technischen Vorraussetzungen gegeben bzw. wäre/ist es denn möglich,
während fachlichen Implementierungen so einen Technikumschwung zu machen?

Ich würde auch als erste Option einen technischen Sprint einlegen.

Reicht denn nicht als Argument, dass VB 6 nun seit 3 Jahren nicht mehr supported wird?
Man auf dieser Technik basiert Altlasten mitschleppt?
Erklärung zum Support von Visual Basic 6.0 unter Windows® Vista™ und Windows® Server 2008

Kann man nicht mit einer besseren Wartbarkeit und einem konsistenterem Zustand des Gesamtsystems argumentieren?
Würde vielleicht eine sauberere und stabilere Architektur entstehen?
17.02.2011
KHoffmann 939 7
Es wird so ziemlich alles verwendet was VB6 "zu bieten" hatte. CInt(), CStr(), Cwasweißichnoch, Date Funktionen, ...

Ich denke das wird noch ein größeres Thema werden.
Maria Simlinger 17.02.2011
1
Halt uns mal auf dem Laufenden, ein spannendes Thema.
KHoffmann 18.02.2011
0
Ohne seherische Fähigkeiten mein Eigen zu nenen würde ich meinen, dass als "obsolete" gekennzeichnete Funktionen in 4.0 noch lange (eher sogar noch sehr lange) verfügbar sein werden (zumindest wird 4.0 nicht gleich verschwinden, ich verweise nur auf die Lebensdauer von 1.1er Framework ....)
17.02.2011
nabuchodonossor 1,3k 5
Ja, Seher ist keiner von uns, aber unter 64 bit werden diese Funktionen nicht mehr unterstützt!
Maria Simlinger 17.02.2011
Das mit 64bit ist mir nicht ins Aug gesprungen.
nabuchodonossor 17.02.2011
0
Den Rest überlasse ich Deiner Kreativität:

private int DateDiff(string interval, DateTime date1, DateTime date2)
{
int _result = 0;
TimeSpan ts = date2 - date1;

switch (interval)
{
case "d":
_result = ts.Days;
break;
case "h":
_result = (ts.Days * 24) + ts.Hours;
break;
default:
break;
}

return _result;
}


Und hier - falls wie bei mir die VB6 Hilfe nicht mehr geht - ist der Rest der DateDiff Funktion beschrieben

Und so würde ich dieses Problem auch angehen: Funktion um Funktion in einer eigenen Klasse (vielleicht sogar wo sinnvoll als Extensions) schreiben und verwenden. Und eines Tages ist dann nichts mehr übrig von der Compi Klasse.
17.02.2011
nabuchodonossor 1,3k 5
Bitte verstehe mich nicht falsch, das Problem ist nicht, dass man es nicht umsetzen kann. Es sind nur über 130.000 Lines Of Code. Btw. ich würde auch nicht jede VB6 Funktion nachbilden, sondern durch .NET Äquivalente ablösen. Grüße maria
Maria Simlinger 17.02.2011
0
Danke an alle, die hier mitgeholfen haben.

[... gleicher Grund wie bei Frage]

Danke nochmals an alle
17.02.2011
Maria Simlinger 1,1k 1 9

Stelle deine .net-Frage jetzt!