Autor Beitrag
IsNull
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic star
Beiträge: 97
Erhaltene Danke: 11


VS 2010, C#, AHK
BeitragVerfasst: Do 17.06.10 12:01 
Hallo,

Vorgeschichte:
Ich habe hier eine sehr grosse Access 2000 / VB6 Applikation - diese wird aktuell durch .NET (C#) dll's erweitert/ergänzt/ersetzt, Ziel wäre irgendwann, eine komplette Migration zu .NET.
Aktuell habe ich reine COM dlls, die auch einigermassen in VB6 *würg* funktionieren. Allerdings ist es absehbar, dass die gleichen DLLs bald auch von anderen .NET Projekten aufgerufen werden müssen - und da will ich eigentlich nicht über COM fahren.

Frage:
Daraus ergibt sich mir das Problem, dass ich C# Klassenbibliotheken einerseits als COM erstellen muss, andererseits auch als normale .NET Bibliotheken.

Muss ich zwei verschiedene Releases definieren, und diese dann in separate Release Ordner kompilieren? Wie geht man da am elegantesten vor?

Gruss
IsNull
Kha
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic star
Beiträge: 3803
Erhaltene Danke: 176

Arch Linux
Python, C, C++ (vim)
BeitragVerfasst: Do 17.06.10 19:43 
:welcome:

Soweit ich weiß, sind COM-registrierte Assemblies doch weiterhin ganz normale .NET-Assemblies?

_________________
>λ=
IsNull Threadstarter
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic star
Beiträge: 97
Erhaltene Danke: 11


VS 2010, C#, AHK
BeitragVerfasst: So 20.06.10 13:34 
user profile iconKha hat folgendes geschrieben Zum zitierten Posting springen:
:welcome:

Soweit ich weiß, sind COM-registrierte Assemblies doch weiterhin ganz normale .NET-Assemblies?

Danke für den Empfang :)
Diese DLL's sind zumindest nicht als .NET Libs sichtbar, wohl aber als COM - daher gehe ich davon aus, dass diese DLLs beim laden wie jede andere COM Dll behandelt werden - und somit unnötigerweise über den COM Server (in process server oder noch schlimmer als Local Server). Ich ging davon aus, dass dies Nachteile bringt - ich weis es aber nicht.
Ralf Jansen
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic star
Beiträge: 4708
Erhaltene Danke: 991


VS2010 Pro, VS2012 Pro, VS2013 Pro, VS2015 Pro, Delphi 7 Pro
BeitragVerfasst: So 20.06.10 15:12 
Zitat:
Diese DLL's sind zumindest nicht als .NET Libs sichtbar


Von wo nicht sichtbar :gruebel: Eine als COM Visible markierte Assembly sollte weiterhin genauso in .NET referenzierbar sein wie ohne diese Kennzeichnung.
IsNull Threadstarter
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic star
Beiträge: 97
Erhaltene Danke: 11


VS 2010, C#, AHK
BeitragVerfasst: So 20.06.10 16:28 
user profile iconRalf Jansen hat folgendes geschrieben Zum zitierten Posting springen:
Zitat:
Diese DLL's sind zumindest nicht als .NET Libs sichtbar


Von wo nicht sichtbar :gruebel: Eine als COM Visible markierte Assembly sollte weiterhin genauso in .NET referenzierbar sein wie ohne diese Kennzeichnung.


Ich hab wahrscheinlich zu kompliziert gedacht. Bei näherer Betrachtung der eingebundenen (COM sichtbaren) dll ist mir aufgefallen, dass bei derjenigen mit .NET erstellten gar keine Interfaces erzeugt werden müssen, diese also direkt angesprochen wird. Hat sich also erledigt, mir solls recht sein :)

Danke für eure Antworten.