When are vb.net modules and its members loaded to memory

I wanted to know how modules and their members are loaded into memory in vb.net windows form application.

According to a VBForums post [1], Visual Basic loads code modules on demand, not all at once during startup. However, it's unclear what happens to functions in a module that are never called.
I also found a statement in Microsoft documentation [2] stating that a module and its members has the same lifetime as the program. Does this mean modules are loaded into memory during application startup ?

To get better clarity, I tried using a profiler and check when module gets loaded, but it didn't get clear information.

Here are my questions:
1. Do modules and all their members load into memory during application startup? If yes, is it possible to lazy load a module or its members?
2. If no, and if loads to memory only on function/method called, will other function/method in the same module be loaded to memory along with called function/method.
3. Is using a profiler the right way to monitor module loading into memory? If not, what other methods can be used?

[1] VBForums: VB Modules
https://www.vbforums.com/showthread....691-VB-Modules

[2] Microsoft Documentation: Module Statement
https://learn.microsoft.com/en-us/do...dule-statement

Just fyi - your first link there is irrelevant. The thread is 23 years old and was a discussion of VB6 modules... which are different from .NET

As for the actual question, I don't have a definitive answer, but interpreting the note from MS there, it sounds like modules are loaded at startup, or shortly thereafter. That said, if load times and/or memory management is an issue, perhaps a module isn't the right answer. Modules are kind of an odd duck since they don't really have an analogue in other languages. It's semi-uniquely a VB thing.

So, I decided to throw this at chatGpt... here's how that went:
Prompt: In .NET, specifically C#, at what point in the lifecycle of an application does a static class get loaded? Is it when the application loads, or when it's used, or at some other time?

Quote:

---

In .NET, a static class is loaded and initialized by the .NET Common Language Runtime (CLR) when it is first accessed or referenced within the application. This process is part of the just-in-time (JIT) compilation that occurs when the CLR is preparing to execute code.

When the application loads, the CLR performs various tasks including loading assemblies and types, but the actual loading and initialization of a static class occur when the class or its members are first accessed or used within the application code. The static constructor of the class, if present, will be executed at this point before any static members are accessed or used. After the static class is initialized, it remains in memory for the duration of the application's lifetime.

---

Prompt: Is this the same for a module in VB.NET? It's similar to a static class, but yet different at the same time.

Quote:

---

In VB.NET, a module is indeed somewhat similar to a static class in terms of providing a way to encapsulate code and data, but there are differences in their behavior.

When it comes to the loading and initialization of a module in VB.NET, it happens similarly to a static class in C#. The module is loaded and initialized by the CLR when it is first accessed or referenced within the application. This typically occurs during the execution of the code when a method, property, or any member of the module is invoked or used for the first time.

Much like a static class in C#, the initialization of a module in VB.NET involves executing its initialization code, if any, and then holding that state throughout the lifetime of the application. The key difference is that a module in VB.NET allows for a more natural syntax and behaves somewhat like a container for shared members, whereas a static class in C# relies on static members and cannot be instantiated.

In essence, both a module in VB.NET and a static class in C# are initialized when they are first accessed, ensuring that their content is available and their initialization code, if any, is executed as necessary.

---

It seems to indicate it's only loaded when it first accessed... This may also be dependent on the version of .NET being used and whether it's Core or not... :shrug:

Not sure if any of this helps, or muddys the water more...

-tg

According to https://github.com/dotnet/runtime/bl...type-system.md it looks like the runtime is designed to limit the loading of a type (Module, class, struct etc.) until it is needed - so if you have a lot of classes and modules in your app then they won't all be loaded on start-up.

Then again there is a lot more to take into account anyway, such as how assemblies are loaded, how relevant metadata is processed, etc. than make this entire process potentially non-trivial.

Additionally the IL code for each method will be JIT compiled into native code on first run (and potentially again for performance reasons), so once a type is loaded it will only JIT compile methods that are called from the type rather than all of them.

A lot of this is probably very version dependant, liable to change, and probably considered an implementation detail rather than a contractual thing so it might change; is there a specific reason you need to know these things or is it more of an academic question?