[.NET/COM+/MTS]DLL in onder MTS

[Scare360]

Ik heb een voormalige VB 6.0 COM DLL geport naar VB.NET alleen nu kan ik mijn nieuwe DLL niet in MTS toevoegen. Dit gaat met de oude VB 6.0 DLL zonder problemen. Hoe kan dat?

De volgende melding krijg ik van de MTS...:

"One or more files do not contain components or type libraries. These files cannot be installed."

Is er een instelling die ik in VS.NET over het hoofd zie bij het builden?

[Verwijderd]

VB.NET is niet native win32, maar heeft .NET als target. Je hebt dan ook geen COM components in je VB.net dll maar assemblies die draaien op het .NET platform. Aangezien .NET zelf transactions regelt dmv contexts en attributes, heb je geen MTS nodig voor je vb.net assemblies.

[gotcha]

is niet waar. .NET heeft voorlopig nog wel component services nodig voor transacties. pas in de volgende release van het .NET framework hoopt microsoft transacties e.d. te hebben gerealiseerd in 100% .NET code.
voor nu: als je .NET DLL's in MTS wilt draaien moet je er een serviced component van maken; dwz dat het component zich kan gedragen als een COM+ DLL. ik geloof dat dit mijn Visual studio vrij eenvoudig aan te geven is bij de project properties, voor de diehards kan het ook met wat commandprompt tools.

nadeel van deze methode; doordat je de DLL ook als COM+ component registreert ben je nogal wat voordelen van .NET kwijt (je hebt alle DLL-hell problemen weer terug )
gebruik dus alleen MTS componenten als je ze echt nodig hebt

[Poiter]

Je kunt inderdaad in .NET een component maken die in COM+ draait als je deze van het type ServicedComponent maakt. (Heb je EnterpriseServices voor nodig in je solution). Vervolgens zul je ook nog een StrongName aan moeten maken voor de registratie van het component. Verder ondersteunt ADO.NET wel transacties, maar die moet je dus zelf regelen. Redenen om een component dus nog in COM+ te laten draaien is de automatische transactie afhandeling(MTS), en instance pooling (en eventueel aanroep vanuit oude programmeertalen).

Het component dat in COM+ komt te draaien is wel een echt .NET component, dus wel managed code.

[Scare360]

Uhm ja we zitten op dezelfde lijn alleen mijn probleem is nog niet beantwoord. Ik weet dat je gewoon COM/COM+ kunt gebruiken en je tevens van de .NET services gebruik kunt maken. Ik ga zeker geen .NET services gebruiken vanwegen het gebruik van MTS. Ik heb dus een huidige applicatie geport naar .NET alleen de COM/COM+ wil niet...

Als ik een DLL port weet .NET niet dat dit component als MTS object gebruikt gaat worden. Als ik probeer de DLL in de MTS te laden geeft ie dsu bovenstaande foutmelding.

Hoe dat te fixen?


Dus:
VB 6.0 COM DLL -> .NET DLL -> toevoegen aan MTS -> levert foutmeldingen op zoals hierboven beschreven in mijn eerste post.

[Verwijderd]

Op maandag 25 februari 2002 20:59 schreef gotcha het volgende:
is niet waar. .NET heeft voorlopig nog wel component services nodig voor transacties. pas in de volgende release van het .NET framework hoopt microsoft transacties e.d. te hebben gerealiseerd in 100% .NET code.
voor nu: als je .NET DLL's in MTS wilt draaien moet je er een serviced component van maken; dwz dat het component zich kan gedragen als een COM+ DLL. ik geloof dat dit mijn Visual studio vrij eenvoudig aan te geven is bij de project properties, voor de diehards kan het ook met wat commandprompt tools.

Hmm de docs roepen idd over component services crap. MTS kan overigens niet altijd, want ASP.NET is bv niet supported op NT4.

nadeel van deze methode; doordat je de DLL ook als COM+ component registreert ben je nogal wat voordelen van .NET kwijt (je hebt alle DLL-hell problemen weer terug )
gebruik dus alleen MTS componenten als je ze echt nodig hebt

Idd . Nu zijn transactions voor het leeuwendeel op databases, en dan kun je goed de ADO.NET transactions gebruiken, waardoor je die COM+ crap omzeilt. Toch wel jammer. Ik zat in Programming C# te lezen en had net een stuk gewauwel over transactions blabla doorgenomen en dacht dat het allemaal goed was opgelost.. dus niet.

[Verwijderd]

Op maandag 25 februari 2002 21:54 schreef paulgielens het volgende:
Dus:
VB 6.0 COM DLL -> .NET DLL -> toevoegen aan MTS -> levert foutmeldingen op zoals hierboven beschreven in mijn eerste post.

Ok, ik voeg mn VB6 COM dlls ook aan MTS toe, want dat is makkelijker onderhouden, maar als je pure database transactions gebruikt, dan kun je ook de connection object (ADO) transactions gebruiken, en heb je MTS niet nodig.

[Verwijderd]

Zoek dit artikel op in de .net docs:
Automatic Transactions and .NET Framework Classes

Er staat een voorbeeld bij plus de punten waar je class aan moet voldoen. (o.a. welke baseclass, welke attributes etc).

Geeft wellicht meer inzicht.

Ik weet overigens niet of DLL-Hell wel terug is met dit systeem, daar de CLR de class managed en niet de COM+ core, maw: ik betwijfel of je services moet stoppen/starten om dll's te updaten at runtime.

[Scare360]

Imports System.EnterpriseService.ServicedComponents

Probleem is ik heb misschien wel 150.000 regels code die normaal als COM objecten in MTS draaien.Om alles volledig te kunnen porten zou het wel lekker zijn dat VS.NET middels die wizzard ook meteen door heeft dat het een COM DLL betreft. Nu na de upgrade krijg ik de DLL gecompiled alleen kan ik hem niet aan de MTS voeren, omdat die zegt dat het geen COM/COM+ Component is (verpakt in een DLL)

De optie "niet met MTS te werken" komt helemaal te vervallen...MTS wordt gebruikt, dus weet iemand de oplossing om zonder al te veel werk die zaak aan de gang te krijgen?

Iemand al praktijk ervaring emt porten van COM/COM+ componenten die men onder MTS laat draaien?

Huidige situatie:
VB 6.0, MTS, MS SQLServer 7.0, 3-Tier Architectuur middels COM/COM+

Bedankt voor de hulp (en dat MSDN artikel nat)

[GBits]

Werk jij soms voor een 3 letterig software huis?

[Scare360]

Op dinsdag 26 februari 2002 08:47 schreef Lecram het volgende:
Werk jij soms voor een 3 letterig software huis?

Softwarehuis, je zou die grijns op m'n gezicht moeten zien

[Verwijderd]

Paul: maar, waarom wil je die 150.000 regels code porten, als je het toch in MTS wilt draaien? Ik zou die handel alleen porten als de logica in .NET interessant was, maar dan zou ik het porten naar een specifieke .NET applicatie, dus bv ombouwen tot een webservice. Je bent nu werk aan het verrichten wat netto niets oplevert (behalve lekker kloten met .net ) want je kunt gewoon die COM components gebruiken vanuit een .net app.

Verder, als je programmatuur stateless is en de transactions zijn puur database gericht, is MTS niet nodig maar kun je met de ADO(.NET) transaction methods je database transactions goed uitvoeren. .NET applicaties zijn meer gericht op black-boxes, dus je maakt gebruik van een applicatie (webservice) en wat daarbinnen gebeurt is niet belangrijk, dus gedraagt die applicatie zich als zodanig als een transaction. Het falen van een webservice call zou dan je huidige 'transaction' moeten laten falen, wat je handmatig kunt programmeren zonder MTS (dmv try/catch/finalize).

Ik zit zelf ook met 50.000 regels aan COM / Business logic components in VB en VC++6 maar die laat ik fijn in die taal: COM based development was en is gebaseerd op het gebruik van functionaliteit dus of die dingen nu in .NET of in VB6 zijn gebouwd boeit niet. Het 1:1 afbeelden van die applicatiestructuur op een .NET applicatie gaat overigens ook niet, je zet in .NET je applicatie toch iewat anders op.

[Verwijderd]

Op dinsdag 26 februari 2002 09:37 schreef paulgielens het volgende:

[..]

Softwarehuis, je zou die grijns op m'n gezicht moeten zien

Iets met een C, een M en een G?

/me , oud employee van die C, M en G

[Scare360]

Nee geen CMG

[Verwijderd]

op msnews.microsoft.com (newsserver, dus Outlook Express oid gebruiken) hebben ze een newsgroup: microsoft.public.dotnet.framework.component_services

(news://msnews.microsoft.com/microsoft.public.dotnet.framework.component_services)

Voor al je COM+/VB.net/.NET/MTS vragen. Veel mensen hebben dezelfde vraag als jij hebt. Wellicht helpt het.

[Scare360]

Bedankt kerel... trouwens dat artikeltje heb ik ondertussen doorgenomen en de ontwikkeling van "the good old Com/Com+" is een eitje. Allenig het porten blijft een hele klus gezien de wizzard er een grote troep van maakt

Listing Simple Com

code:

Imports System.EnterpriseServices
Imports System.Reflection

<Assembly: ApplicationName("ComPlusTest")> 
<Assembly: AssemblyKeyFile("C:\Documents and Settings\pgie\My Documents\Visual Studio Projects\ComLib\bin/ComPlusTest.snk")> 

<Transaction(TransactionOption.Required)> Public Class ComTest
    Inherits ServicedComponent

    Public Sub New()
      MyBase.New()
    End Sub

    Public Function DoTransaction() As String
      Return "Succes with COM+"
    End Function
End Class

Listing Simple App witch invokes ComPlusTest

code:

Module Module1

    Sub Main()
      Dim objcomTest As New ComLib.ComTest()

      Console.WriteLine(objcomTest.DoTransaction)
    End Sub

End Module

Misschien dat ik iemand anders vooruit help met dit simpele voorbeeld. PS: Let op dat je een Strong Name aanmaakt met het tooltje sn.exe.

vb: In console -> sn -k ComPlusTest.snk