---

Hej.

Som et lille eksperiment i at få asp til at kommunikerer med .net,
har jeg lavet et lille COM-bibliotek.
I den forbindelse er jeg stødt på et lidt underligt problem i forb.
med instantiering af objekter med Sessions-virkefelt.


Når jeg i Global.asa deklarerer en instans af COM-klassen ASPClassic.Client
v.h.a. :

--- Global.asa ---
<OBJECT RUNAT=Server Scope=Session ID=Client PROGID="ASPClassic.Client">
</OBJECT>

og jeg kalder metoder på objektet Client som f.eks.:

--- Test.asp ---
<%
Response.Write Client.GetHashClode

Session.Abandon
%>

får jeg følgende fejl :

Fejltype:
Active Server Pages (0x8002802B)
Der opstod en fejl under oprettelse af objektet 'Client'.



Hvis jeg fjerner kald af metoder på Client og blot iterere over objekterne i
Session.StaticObjects får jeg følgende fejl :

Fejltype:
(0x80004003)
Ugyldig pointer



Hvis jeg derimod instantierer et objekt via Server.CreateObject(
"ASPClassic.Client" ) på side-niveau som f.eks. :

--- Test.asp ---
<%
Set MyClient = Server.CreateObject( "ASPClassic.Client" )
Response.Write MyClient.GetHashClode
Session.Abandon
%>

er alt fint og alt virker som det skal og jeg kan f.eks. gemme objektet i
Session.Content-samlingen og bruge det derfra,
men det vil jeg gerne undgå.

Så problemet er præcis hvad der gør at der ikke instantieres et
Client-objekt første gang det kaldes, når det er deklareret i Global.asa.
Et eller andet siger mig at for at COM-klasser kan instantieres fra
Global.asa med Session-virkefelt, skal de implementere
"et eller andet" idet jeg sagtens kan benytte fremgangsmåden med
standard-komponenterne, f.eks. MyInfo.... men hvad ?

Nogen bud ?


--
Six Degrees Of Separation

---

Michael Weber wrote:

> skal de implementere
> "et eller andet"
>
> Nogen bud ?

Nu ved jeg ikke hvordan ASP er strikket sammen internt.
Men hvis det(dit komponent) skal ligge globalt, kunne det være du skulle
kigge på din instiancing model og threading model.


--
Med venlig hilsen
Stig Johansen

---

Stig Johansen wrote:
> Michael Weber wrote:
>
>> skal de implementere
>> "et eller andet"
>>
>> Nogen bud ?
>
> Nu ved jeg ikke hvordan ASP er strikket sammen internt.
> Men hvis det(dit komponent) skal ligge globalt, kunne det være du
> skulle kigge på din instiancing model og threading model.


I forhold til instantieringen kunne jeg ikke rigtig finde nogen problemer.
Hvad jeg derimod fandt ud af, efter en tur i reg-databasen, var at threading
apartment, hvis ikke er er specificeret, pr. default sættes
til "both" og dermed lader det være op til COM-klienten.

Hvad jeg så opdagede var at mit komponent var registreret 2 gange, hvilket
vil sige at jeg havde glemt at unregister mit komponent på et tidligere
tidspunkt
Problemet er jo at når man sidder og afprøver sit bibliotek, "låser" windows
dll´en så når man skal kompilerer igen skal man omdøbe filen.
Så på én eller anden måde må der være kommet noget "rod" i reg-databasen.
Efter en "rensning" af reg-databasen og genregistrering virker instantiering
af objekter også i Global.asa.
Jeg må så lige prøve at se om jeg kan reproducerer fejlen på et tidspunkt.

Tak for hjælpen.
:)


--
Six Degrees Of Separation

---

Michael Weber wrote:

> Problemet er jo at når man sidder og afprøver sit bibliotek, "låser"
> windows dll´en så når man skal kompilerer igen skal man omdøbe filen.

På min kværn skal jeg bare stoppe IIS'en, eller rettere sagt, _servicen_
'world wide web publisher'.
dll'en er loadet så længe servicen kører.
Et stop på Internet Service Manageren frigiver ikke dll'en.

> Så på én eller anden måde må der være kommet noget "rod" i reg-databasen.

Det burde ellers ske mere eller mindre pr. automatik via regsvr32 eller?

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen wrote:
> Michael Weber wrote:
>
>> Problemet er jo at når man sidder og afprøver sit bibliotek, "låser"
>> windows dll´en så når man skal kompilerer igen skal man omdøbe filen.
>
> På min kværn skal jeg bare stoppe IIS'en, eller rettere sagt,
> _servicen_ 'world wide web publisher'.
> dll'en er loadet så længe servicen kører.
> Et stop på Internet Service Manageren frigiver ikke dll'en.
>


Ah!
Det måtte jeg lige efterprøve..og det virker.
Hvis man stopper www publisher i stedet for blot IIS kan man slette filen.
Glimrende!
Det gør tingene liiiidt nemmere.
:)


>> Så på én eller anden måde må der være kommet noget "rod" i
>> reg-databasen.
>
> Det burde ellers ske mere eller mindre pr. automatik via regsvr32
> eller?

Nu bruger jeg regasm ( register assembly ) med switch´ene /codebase og /tlb
( og /unregister den modsatte vej ), der
automatisk registrere (med autogenereret GUID hvis dette ikke er
specificeret i biblioteket) og producerer
et typebibliotek.

Så hvis jeg har afregistret et bibliotek, kompileret et nyt og registreret
dette _og_ 'world wide web publisher' har brugt den tidligere dll, som jeg
jo ikke kunne slette, så er der et versionsproblem....eller....det tror jeg.
Og selv hvis man registrerer en ny version, opretter en instans i asp og
derefter afregistrerer versionen, er det derefter stadig muligt at oprette
instanser
hvilket jo så må være fra den låste/loaded version.


--
Six Degrees Of Separation

---

Michael Weber wrote:

> Så hvis jeg har afregistret et bibliotek, kompileret et nyt og registreret
> dette _og_ 'world wide web publisher' har brugt den tidligere dll, som jeg
> jo ikke kunne slette,

Du behøver (højst sandsynligt) ikke at afregistre og registre igen, det er
kun en 'henvisning'.

Det handler om at servicen, som er programmet, (inetinfo.exe her) har loadet
dll'en.
Så længe dll'en er loaded er der ingen der må rette/slette osv.

Så selvom du
> registrerer en ny version, opretter en instans i asp
> og derefter afregistrerer versionen, er det derefter stadig muligt at
> oprette instanser
er det stadig den loadede version af dll'en der bliver brugt, som du selv er
inde på:
> hvilket jo så må være fra den låste/loaded version.
Præcis.

--
Med venlig hilsen
Stig Johansen

---

Michael Weber wrote:

> Nu bruger jeg regasm ( register assembly ) med switch´ene /codebase og
> /tlb ( og /unregister den modsatte vej ), der
> automatisk registrere (med autogenereret GUID hvis dette ikke er
> specificeret i biblioteket) og producerer
> et typebibliotek.

BTW - jeg bruger Delphi til den slags.
Jeg fandt en - måske lidt gammel side - men måske lidt informativ alligevel:
<http://www.matlus.com/scripts/website.dll/Tutorials?DelphiASP&FirstASP&1>

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen wrote:
> Michael Weber wrote:
>
>> Nu bruger jeg regasm ( register assembly ) med switch´ene /codebase
>> og /tlb ( og /unregister den modsatte vej ), der
>> automatisk registrere (med autogenereret GUID hvis dette ikke er
>> specificeret i biblioteket) og producerer
>> et typebibliotek.
>
> BTW - jeg bruger Delphi til den slags.
> Jeg fandt en - måske lidt gammel side - men måske lidt informativ
> alligevel:
> <http://www.matlus.com/scripts/website.dll/Tutorials?DelphiASP&FirstASP&1>


Tjoe....tjaee....hvis du kunne fortælle mig hvor han, i artiklen, får Active
Server Objektet fra, vil det hjælpe.
Umidelbart kan jeg ikke finde det i asp.dll., så måske det er noget
Delphi-halløj.
Hans klasse nedarver så vidt jeg kan forstå fra denne asp-klasse, men jeg
kan ikke finde det i asp.dll´en.
Det er dog lykkedes at få en refence til et Response-objekt ind i C# via en
metode og lave en Response.Write
fra C#.
So far, so good.
:)



--
Six Degrees Of Separation

---

Michael Weber wrote:

> Tjoe....tjaee....hvis du kunne fortælle mig hvor han, i artiklen, får
> Active Server Objektet fra, vil det hjælpe.

Det får man med en file|new|other
her er et dump fra min egen installation:
<http://w-o-p-r.dk/tips/asp/images/active_server_object.png>

> Det er dog lykkedes at få en refence til et Response-objekt ind i C# via
> en metode og lave en Response.Write
> fra C#. So far, so good.

Very good, men hold øje med om P/Invoke bliver ved med at være understøttet.

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen wrote:
> Michael Weber wrote:
>
>> Tjoe....tjaee....hvis du kunne fortælle mig hvor han, i artiklen, får
>> Active Server Objektet fra, vil det hjælpe.
>
> Det får man med en file|new|other
> her er et dump fra min egen installation:
> <http://w-o-p-r.dk/tips/asp/images/active_server_object.png>
>
>> Det er dog lykkedes at få en refence til et Response-objekt ind i C#
>> via en metode og lave en Response.Write
>> fra C#. So far, so good.
>
> Very good, men hold øje med om P/Invoke bliver ved med at være
> understøttet.

Når jeg begynder at invoke noget får jeg fejlen :

"ECall methods must be packaged into a system module."
hmm..

--
Six Degrees Of Separation

---

Michael Weber wrote:
> Stig Johansen wrote:
>> Michael Weber wrote:
>>
>>> Tjoe....tjaee....hvis du kunne fortælle mig hvor han, i artiklen,
>>> får Active Server Objektet fra, vil det hjælpe.
>>
>> Det får man med en file|new|other
>> her er et dump fra min egen installation:
>> <http://w-o-p-r.dk/tips/asp/images/active_server_object.png>
>>
>>> Det er dog lykkedes at få en refence til et Response-objekt ind i C#
>>> via en metode og lave en Response.Write
>>> fra C#. So far, so good.
>>
>> Very good, men hold øje med om P/Invoke bliver ved med at være
>> understøttet.
>
> Når jeg begynder at invoke noget får jeg fejlen :
>
> "ECall methods must be packaged into a system module."
> hmm..

Nå, men...
Response response =
(Response)System.EnterpriseServices.ContextUtil.GetNamedProperty("Response")
; //"Request", "Response", "Session", "Application", eller "Server"
response.Write("Hello");
....virker.

http://groups.google.com/group/microsoft.public.dotnet.languages.csharp/msg/
15bdd5cbef9666f4
:)

--
Six Degrees Of Separation

---

Michael Weber wrote:

> "ECall methods must be packaged into a system module."
> hmm..

Jeg prøvede at smide hele strengen ind i Google, og det ser ud som om det er
noget 'sikkerhedsnoget' i .NET.
Jeg bruger ikke selv .NET, så det kan jeg ikke hjælpe dig med.

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen wrote:
> Michael Weber wrote:
>
>> "ECall methods must be packaged into a system module."
>> hmm..
>
> Jeg prøvede at smide hele strengen ind i Google, og det ser ud som om
> det er noget 'sikkerhedsnoget' i .NET.
> Jeg bruger ikke selv .NET, så det kan jeg ikke hjælpe dig med.

Tjaee...hvis man kigger lidt under "motorhjelmen" på .NET viser det sig at :

System.EnterpriseServices.ContextUtil.GetNamedProperty("Response")

....faktisk laver et p/invoke til :

[DllImport("mtxex.dll", CallingConvention=CallingConvention.Cdecl)]
internal static extern int
GetObjectContext([MarshalAs(UnmanagedType.Interface)] out IObjectContext
pCtx);

men nu virker det ganske fint.

--
Six Degrees Of Separation

---

Michael Weber wrote:

> System.EnterpriseServices.ContextUtil.GetNamedProperty("Response")
>
> ...faktisk laver et p/invoke til :
>
> [DllImport("mtxex.dll", CallingConvention=CallingConvention.Cdecl)]
> internal static extern int
> GetObjectContext([MarshalAs(UnmanagedType.Interface)] out IObjectContext
> pCtx);
>
> men nu virker det ganske fint.

Jeg er ikke 100% sikker på hvor vi skal hen.
P/Invoke er jo netop den eneste måde for .NET til at få adgang til native
codede objekter - eller hur?

Hvorvidt det bliver understøttet i fremtidige versioner af .NET må man
ligesom selv køre en risk management på.

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen wrote:
> Michael Weber wrote:
>
>> System.EnterpriseServices.ContextUtil.GetNamedProperty("Response")
>>
>> ...faktisk laver et p/invoke til :
>>
>> [DllImport("mtxex.dll", CallingConvention=CallingConvention.Cdecl)]
>> internal static extern int
>> GetObjectContext([MarshalAs(UnmanagedType.Interface)] out
>> IObjectContext pCtx);
>>
>> men nu virker det ganske fint.
>
> Jeg er ikke 100% sikker på hvor vi skal hen.


Jeg var bare lige mig der kom ud på et sidespor.


> P/Invoke er jo netop den eneste måde for .NET til at få adgang til
> native codede objekter - eller hur?


Korrekt.


>
> Hvorvidt det bliver understøttet i fremtidige versioner af .NET må man
> ligesom selv køre en risk management på.


Sandt nok.



Tak for hjælpen.
:)


--
Six Degrees Of Separation