Event on Module Load:

[Praveen Ramesh]

Hi,

Is there anyway I can determine when exactly a module file I have (part of a
bigger assembly) gets loaded into memory?

The AssemblyLoad event tells me when exactly an assembly gets loaded, but
not a module.

Basically, I want to confirm that a module will NOT get loaded into memory
UNTIL a type defined in that module is referenced. That's what I have read,
but, I am finding it difficult to confirm.

Any feedback will be appreciated.

Thanks
Praveen

[Nice Chap]

A module, behind the scenes is nothing but a Class with only static members.
So if your experiment succeeds with a Class with static members you can rest
assured that the result holds good for a module.

[Praveen Ramesh]

Thanks for the feedback.

The static const. gets called only when the Type gets referenced explicitly,
but the file (.netmodule file) itself gets locked (cannot delete it) at
around app start.

What I also observed was that I could run the app without the above
..netmodule, until a type in that module gets referenced.

So, it does seem like the module gets loaded only as necessary, but I am
wondering why the file gets "locked" ahead of time!

-Praveen
"Nice Chap" <Ni******@PlasmaDyne.com> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl...

A module, behind the scenes is nothing but a Class with only static members. So if your experiment succeeds with a Class with static members you can rest assured that the result holds good for a module.

[Nice Chap]

I am not able to get what exactly you are after. Source files are locked by
Visual Studio not by CLR. Once compiled your module will be incorporated
into the assembly and there would be no question of locking the mod file.

"Praveen Ramesh" <rp******@syncfusion.com> wrote in message
news:eY**************@TK2MSFTNGP09.phx.gbl...

Thanks for the feedback.

The static const. gets called only when the Type gets referenced explicitly, but the file (.netmodule file) itself gets locked (cannot delete it) at
around app start.

What I also observed was that I could run the app without the above
.netmodule, until a type in that module gets referenced.

So, it does seem like the module gets loaded only as necessary, but I am
wondering why the file gets "locked" ahead of time!

-Praveen
"Nice Chap" <Ni******@PlasmaDyne.com> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl...

A module, behind the scenes is nothing but a Class with only static

members.

So if your experiment succeeds with a Class with static members you can

rest

assured that the result holds good for a module.

[Nice Chap]

I am not able to get what exactly you are after. Source files are locked by
Visual Studio not by CLR. Once compiled your module will be incorporated
into the assembly and there would be no question of locking the mod file.

"Praveen Ramesh" <rp******@syncfusion.com> wrote in message
news:eY**************@TK2MSFTNGP09.phx.gbl...

Thanks for the feedback.

The static const. gets called only when the Type gets referenced explicitly, but the file (.netmodule file) itself gets locked (cannot delete it) at
around app start.

What I also observed was that I could run the app without the above
.netmodule, until a type in that module gets referenced.

So, it does seem like the module gets loaded only as necessary, but I am
wondering why the file gets "locked" ahead of time!

-Praveen
"Nice Chap" <Ni******@PlasmaDyne.com> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl...

A module, behind the scenes is nothing but a Class with only static

members.

So if your experiment succeeds with a Class with static members you can

rest

assured that the result holds good for a module.

[Praveen Ramesh]

Yes, that sounds wierd doesn't it? But that's what I see.

There is no VS.Net in the picture here.
Let's say I have modulex with just TypeX, then when I run my app, before
TypeX's static const. gets hit my moudlex file gets locked. By locked, I
mean that I cannot delete that file. Running FileMon util., I see that my
Client app has a reference to that module file and so I cannot delete it.

I am inclined to believe though that the module file has not been loaded
into memory but just been "locked". That is how I would like to behave. But
I am not sure.

Thanks for the feedback.

-Praveen

"Nice Chap" <Ni******@PlasmaDyne.com> wrote in message
news:uf**************@TK2MSFTNGP09.phx.gbl...

I am not able to get what exactly you are after. Source files are locked by Visual Studio not by CLR. Once compiled your module will be incorporated
into the assembly and there would be no question of locking the mod file.

"Praveen Ramesh" <rp******@syncfusion.com> wrote in message
news:eY**************@TK2MSFTNGP09.phx.gbl...

Thanks for the feedback.

The static const. gets called only when the Type gets referenced

explicitly,

but the file (.netmodule file) itself gets locked (cannot delete it) at
around app start.

What I also observed was that I could run the app without the above
.netmodule, until a type in that module gets referenced.

So, it does seem like the module gets loaded only as necessary, but I am
wondering why the file gets "locked" ahead of time!

-Praveen
"Nice Chap" <Ni******@PlasmaDyne.com> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl...

A module, behind the scenes is nothing but a Class with only static

members.

So if your experiment succeeds with a Class with static members you

can rest

assured that the result holds good for a module.

[Praveen Ramesh]

Yes, that sounds wierd doesn't it? But that's what I see.

There is no VS.Net in the picture here.
Let's say I have modulex with just TypeX, then when I run my app, before
TypeX's static const. gets hit my moudlex file gets locked. By locked, I
mean that I cannot delete that file. Running FileMon util., I see that my
Client app has a reference to that module file and so I cannot delete it.

I am inclined to believe though that the module file has not been loaded
into memory but just been "locked". That is how I would like to behave. But
I am not sure.

Thanks for the feedback.

-Praveen

"Nice Chap" <Ni******@PlasmaDyne.com> wrote in message
news:uf**************@TK2MSFTNGP09.phx.gbl...

I am not able to get what exactly you are after. Source files are locked by Visual Studio not by CLR. Once compiled your module will be incorporated
into the assembly and there would be no question of locking the mod file.

"Praveen Ramesh" <rp******@syncfusion.com> wrote in message
news:eY**************@TK2MSFTNGP09.phx.gbl...

Thanks for the feedback.

The static const. gets called only when the Type gets referenced

explicitly,

but the file (.netmodule file) itself gets locked (cannot delete it) at
around app start.

What I also observed was that I could run the app without the above
.netmodule, until a type in that module gets referenced.

So, it does seem like the module gets loaded only as necessary, but I am
wondering why the file gets "locked" ahead of time!

-Praveen
"Nice Chap" <Ni******@PlasmaDyne.com> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl...

A module, behind the scenes is nothing but a Class with only static

members.

So if your experiment succeeds with a Class with static members you

can rest

assured that the result holds good for a module.