Contesto
I miei progetti sono separati in un unico assieme con Interfacce, che chiamo Core , e un altro assieme con l'implementazione, che chiamo Implementation . In realtà, gli spazi dei nomi hanno questo aspetto:
CompanyName.ProjectName.Core
CompanyName.ProjectName
Il primo progetto non ha una logica di business in esso (può o non può avere logica "dominio", logica correlata all'istanziazione di base e alla convalida dei modelli). Il secondo progetto ha tutta la logica aziendale in esso contenuta (può o non può avere logica "dominio", come la definisco qui).
Qualsiasi altro progetto in qualsiasi altro sistema che desideri consumare questo dominio implementerà solo Core e nient'altro. Da lì, può definire l'utilizzo delle interfacce e dei modelli definiti all'interno.
Qualsiasi altro Startup Progetti dovrebbe anche consumare SOME versione di Implementazione, al fine di eseguire Dependency-Injection sulle loro classi che stanno consumando il Core . È probabile che consumeranno il progetto di implementazione che ho definito sopra ... specialmente se è l'unica implementazione del relativo Core .
Il problema
In generale, non distribuisco la mia implementazione a meno che non venga pagata. Ciò consente agli utenti di esaminare, navigare e implementare liberamente un Core del mio prodotto, senza l'effettiva implementazione proprietaria a meno che non lo comprino.
In questo caso, ho creato alcune classi base Abstract che contengono molta implementazione della piastra di riscaldamento del Core Interfaces . A tutti gli effetti, questo assembly con le classi base è il progetto di implementazione, a cui non voglio che gli utenti non autorizzati abbiano accesso.
Tuttavia, ho bisogno che abbiano accesso alle definizioni delle classi astratte in modo che possano implementarle. Quindi tecnicamente, sono Core materiale. Contratti, se vuoi.
La mia soluzione fallita 1
L'idea 1 consiste nel definire la classe astratta nel progetto principale, ma fare in modo che tutti i metodi virtuali non generino eccezioni implementate.
Se creo la classe: CompanyName.ProjectName.Core.BaseClass() , il consumatore implementerà quella classe. Quindi, quando in seguito consumerò le loro librerie, il mio effettivo CompanyName.ProjectName.BaseClass() non verrà riconosciuto come lo stesso oggetto.
Se creo la classe: CompanyName.ProjectName.BaseClass() all'interno del mio assembly Core , quindi quando uso in seguito le loro librerie, la mia implementazione Attuale genererà un'eccezione secondo la quale esistono due istanze di CompanyName.ProjectName.BaseClass() e non sa quale usare.
La mia soluzione fallita 2
L'idea 2 è di andare avanti e dare loro la stessa esatta libreria di implementazione ... ma prima di darglielo, rimuovi tutta la logica e lancia le eccezioni non implementate.
Questo funziona, ma è molto lavoro per me, e devo dare loro le librerie manualmente. Quindi non saranno in grado di utilizzare NuGet o qualcosa che li possa estrarre.
La mia soluzione fallita 3
Simile a Idea 2; Idea 3 è creare un nuovo pacchetto NuGet chiamato CompanyName.ProjectName.________ , che è lo stesso di Idea 2 sopra.
Non l'ho ancora provato, ma presumo che funzionerebbe. Avrebbero implementato la biblioteca e, quando mi avrebbero dato le loro assemblee, avrei semplicemente sostituito la loro falsa dll con quella che ho. Oppure, al contrario, quando pagano il prodotto, sostituiscono semplicemente il loro falso con quello a pagamento.
Un problema qui è ... Non l'ho provato direttamente, quindi non sono sicuro che funzionerebbe. Sebbene, data la mia conoscenza degli spazi dei nomi e della firma dell'assemblea, presumo che sarebbe facile farlo funzionare. Non riesco a testarlo senza una convenzione di denominazione accettabile, quindi ...
Il problema principale qui è, come si chiamerebbe quel pacchetto NuGet? Non può essere Core, Implementation o Empty. C'è già uno schema per questo, o devo fare qualcosa.
La mia soluzione fallita 4
Acquista un offuscatore e implementa uno schema di licenza in modo che ... gli utenti senza licenza non possano accedere all'implementazione, ma potrebbero comunque consumare i contratti.
Questo è costoso e richiede il lavoro per implementare lo schema delle licenze ... In realtà pianifico di fare tutto questo, ma non prima del nuovo anno. Spero che ci sia qualche altra risposta che è utile usare nell'intermediario.