static msclr::auto_gcroot managed variables and the linker lock error

[DaTurk]

Hi,

I've noticed that when trying to create a managed, auto_gcrooted
variable in a antive class, the compiler throws linker exceptions.
While searching some forums I found out that this is a bug? I
couldn't find the work around, just numerous references to the fact
there is one. But apparently there are issues as to how to destroy
said objects. Can anyone shed some more light on this topic for me?
It would be much appreciated.

[Ben Voigt]

"DaTurk" <mm******@hotmail.comwrote in message
news:11**********************@k78g2000cwa.googlegr oups.com...

Hi,

I've noticed that when trying to create a managed, auto_gcrooted
variable in a antive class, the compiler throws linker exceptions.
While searching some forums I found out that this is a bug? I
couldn't find the work around, just numerous references to the fact
there is one. But apparently there are issues as to how to destroy
said objects. Can anyone shed some more light on this topic for me?
It would be much appreciated.

It's the "loader lock", not "linker lock" that will bite you with static
native variables in mixed assemblies. Essentially, when static variables
are initialized, the managed runtime typically isn't started yet, so you
can't create managed objects. Destruction has the same issues, static
variables last until the very end, when the managed runtime has typically
shutdown.

I think you might be able to work around with a pointer to gcroot and lazy
initialization. And you'll have to explicitly delete the gcroot object to
get cleanup right.

And don't even think of using a native class instance declared as a global
to perform your init and cleanup, that's the same problem all over again,
although the linker probably wouldn't recognize it.

[DaTurk]

On Feb 12, 7:12 pm, "Ben Voigt" <[e-mail]:

"DaTurk" <[e-mail] in message

news:11**********************@k78g2000cwa.googlegr oups.com...

Hi,

I've noticed that when trying to create a managed, auto_gcrooted
variable in a antive class, the compiler throws linker exceptions.
While searching some forums I found out that this is a bug? I
couldn't find the work around, just numerous references to the fact
there is one. But apparently there are issues as to how to destroy
said objects. Can anyone shed some more light on this topic for me?
It would be much appreciated.

It's the "loader lock", not "linker lock" that will bite you with static
native variables in mixed assemblies. Essentially, when static variables
are initialized, the managed runtime typically isn't started yet, so you
can't create managed objects. Destruction has the same issues, static
variables last until the very end, when the managed runtime has typically
shutdown.

I think you might be able to work around with a pointer to gcroot and lazy
initialization. And you'll have to explicitly delete the gcroot object to
get cleanup right.

And don't even think of using a native class instance declared as a global
to perform your init and cleanup, that's the same problem all over again,
although the linker probably wouldn't recognize it.

I'm not entirely sure what lazy init is, could you elaborate please?

[Ben Voigt]

"DaTurk" <mm******@hotmail.comwrote in message
news:11**********************@m58g2000cwm.googlegr oups.com...

On Feb 12, 7:12 pm, "Ben Voigt" <[e-mail]:

>"DaTurk" <[e-mail] in message

news:11**********************@k78g2000cwa.googleg roups.com...

Hi,

I've noticed that when trying to create a managed, auto_gcrooted
variable in a antive class, the compiler throws linker exceptions.
While searching some forums I found out that this is a bug? I
couldn't find the work around, just numerous references to the fact
there is one. But apparently there are issues as to how to destroy
said objects. Can anyone shed some more light on this topic for me?
It would be much appreciated.

It's the "loader lock", not "linker lock" that will bite you with static
native variables in mixed assemblies. Essentially, when static variables
are initialized, the managed runtime typically isn't started yet, so you
can't create managed objects. Destruction has the same issues, static
variables last until the very end, when the managed runtime has typically
shutdown.

I think you might be able to work around with a pointer to gcroot and
lazy
initialization. And you'll have to explicitly delete the gcroot object
to
get cleanup right.

And don't even think of using a native class instance declared as a
global
to perform your init and cleanup, that's the same problem all over again,
although the linker probably wouldn't recognize it.

I'm not entirely sure what lazy init is, could you elaborate please?

Just that initialization waits until the first time you use it, maybe
involving a check for NULL. Writing an explicit initialization function
called from a managed type initializer (also called static constructor or
..cctor) also works well.

[DaTurk]

On Feb 13, 11:05 am, "Ben Voigt" <[e-mail]:

"DaTurk" <[e-mail] in message

news:11**********************@m58g2000cwm.googlegr oups.com...

On Feb 12, 7:12 pm, "Ben Voigt" <[e-mail]:

"DaTurk" <[e-mail] in message

>news:11**********************@k78g2000cwa.googleg roups.com...

Hi,

I've noticed that when trying to create a managed, auto_gcrooted
variable in a antive class, the compiler throws linker exceptions.
While searching some forums I found out that this is a bug? I
couldn't find the work around, just numerous references to the fact
there is one. But apparently there are issues as to how to destroy
said objects. Can anyone shed some more light on this topic for me?
It would be much appreciated.

It's the "loader lock", not "linker lock" that will bite you with static
native variables in mixed assemblies. Essentially, when static variables
are initialized, the managed runtime typically isn't started yet, so you
can't create managed objects. Destruction has the same issues, static
variables last until the very end, when the managed runtime has typically
shutdown.

I think you might be able to work around with a pointer to gcroot and
lazy
initialization. And you'll have to explicitly delete the gcroot object
to
get cleanup right.

And don't even think of using a native class instance declared as a
global
to perform your init and cleanup, that's the same problem all over again,
although the linker probably wouldn't recognize it.

I'm not entirely sure what lazy init is, could you elaborate please?

Just that initialization waits until the first time you use it, maybe
involving a check for NULL. Writing an explicit initialization function
called from a managed type initializer (also called static constructor or
.cctor) also works well.- Hide quoted text -

- Show quoted text -

OK, I understand. But what I don't understand is how this allows me
to use a static, gcrooted, managed variable in native code. I'm not
sure what I'm missing.