Hallo,

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

Danke vorab

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.

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?

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 ....)

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.