Anmelden
Ich möchte für die nächsten 30 Tagen angemeldet bleiben
Deutsch
Several pages in the usergroup are available in English. Click on english to visit these pages.
Druckerfreundlich DNN in komplett in C#
Sortieren:
Vorheriger BeitragVorheriger Beitrag Nächster BeitragNächster Beitrag
Sie sind nicht autorisiert, um eine Antwort zu erstellen.
Autor Nachrichten
Object reference not set to an instance of an object.
Andreas DeckeBenutzer ist Offline
Beiträge: 199
Basic Member


--
28 Mai 2010 10:02
Hallo,

nachdem ich doch nach den letzten Updates (5.4.1, 5.4.2) etwas frustriert war (Problem mit CBO.FillCollection und int? bzw. dem RadEditorProvider,
oder dem ControlPanel od. dem Logon od. ModuleCommunication) findet sich jetzt auf Codeplex ein DNN in Full-C#.

Werde es noch heute mal testen.

ForumDNN
CodePlex

gruss Andreas
Grüße aus Bonn
Andreas Decke
Thomas K.Benutzer ist Offline
Beiträge: 62
New Member


--
28 Mai 2010 11:17
Huhu Zusammen,

hmm besonderst viel halte ich von diesem Projekt nicht, zumindest nicht zu dieser Zeit. Die Unterschiede zwischen VB.NET und C# verschwimmen immer weiter mit jedem .NET-Release und liegen heute fast nur noch in der Syntax. Beide Programmiersprachen können durch .NET wunderbar und ohne Probleme innerhalb eines Projektes koexistieren. Ich sehe also keinen akuten Bedarf.

Zudem sehe ich den Zeitpunkt für Initierung dieses Forks als völlig falsch an. Zunächst einmal sollten die vorhandenen Ressourcen genutzt werden um das bestehende 5er Release zu stabilisieren und das Qualitätsmanagement zu verbessern. Die Defiziete hier liegen nicht in der gewählten Programmiersprach VB.NET. Und warum sollte die 5er Core-Version in C# in diesem Stadium stabiler sein oder in naher Zukunft werden?
Meiner Meinung nach macht die DotNetNuke Coorp. derzeit zu viele Baustellen auf ...

Nur meine Meinung ... die kommt aber auch noch in das ofizielle Forum :)

lG
Thomas K.

Christoph HeroldBenutzer ist Offline
Beiträge: 623
Advanced Member


--
29 Mai 2010 00:42
Wenn ich das richtig verstanden habe, arbeitet da vom Core-Team eh nur eine einzige Person mit, von daher dürfte das nicht allzu viel Manpower binden. Das ist eher eine Sache des einen Freiwilligen, der das maßgeblich in der Hand hat.
Gruß aus Dormagen
Christoph Herold
HeroldIT
Thomas K.Benutzer ist Offline
Beiträge: 62
New Member


--
29 Mai 2010 10:00

Hallo Christoph,

danke für deinen Hinweis, das Statement von Joe Brinkmann hatte ich dazu gar nicht gelesen. Du hast recht, das Projekt dnnc wurde und wird von einem einzelnen Community-Mitglied gestartet und gepflegt. Wie es scheint wurde die Konvertierung zum größten Teil automatisiert vorgenommen. Die Version 5.4.2 der C#-Variante war nach ca. 24 Stunden fertig.

Damit dürfte es sich in dem Projekt dnnc um eine reine Konvertierung von vb.net in c# handeln, mit allen logischen Fehlern :) und nicht um eine parallele Entwicklung. 

Damit ziehe ich meinen oben geschriebenen Kommentar zurück.

lg

Thomas K.

Andreas DeckeBenutzer ist Offline
Beiträge: 199
Basic Member


--
31 Mai 2010 09:31
Hallo Michael,

erstmal hoffe ich für Dich das Paris spass gemacht hat.

Ich habe die C# Version getestet, und kann sagen das sie alle Bugs übernommen hat.
Teilweise sind diese Bugs wohl in der Version 5.4.3 gefixt.

Ich weiss nicht wie es anderen Entwicklern geht, aber wir haben für ein Projekt voll auf DNN gesetzt.
Das Projekt läuft jetzt seit einem Jahr und soll Ende August zum Abschluss kommen.
Wir haben unsere BLL und DAL mit MyGeneration erstellt (unser BO besteht z.Z. aus ca. 370 Files) und
verwenden eben CBO.

Bis Version 5.3.1 hat auch alles reibungslos funktioniert (mal abgesehen von anderen Problemen).
Wir verwenden in unseren InfoClasses eben so etwas wie int? oder double? weil diverse Controls eben
einen null und kein -1 od. 0 (siehe SetNull) erwarten.

Auch der Weg über IHydratable funktioniert nicht richtig. Die Fill-Methode holt den IDataReader über die CBO
(ich glaube FillDataReaderObject), es werden zwar keine Fehler in der GUI angezeigt, aber das Log ist voll
von GetOrdinal(..) Exceptions. Das ist zwar nicht so tragisch, aber in unseren Fall werden die Daten (ca. 1000 Records)
in einen Tree geladen, d.h. ich habe im Log 1000 Exceptions stehen (ps: die Felder sind auch vorhanden :-)).

Ich denke hier wäre es doch wesentlich einfacher, die CBO glatt zu ziehen als das Framework zu umschiffen und eine
eigene Logik zu implementieren. Es ist ja alles da, es funktioniert nur nicht richtig.

gruss Andreas
Grüße aus Bonn
Andreas Decke
Sie sind nicht autorisiert, um eine Antwort zu erstellen.

Active Forums 4.2
NOT LICENSED FOR PRODUCTION USE
www.activemodules.com