[VS 2008] Applicatie compileren naar 2 verschillende namen

[ThaStealth]

We zijn bezig met een nieuwe software applicatie te ontwikkelen, deze applicatie moet uiteindelijk gecompileerd worden naar 2 verschillende producten (d.w.z., naam + logo moet anders zijn, interne functies van de app blijven hetzelfde).

Op dit moment is er een vorige versie van deze applicatie in Delphi geschreven, hier is het opgelost door 2 dezelfde projecten te maken (met dezelfde files erin dus) met alleen 2 verschillende compiler directives.

De vraag is hoe ik dit het beste gedaan kan krijgen, het liefste zou ik het zo willen hebben dat bij elke build de twee versies alle twee gebakken worden. Maar is dit mogelijk?

[Haan]

Je kan in VS wel prima verschillende build configurations instellen, ik zou alleen niet weten of je ook met 1 build meerdere configurations kan builden. Normaal gesproken kies je een configuratie (bijv. debug of release of je eigen variant) waarmee je gaat builden.

[CodeCaster]

Dat kan gewoon, of denk ik nu te simpel of juist te moeilijk?

[ Voor 6% gewijzigd door CodeCaster op 18-10-2010 11:02 ]

[jip_86]

Naam en logo configureerbaar maken en uitleveren met verschillende configbestanden.

Dus:
config1
- bedrijfsnaam a
- logo_a.jpg

config2
- bedrijfsnaam b
- logo_b.jpg

[MLM]

Je kan gewoon een file in een project rechtsklikken en dan "exclude from build", en die setting word opgeslagen per project-configuratie, dus dan kan je een project configuratie klonen, en in elk van de configuraties een andere file meebouwen
(Uit mijn ervaringen met VisualC++ 2008, als je C# ofzo gebruikt, weet ik niet of dat kan)

[ThaStealth]

CodeCaster schreef op maandag 18 oktober 2010 @ 10:38:
Dat kan gewoon, of denk ik nu te simpel of juist te moeilijk?
[afbeelding]

Nadeel daarvan is dat als ik een file in application a toevoeg ik em ook in application b moet toevoegen, (waardoor ik makkelijk 1 kan vergeten te adden).

jip_86 schreef op maandag 18 oktober 2010 @ 10:48:
Naam en logo configureerbaar maken en uitleveren met verschillende configbestanden.

Dus:
config1
- bedrijfsnaam a
- logo_a.jpg

config2
- bedrijfsnaam b
- logo_b.jpg

Jep, maar dan moeten alle 2 de files erbij geleverd worden, en das iets wat we liever niet doen (mocht iemand beginnen rond te neuzen in de dirs )

MLM schreef op maandag 18 oktober 2010 @ 10:59:
Je kan gewoon een file in een project rechtsklikken en dan "exclude from build", en die setting word opgeslagen per project-configuratie, dus dan kan je een project configuratie klonen, en in elk van de configuraties een andere file meebouwen
(Uit mijn ervaringen met VisualC++ 2008, als je C# ofzo gebruikt, weet ik niet of dat kan)

Jep dat is mogelijk, alleen moet ik dan nog met configs/directives werken om aan te geven dat hij een bepaalde versie moet gaan bouwen

[CodeCaster]

ThaStealth schreef op maandag 18 oktober 2010 @ 15:39:
[...]


Nadeel daarvan is dat als ik een file in application a toevoeg ik em ook in application b moet toevoegen, (waardoor ik makkelijk 1 kan vergeten te adden).

Forms, klassen, en andere gedeelde dingen voeg je dan toe aan de gedeelde programmabibliotheek (in sommige streken ook wel DLL), waar beide Application-projecten een referentie naar hebben. Per project (dus per executable) heb je alleen een aparte config en launch-screen (of wat je dan ook wil customizen). Het voordeel hiervan is dat je designtime specifieke aanpassingen kunt maken, het nadeel is dat je code kopiëert.

Andere oplossingen zien er ook wel goed uit.

ThaStealth schreef op maandag 18 oktober 2010 @ 15:39:
Jep, maar dan moeten alle 2 de files erbij geleverd worden, en das iets wat we liever niet doen (mocht iemand beginnen rond te neuzen in de dirs )

Nee toch? Als je in je configuratie iets als "<loadingIcon>icoonA.ico</loadingIcon>" hanteert hoef je toch nooit icoonB.ico mee te leveren?

ThaStealth schreef op maandag 18 oktober 2010 @ 15:39:
Jep dat is mogelijk, alleen moet ik dan nog met configs/directives werken om aan te geven dat hij een bepaalde versie moet gaan bouwen

Nee, want je build de hele solution, en beide executables zullen dan worden gecompileerd.

[jip_86]

Jep, maar dan moeten alle 2 de files erbij geleverd worden, en das iets wat we liever niet doen (mocht iemand beginnen rond te neuzen in de dirs )

Zo veel werk is het toch niet om even delete te doen? Sowieso is er meer een app.config. Dan moet je een config gaan bouwen om te configureren welke config je nodig hebt

Andere optie is een eigen build tool te maken. Met msbuild is dat wel mogelijk. Daarin kun je dan voor klant 1 en 2 en de volgende 200 klanten een definitie aanmaken wat je tool moet doen.

Dus voor klant a word het dan zo iets:
- selecteer instellingen voor klant a
- create dir voor klant a
- build code uit ontwikkelomgeving met mbsbuild
- copy logo klant a
- write config klant a

In je tool moet je dan wat settings instellen. Als output dir, gewenst logo, klantnaam enz.

Twee keer je code onderhouden moet je echt niet aan gaan beginnen. 2 klanten zal het per ongeluk wel goed gaan maar bij 10 of 20 echt niet meer.

[codeneos]

Als je alles hardcoded wilt hebben maak je toch gewoon een base applications die op zijn beurt weer een satelite assembly laad tijdens runtime. Dus een soort van plugin met klant specifieke settings.

Je hebt dus in de shared code een interface welke specificeert wat de voor dingen er in de klant specifieke plugin in aanwezig moet zijn, denk aan andere licentie functie, andere logo, andere register locaties, noem maar op. De shared code bevat ook een dummy implementatie van de interface zodat je ook kan runnen zonder klant specific DLL.

Je hebt dus alles in je shared code staan behalve de klant specifieke dingen, die laad je tijdens runtime. Afhankelijk van hoeveel werk je er voor wilt doen kan je er ook voor kiezen om dynamisch een class te maken (met reflection emit) zodat de plugin niet de version afhankelijk is. Je vangt dan niet bestaande functies/properties op met een default implementatie.

Voorbeeldje:

C#:

logoImage.Source = ClientSettings.Logo;

Waar ClientSettings de static class is die opzichzelf de onderliggende plugin assembly laad en anders de default waarde terug geeft. Je initialized de static class natuurlijk bij het opstarten van de app met iets als:

C#:

ClientSettings.Initialize("localized_client_settings.dll");

[ Voor 18% gewijzigd door codeneos op 18-10-2010 16:32 . Reden: Voorbeeldje geadd ]