Questo è un’altro dei passaggi cruciali, abbastanza manutenibile anche a posteriori a patto che non siate sotto source control che rende le cose un po’ più ostiche.
Per prima cosa ricordiamoci che i sistemi di source control non digeriscono molto bene il rename di un progetto, e TFS non fa difetto ;-); per essere precisi il problema è che se siete (e io lo sono alla noia) pignoli quando rinominate un progetto volete anche rinominare la folder.. e questo spacca la solution… e che ----- :-), quindi si può fare ma è abbastanza tedioso, meglio cercare di evitarlo.
Tornando in tema, quando create un progetto Visual Studio fa le seguenti assunzioni:
  • creo una cartella con lo stesso nome del progetto e li ci metto il progetto e tutto il resto;
  • assegno come default namespace del progetto il nome del progetto, applicando una serie di trasformazioni se il nome del progetto non è proprio consono… tipo contiene degli spazi;
  • assegno all’assembly, output della build, lo stesso nome del progetto;
Molte bene, a me piace tutto :-) però attenzione alle scelte che fate:
  1. Casing: se il nome del progetto è “foo my library” il default namespace sarà una cosa del tipo foo_my_library che è tutto tranne che compliant alle naming convention: quindi perchè non chiamare il progetto “Foo.MyLibrary”?
  2. Io non metto mai il nome dell’azienda nel nome del progetto, ma modifico a mano dopo il default namespace: la mia personale convenzione è che il project name inizia sempre con il project code name seguito da qualcosa chje identifichi bene a cosa serve:
    1. project name: Next.Backend.Publishing;
    2. assembly name: Next.Backend.Publishing (.dll) che mi va benissimo;
    3. default namespace: ManagedDesigns.Next.Backend.Publishing, che è l’unica cosa che cambio;
fanno eccezione alla regola tipicamente i progetti di “startup”, le UI per intenderci, che spesso hanno nomi più esoterici:
  1. project name: Next Mvc UI;
  2. assembly name: Next (.dll);
  3. default namespace: ManagedDesigns.Next;
Perchè nell’assembly name non mettiamo il nome dell’azienda? perchè allungherebbe il nostro path… e non aggiungerebbe informazioni utili.
Perchè tutte queste menate che portano via un sacco di tempo?… che mi fanno fare tutto tranne che scrivere codice? perchè in un progetto degno del suo nome la scrittura del codice non è detto che sia la parte più importante, quello che a prima vista sembra il contorno potrebbe rivelarsi fondamentale in seguito e potrebbe rivelarsi essere la magagna che non vi fa dormire di notte.
Pensate banalmente a dover fare un po’ di sana reflection e a tutto il tempo che perdete perchè il naming degli assembly, dei tipi e dei namespace semplicemente non è intuitivo…
voglio caricare dinamicamente l’assembly del data layer… ma perchè si chiama “samples oracle tests.dll” e non “Next.Data.Oracle.dll”? e il collega… ahhh… si certo stavo facendo delle prove e poi sono andato avanti li… vaporizzatelo :-)
.m