MS.NET-Framework Versionen mischen

[Schrammel]

Hallo zusammen,

ich probiere gerade eben mit dem .NET-Framework 2.0 herum. Dabei stelle ich fest, dass dem Entwickler was GUI-Features angeht dabei mehr geboten wird, als bei Version 1.1 .

ich möchte aber für die Modellierung meiner Business-Rules weiter auf das ECO-Framework zugreifen.

Jetzt habe ich folgende Idee: eigentlich müsste es möglich sein, meine ECO-Objekte hinter einem ASP.NET WebService oder hinter einer .NET-Automatisierungsschnittstelle zu verstecken, auf die ich mit dem .NEt 2.0 Programm zugreife.

Geht das? Hat das schon mal jemand probiert?

Über Hinweise wäre ich sehr dankbar!

Schrammel

[Lemmy1]

Ist eigentlich noch einfacher. Mach mit .Net 1.1 eine DLL und verwende sie in 2.0. Bis auf ganz ganz wenige Ausnahmen klappt das einwandfrei.

[Schrammel]

Das ist eine Idee, auf die ich bisher noch nicht gekommen bin. Das Einfache liegt so nahe. Ich werd's später mal ausprobieren und berichten, ob' geklappt hat.

Danke für die schnelle Antwort.

Gruß

Schrammel

[Elvis]

Zitat von Lemmy1:

Ist eigentlich noch einfacher. Mach mit .Net 1.1 eine DLL und verwende sie in 2.0. Bis auf ganz ganz wenige Ausnahmen klappt das einwandfrei.

Richtig, er könnte genauso gut die source files als Link in ein VS2005 Projekt ziehen und dort direkt gegen 2.0 kompilieren.
Auf die Art merkt man gleich wenn etwas nicht mehr da ist wo es sein sollte.

edit: picasso text

[Lemmy1]

Zitat von Elvis:

Zitat von Lemmy1:

Ist eigentlich noch einfacher. Mach mit .Net 1.1 eine DLL und verwende sie in 2.0. Bis auf ganz ganz wenige Ausnahmen klappt das einwandfrei.

Richtig, er könnte genauso gut die source files als Link in ein VS2005 Projekt ziehen und dort direkt gegen 2.0 kompilieren.
Auf die Art merkt man gleich wenn etwas nicht mehr da ist wo es sein sollte.

edit: picasso text

Hrm aber so kann man doch keinen Delphi Code kompilieren...? C# 1.1 Code könnte so natürlich klappen aber dann muss man halt immer manuell die Files in die Solution einfügen/rausnehmen...

[Elvis]

Zitat von Lemmy1:

Hrm aber so kann man doch keinen Delphi Code kompilieren...?

Ich dachte er hat ECO/C# genommen?

Zitat:

C# 1.1 Code könnte so natürlich klappen aber dann muss man halt immer manuell die Files in die Solution einfügen/rausnehmen...

Nope, Add->Add as Link (der Button im OpenFileDialog im VS ist ein DropDown )

[Lemmy1]

Zitat von Elvis:

Ich dachte er hat ECO/C# genommen?

Yep hast Recht, wer lesen kann ist klar im Vorteil

Zitat von Elvis:

Nope, Add->Add as Link (der Button im OpenFileDialog im VS ist ein DropDown )

Schon, aber man muss alle Änderungen im Filesystem mühsam nachpflegen (umbenennen, neue Dateien etc)

[Elvis]

Zitat von Lemmy1:

Schon, aber man muss alle Änderungen im Filesystem mühsam nachpflegen (umbenennen, neue Dateien etc)

Ich habe vor Jahren mit ECO/Delphi8 gearbeitet, damals hat er nur wenige (eine?) Datei pro ECO Package angelegt. Code generatoren sollten IMHO sowieso nicht soviele Dateien erzeugen. Muss ja keiner direkt lesen können, nur benutzen. Da überwiegt dann der Vorteil von wenigen Dateien.

[Schrammel]

Hallo zusammen,

zu allerest möchte ich mich bei all denen bedanken, die hier mitdiskutiert haben und mir Tipps zum ausprobieren gegeben haben.

Vor allem der Tipp von Daniel war Gold wert. Das ist die Richtung, in die ich gehe.

So, nun das Feedback. Um den Tipp auszuprobieren bin ich folgendermaßen vorgegangen:

1) Ich habe mir ein einfaches Beispiel gesucht: Den gibt's hier
Das Projekt besteht aus 3 Teilen: DLL mit den Klassen, die später 'fernbedient' werden sollen, dem Server und dem Client
3) Öffnen des DLL-Projekts (RemotableObjects.dll) mir BDS 2006 und Compilieren mit dem Framework 1.1
4) Compilieren des Server-Projektes (RServer). Hierzu muss die Referenz auf die RemotableObjects.dll aktualisiert werden
5) Der Server ist fertig. Das BDS 2006 kann geschlossen werden
6) Öffnen des DLL-Projekte (RemotableObjects.dll) mir VS 2005 und Compilieren mit dem Framework 2.0 (Die Ausgabe erfolgt in ein anderes Verzeichnis als bei lfd. Nr. 3))
7) Compilieren des Client mit VS 2005 (RCLient). Auch hierzu muss die Referenz auf RemotableObjects.dll aktualisiert werden. Achtung diese befindet sich nicht in bin\debug, sondern obj\debug
8) Starten des Servers
9) Starten des Clients
10) Es läuft

Vielleicht ist der Schritt, in den Client und in der Server unterschiedlich gelinkte RemotableObjects.dll einzubauen etwas mutig, aber in diesem einfachen Beispiel hat's geklappt.

Mal schauen, wie es weiter geht!


Gruß

Stefan