.NET and C++ target assembly names are identical when not specifying a "main module"

[kamiddel]

If the generated code is compiled for .NET and CPP, for both technologies binary files with identical names are created. A deployment in a directory for both technologies will result in a name conflict.

[sigiesec]

Looks like a regression. In principle, .NET assemblies should always contain a .NET name fragment, controlled by the "main" prefix to the module keyword.

[sigiesec]

I checked the current implementation. The .NET fragment is only added after the modules marked as main, these may be 0, 1 or multiple. However, the nu-get package name will always have .NET at its end, so to get a consistent naming, for a file named Foo.Bar.idl, you should use:

module Foo {
  main module Bar {
    // your interface definition
  }
}

Can you use this approach for the moment? I will discuss with @GerrietReents how to deal with this in future versions. I can imagine removing/deprecating the main keyword completely, and derive this from the package name. Maybe it also makes sense to check consistency between the module name and the file name.

[kamiddel]

I will try that and then feedback here. Thanks.

[kamiddel]

Now I get files like BTC.GA.FieldLink.NET.ServiceAPI.dll. This is not the name structure I had expected (request: BTC.GA.FieldLink.ServiceAPI.NET.dll), but solves the problem for now.

[sigiesec]

@kamiddel As discussed today, the current behaviour when specifying the inner module as the main module will be preserved. Appending .NET at the end of each module name will probably not be supported, as this would create an inconsistency with the package name.

[huttenlocher]

Just a remark: the current behavior is "by design" and was requested in this form by Stefan Baier. Using "main" keyword allows the IDL author to designate the namespace part with ".NET" appendix in a flexible way. Without this hint, there is indeed no difference between resulting namespaces in C++ und .NET

[sigiesec]

After discussion with @GerrietReents and @huttenlocher, which includes some other issues with the naming (where the package name is not consistent with the module name), we came to the following conclusion:

• the "main" prefix to the module keyword is kept
• the name of the package will no longer be derived from the IDL filename, but always from the name of the "main" module. If no module is declared as main explicitly, the outermost module that is non-empty will be implicitly regarded as the "main" module.
• some diagnostics will be added that check
  • there may be only one "main" module (ERROR)
  • all modules that are not contained in the "main" module must be empty (ERROR)
  • there are multiple top-level modules that contain declarations (ERROR)
  • there are multiple modules which contain declarations and no module is explicitly declared as "main" (WARNING)
  • the name of the file must correspond to the "main" module name (WARNING)

In a future step, the IDL syntax might be changed to remove the possibility for some misuses, by replacing the nested module specification by a single module statement, similar to the package declaration in Java. This is beyond the scope of this issue.

[huttenlocher]

@sigiesec, just to mention: the first check (there may be only one "main" module) already exists since "main" keyword was introduced, see com.btc.serviceidl.validation.IdlValidator::checkMainModule.