Summary
sm new module <Name> generates source files declaring namespace SimpleModule.<Name> and namespace SimpleModule.<Name>.Contracts, but creates the csproj as <Name>.csproj and <Name>.Contracts.csproj. The default assembly name from those csproj filenames is <Name> and <Name>.Contracts — which the framework's source generator then rejects with SM0052 and SM0053.
Net effect: a freshly-scaffolded project fails to compile.
Repro
dotnet tool install -g SimpleModule.Cli # 0.0.36
sm new project Repro
cd Repro
sm new module Customers
dotnet build
(Assumes the entity-singular collision in #148 is avoided by picking a name like Customers.)
Expected
Build succeeds. Generated assembly names line up with the namespace the templates produce (SimpleModule.<Name> and SimpleModule.<Name>.Contracts).
Actual
CSC : error SM0052: Module 'Customers' is in assembly 'Customers', but the assembly name must be 'SimpleModule.Customers' (or 'SimpleModule.Customers.Module' when a framework assembly with the same base name exists). Rename the project/assembly to follow the standard module naming convention.
CSC : error SM0053: Module 'Customers' (assembly 'Customers') has no matching Contracts assembly. Every module must have a 'SimpleModule.Customers.Contracts' project with at least one public interface.
Suggested fix
Either (any one is enough):
- Name the csproj files
SimpleModule.<Name>.csproj and SimpleModule.<Name>.Contracts.csproj (so the default assembly name matches).
- Inside the generated csproj, set
<AssemblyName>SimpleModule.<Name></AssemblyName> and <RootNamespace>SimpleModule.<Name></RootNamespace> explicitly.
- (If the goal is namespace flexibility) loosen
SM0052/SM0053 to accept any assembly name and discover the module by [Module] attribute.
Option 1 is the smallest change and gives consistent file naming with what dotnet build will produce in bin/.
Environment
sm --version: 0.0.36
dotnet --version: 10.0.201
- macOS
Related
#148 (the singular-name collision in the same scaffolding command).
Summary
sm new module <Name>generates source files declaringnamespace SimpleModule.<Name>andnamespace SimpleModule.<Name>.Contracts, but creates the csproj as<Name>.csprojand<Name>.Contracts.csproj. The default assembly name from those csproj filenames is<Name>and<Name>.Contracts— which the framework's source generator then rejects withSM0052andSM0053.Net effect: a freshly-scaffolded project fails to compile.
Repro
(Assumes the entity-singular collision in #148 is avoided by picking a name like
Customers.)Expected
Build succeeds. Generated assembly names line up with the namespace the templates produce (
SimpleModule.<Name>andSimpleModule.<Name>.Contracts).Actual
Suggested fix
Either (any one is enough):
SimpleModule.<Name>.csprojandSimpleModule.<Name>.Contracts.csproj(so the default assembly name matches).<AssemblyName>SimpleModule.<Name></AssemblyName>and<RootNamespace>SimpleModule.<Name></RootNamespace>explicitly.SM0052/SM0053to accept any assembly name and discover the module by[Module]attribute.Option 1 is the smallest change and gives consistent file naming with what
dotnet buildwill produce inbin/.Environment
sm --version: 0.0.36dotnet --version: 10.0.201Related
#148 (the singular-name collision in the same scaffolding command).