applicatie met minder functionaliteit compileren c#

[Verwijderd]

Ik heb een uitgebreide ontwikkeltool met heel wat control die voor intern gebruik zijn. Nu wil ik deze tool ook beschikbaar stellen voor iemand anders, maar die mag maar een beperkte functionaliteit hebben.
Uit oogpunt van onderhoudbaarheid, zou ik graag één source houden en hier wat condities aan toe voegen om controls wel of niet zichtbaar te maken.
Nu vroeg ik me af of iemand hier een goede aanpak voor weet. Hoe kan ik makkelijk 2 varianten compileren en daarbij een variabele zetten ofzo.
Ik werk in VS2015 en C#

[Teunis]

MSDN: #if (C# Reference) ?

[Adimeuz]

Een eerste gedachte is inderdaad via de preprocessor directives. Echter vind ik het zelf (mijn mening) meer een manier om in uitzonderlijke situaties dingen toe te laten / weg te laten.

Wat jij noemt, heeft meer te maken met de requirements van het gehele systeem, en zou eerder opgelost moeten worden door bepaalde ontwerpkeuzes te maken (denk bijvoorbeeld eens aan een gelaagde architectuur, een control-layer waarin de typen gebruikers liggen), in plaats van deze "quick-and-dirty" ifdev-jes. Het wordt er in ieder geval niet leesbaarder (lees: onderhoudbaarder) op.

[ Voor 7% gewijzigd door Adimeuz op 30-05-2016 10:37 ]

[Mercatres]

Adimeuz schreef op maandag 30 mei 2016 @ 10:23:
Een eerste gedachte is inderdaad via de preprocessor directives. Echter vind ik het zelf (mijn mening) meer een manier om in uitzonderlijke situaties dingen toe te laten / weg te laten.

Wat jij noemt, heeft meer te maken met de requirements van het gehele systeem, en zou eerder door opgelost moeten door bepaalde ontwerpkeuzes te maken (denk bijvoorbeeld eens aan een gelaagde architectuur, een control-layer waarin de typen gebruikers liggen), in plaats van deze "quick-and-dirty" ifdev-jes. Het wordt er in ieder geval niet leesbaarder op.

Inderdaad, je zegt namelijk al zelf dat je aparte gebruiker-rollen hebt.
Als je dit echter niet wilt implementeren, is er alsnog de optie om het via de App.config te doen, maar dat zou ik ten zeerste afraden.

[Hydra]

Wat je zou kunnen doen tijdens/na de build de classes met de code die je niet extern wil hebben verwijderen. At start-up doe je dan een check of die class bestaat (in Java is dat Class.forName(), .Net zal ook zo iets hebben) en disable je de interne functionaliteit. Dit is dus niet te omzeilen (zoals bij licentie checks) omdat de code simpelweg niet aanwezig is en je hoeft je code ook niet te vervuilen met precompiler directives. Enige wat je moet doen is zorgen dat de interne functionaliteit in een losse module staat en dat de UI hier rekening mee houdt.

Mercatres schreef op maandag 30 mei 2016 @ 10:35:
Inderdaad, je zegt namelijk al zelf dat je aparte gebruiker-rollen hebt.

Niet echt. Het is een beetje als het ouderwetse 'shareware' gebeuren. Je geeft hetzelfde programma dat beperkt is ongeacht van welke gebruiker het gebruikt. Dit voorkomt ook dat je met reverse engineering toch toegang krijgt.

[ Voor 27% gewijzigd door Hydra op 30-05-2016 11:10 ]

[MSalters]

Adimeuz schreef op maandag 30 mei 2016 @ 10:23:
Een eerste gedachte is inderdaad via de preprocessor directives. Echter vind ik het zelf (mijn mening) meer een manier om in uitzonderlijke situaties dingen toe te laten / weg te laten.

Wat jij noemt, heeft meer te maken met de requirements van het gehele systeem, en zou eerder opgelost moeten worden door bepaalde ontwerpkeuzes te maken (denk bijvoorbeeld eens aan een gelaagde architectuur, een control-layer waarin de typen gebruikers liggen), in plaats van deze "quick-and-dirty" ifdev-jes. Het wordt er in ieder geval niet leesbaarder (lees: onderhoudbaarder) op.

Het probleem met jouw niet-quick-and-dirty method is vooral dat het niet quick is. Het verdient zich zeker terug als je een vierde of vijfde variant moet gaan supporten, met verschillende mates van overlap tussen die 5 rollen.

Een nog niet genoemd alternatief is de verboden functionaliteit in een aparte DLL onder te brengen, en die simpelweg niet mee te leveren. (.Net gebruikt on-demand loading van DLL's)

[Grijze Vos]

Plugin architectuur en de plugins niet meeleveren.

[jip_86]

Ben wel benieuwd waar hem dan de verschillen in gaan zitten? Gaat het er dan om dat die gebruiker alleen schermpje A nodig heeft en jij bijvoorbeeld A, B en C? Of meer in de richting dat jullie beiden A, B, en C gebruiken, maar die gebruiker bijvoorbeeld alleen inzage nodig heeft?

[DJMaze]

Gewoon een licentie rechten class en voor elke "feature" een waarde.
De rechten vervolgens via een encrypted systeem laden.

[Verwijderd]

jip_86 schreef op maandag 30 mei 2016 @ 14:10:
Ben wel benieuwd waar hem dan de verschillen in gaan zitten? Gaat het er dan om dat die gebruiker alleen schermpje A nodig heeft en jij bijvoorbeeld A, B en C? Of meer in de richting dat jullie beiden A, B, en C gebruiken, maar die gebruiker bijvoorbeeld alleen inzage nodig heeft?

Nu is het niet meer dan van een tabcontrol 2 tabbladen verwijderen, daarmee is de meeste development functionaliteit al weg.
De opties van een mooie gelaagde architectuur zou mooi zijn, maar daar is geen tijd en budget voor.
De optie met de plugin DLLs, hebben we bij een andere tool gebruik en dat werkt erg goed, maar is voor de bestaande tool ook teveel werk.
Ik denk dat het toch maar met de compiler directives moet. Ik ben daar niet zo'n voorstander van, maar het is het één of het ander.

[Laurens-R]

Is het dan niet handiger om die twee tabbladen te hiden oid? Normaliter zou ik het via de architectuur regelen door een plugin model oid te implementeren, maar als je quick and dirty wilt en de user niet zo tech savy is dat hij zelf tegen jouw assemblies aan gaat builden kan dat al voldoende zijn.

[Lethalis]

Gezien het tijdgebrek dat je hebt, zou ik een globale boolean zetten ergens (static property in een class).

Dus bijv. MijnTool.DevMode die standaard true is.

Vervolgens zou ik een preprocessor directive gebruiken om hem op false te zetten. Dan heb je die directive maar op 1 plek.

Vervolgens kun je overal in de code gewoon MijnTool.DevMode gebruiken om de functionaliteit aan / uit te zetten.

Wil je in de toekomst iets anders gebruiken, dan laat je dat die property zetten.

[Verwijderd]

Lethalis schreef op dinsdag 31 mei 2016 @ 08:58:
Gezien het tijdgebrek dat je hebt, zou ik een globale boolean zetten ergens (static property in een class).

Dus bijv. MijnTool.DevMode die standaard true is.

Vervolgens zou ik een preprocessor directive gebruiken om hem op false te zetten. Dan heb je die directive maar op 1 plek.

Vervolgens kun je overal in de code gewoon MijnTool.DevMode gebruiken om de functionaliteit aan / uit te zetten.

Wil je in de toekomst iets anders gebruiken, dan laat je dat die property zetten.

zo wilde ik het inderdaad doen.
Dat zal ook de compilatie variant worden.
Maar ik zat nog met een 2e wens eigenlijk.

Ik moet voor elke klant een variant maken. Al deze versie hebben dus beperkte functionaliteit maar de applicatie moet wel een unieke klant id bevatten. Dit is niet meer dan een byte.

Nu had ik vandaag het idee om bij de executable gewoon een text file of whatever voor file mee te leveren met ene encrypted string.

Ik zal te denken om bijvoorbeeld een string te gebruiken als "devMode=true;customerId=123"
Als ik deze string assymetrisch encrypt en in een file schrijf, dan kan ik de tool laten zoeken naar deze file. de string decrypten en aan de hand daarvan wat opties enablen of het klant ID bepalen.
Dat lijkt me een eenvoudige oplossing.

Nu ben ik niet zo thuis in encryptie maar om iets assymetrisch te encrypten/decrypten met RSA is niet spannend. Nu had ik al 2 voorbeelden op codeProjects gezien en die doen wat ik zou willen, echter had ik bij assymetrische encrypte verwacht dat ik ergens in mijn code de private en public key moet ingeven maar die zie ik nergens terug komen.

de voorbeeld code is:

C#:

static public byte[] RSAEncrypt(byte[] DataToEncrypt, RSAParameters RSAKeyInfo, bool DoOAEPPadding)
        {
            try
            {
                byte[] encryptedData;
                //Create a new instance of RSACryptoServiceProvider. 
                using (RSACryptoServiceProvider RSA = new RSACryptoServiceProvider())
                {

                    //Import the RSA Key information. This only needs 
                    //toinclude the public key information.
                    RSA.ImportParameters(RSAKeyInfo);

                    //Encrypt the passed byte array and specify OAEP padding.   
                    //OAEP padding is only available on Microsoft Windows XP or 
                    //later.  
                    encryptedData = RSA.Encrypt(DataToEncrypt, DoOAEPPadding);
                }
                return encryptedData;
            }
            //Catch and display a CryptographicException   
            //to the console. 
            catch (CryptographicException e)
            {
                Console.WriteLine(e.Message);

                return null;
            }

        }

vevolgens wordt de functie zo gebruikt:

C#:

RSACryptoServiceProvider RSA = new RSACryptoServiceProvider();
            encryptedtext = RSAEncrypt(plaintext, RSA.ExportParameters(false), false);

werkt RSA niet met private/public keys?

Mijn idee was dus om op het werkt 1 tool te beheren die de keys genereert en dat de applicatie die we aan klanten geven enkel deze keys decrypt

[jip_86]

Nu ga je wel ineens van een interne tool die ook door een ander gebruikt moest worden naar een tool die door meerdere klanten gebruikt kan worden. Wat is het nu?

[Ventieldopje]

Is het niet makkelijker om een simpele 'phone home' routine te maken met klantnummer en unieke sleutel waarna de server een lijst met mogelijkheden stuurt (allemaal via SSL natuurlijk). Dan hoef je maar 1 keer te compileren en zet je het klantnummer en sleutel gewoon in een configuratie bestand.

Desnoods limiteer je het aantal gebruikers of op IP...

[jip_86]

Sowieso zou ik niet functies af gaan schermen met customerids dat word een zooitje als je overal lijsten met customerids hebt staan in je code.

[Verwijderd]

nee het customer ID is enkel een getal wat bij bepaalde functies gebruikt moet worden als argument meer niet.
de afgeschermde functies zijn voor alle verschillende klanten hetzelfde.
Maar om nu 10 versie te compileren omdat deze 10 versies enkel een ander getalletje moeten hebben vind ik teveel gedoe.
Dus het is een interne tool die functioneel uitgekleed moet worden voor klanten. Elke klant (hooguit 5 a 10) moet een uniek nummertje hebben. Deze heeft geen relatie met de functies die aan of uit staan.
Zo slecht idee is mijn idee met ene encrypted key toch niet?

[Ventieldopje]

Verwijderd schreef op woensdag 08 juni 2016 @ 21:11:
nee het customer ID is enkel een getal wat bij bepaalde functies gebruikt moet worden als argument meer niet.
de afgeschermde functies zijn voor alle verschillende klanten hetzelfde.
Maar om nu 10 versie te compileren omdat deze 10 versies enkel een ander getalletje moeten hebben vind ik teveel gedoe.
Dus het is een interne tool die functioneel uitgekleed moet worden voor klanten. Elke klant (hooguit 5 a 10) moet een uniek nummertje hebben. Deze heeft geen relatie met de functies die aan of uit staan.
Zo slecht idee is mijn idee met ene encrypted key toch niet?

Je wensen veranderen nogal eens heb ik het idee. Je idee is prima maar niet erg flexibel, blijkbaar hoeft dat ook niet

[roy-t]

Volgens mij is het nog niet genoemd, maar het is bijzonder makkelijk om at runtime dingen aan C# code te veranderen. Zoiets als een tabblad weer zichtbaar maken kan zonder enige probleem met Snoop. En een licentie check ergens uit gooien is ook in een paar uur gedaan. Nu weet ik niet hoe belangrijk het is dat deze klant niet bij deze functionaliteit kan. Maar het is denk ik goed om even een korte kosten/baten analyse te maken om te bepalen of je misschien obfuscators wil gebruiken of toch afgescheide DLLs wil gebruiken.

De encryptie klassen in .net zijn ooit nogal geupdate. Ik heb ze al een tijd niet meer gebruikt maar check even dat je de meest up-to-date documentatie gebruikt .

[ Voor 7% gewijzigd door roy-t op 09-06-2016 13:57 ]

[Verwijderd]

Helemaal mee eens,
de truuk om controls weer zichtbaar te maken door er een debug process aan te attachen bijvoorbeeld kan.
Zo schokkend is het niet.
Over het algemeen schat ik onze klanten niet in dat het zulke script kiddies zijn. Het is ook geen zwaar geheime info ofzo.