Modules at the same level in a layered architecture
Of course it is possible, just be careful not to introduce circular dependencies between modules. In general, modules on a given layer should only depend on other modules from the same layer or layers below. Modules don't need to know about the layers above them.
If you want to make this even more restrictive, you can also restrict dependencies on other modules to the same or different levels below the current one.
Keeping the open interface to a minimum, eg. exposing only a basic set of public interfaces, value objects, and exceptions is always a good idea. You can use language access control functions (i.e. private / package / public) to limit the visibility of the internal components of a module from spilling over to other layers.
a source to share
Technically, you can cross-reference in any direction you want in .NET (there is no technical DAL constraint for referencing a UI component, although that might not be a good idea). I see no problem with module links at the same level.
But we need to take a little look at the word "layer" since layers have different shapes and sizes. Often when we use the word "layer" we think of the data access layer or presentation layer, and we usually let the layers look down but not up.
Within each layer, different modules often also allow you to logically arrange into layers. The same rule applies here; the module can look down, but not up. With this in mind, it feels safe enough to reference modules in the same (outer) layer.
You just don't need two modules to refer to each other, directly or indirectly. If you find that A and B both have functionality apart (which means that A and B are on the same level), you may have to refactor your code, perhaps introducing a new module C, logically below A and B. which both of them can use.
Also keep in mind to keep the modules as detached as possible; the less they know about each other, the better.
a source to share
as Paul said, be careful with your circular dependencies. If you absolutely cannot live without circular dependency (what you call cross-referencing), the classes must not only be from the same "level", but also from the same assembly.
At the same time, there should be no reason for cross-referencing - not only should (as stated in pavel) modules depend only on the layers below them, that in all cases there should be a one-way dependency.
There are some logical exceptions to this rule, for example, in something like the domain model - a customer will have multiple orders. In this case it can be useful (for example with ORM, etc.) To have a list of orders from the customer and a link to the customer from each order. As for units of functionality like services, etc., there should only be one way dependencies.
One way to get around this problem is to use inversion of control through Windsor, autofac, spring.net, etc. You can define an interface in an assembly and another object that uses a specific implementation of that interface. Another library may contain the actual implementation (which means that the assembly must reference the first assembly). In this case, the IoC container takes over the implementation.
a source to share