ModuleName and ModuleDependency attributes - name of the module class or name of the module assembly, or fullname of module

Question

Is the string parameter used in a ModuleName and ModuleDependency attributes the name of the module class ,the name of the module assembly, or full name of the module class.

If there are two module projects one named Module1Project and the other named Module2Project.

In Module1Project the name of the module class is Module

1 public class Module1 :IModule

In Module2Project the name of the module class is Module2

public class Module2 :IModule

So what would be the string parameter  used in the ModuleNameAttribute for the both module classes be?

If Module1 had to be loaded before Module2,in the Module2 class what would be the string parameter bein the ModuleDependencyAttribute place above the Module2 class?

All the demo examples I fould the Project and the module class in the project had the same name.

Answer 1

Is the string parameter used in a ModuleName and ModuleDependency attributes the name of the module class, the name of the module assembly, or full name of the module class.

It is the module's name, which defaults to the name of the module class if no ModuleAttribute is present that overrides it.

So what would be the string parameter used in the ModuleNameAttribute for the both module classes be?

You can name the modules whatever you like, but you don't need a ModuleAttribute at all if you like the name of the class (Module1 and Module2 in your example) as name of the module.

The names of project, assembly and namespace don't matter. So, if, for example, you have MyProject.Module1 and TheOtherProject.Module1 as module classes and want to load them both at the same time, it makes sense to distinguish them using ModuleAttribute.ModuleName, if you cannot simply change the names of the classes.

Rant: Module1 isn't a good name for a module. A module, as a class should have a purpose, and a name that reflects it. You don't call your services or tables Service1, Service2, Table3 and Table4, do yo? WCFConnectorModule may be a good name for a module that provides the implementation for some backend-interface. If you can't come up with better names than Module1 and Module2 you most likely don't need or want modules in the first place. You want modules, if you have parts of your application that you want to swap out (without breaking anything) after compiling and probably after deploying. If you don't have this requirement, assemblies or just namespaces are perfectly fine to organize your code.