Toon posts:

[VS 2008] Applicatie compileren naar 2 verschillende namen

Pagina: 1
Acties:

  • ThaStealth
  • Registratie: oktober 2004
  • Laatst online: 19-09 09:55
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?

Mess with the best, die like the rest


  • Haan
  • Registratie: februari 2004
  • Nu online

Haan

dotnetter

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.

Kater? Eerst water, de rest komt later
Last.fm profiel


  • CodeCaster
  • Registratie: juni 2003
  • Niet online

CodeCaster

👌👀 good shit ✔💯

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

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

As always, we are nailed to a cross of our own construction.


  • jip_86
  • Registratie: juli 2004
  • Laatst online: 23:57
Naam en logo configureerbaar maken en uitleveren met verschillende configbestanden.

Dus:
config1
- bedrijfsnaam a
- logo_a.jpg

config2
- bedrijfsnaam b
- logo_b.jpg

  • MLM
  • Registratie: juli 2004
  • Laatst online: 19-01-2018

MLM

aka Zolo

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)

-niks-


  • ThaStealth
  • Registratie: oktober 2004
  • Laatst online: 19-09 09:55
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

Mess with the best, die like the rest


  • CodeCaster
  • Registratie: juni 2003
  • Niet online

CodeCaster

👌👀 good shit ✔💯

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.

As always, we are nailed to a cross of our own construction.


  • jip_86
  • Registratie: juli 2004
  • Laatst online: 23:57
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 :P

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
  • Registratie: augustus 2004
  • Laatst online: 00:59
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#:
1
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#:
1
ClientSettings.Initialize("localized_client_settings.dll");

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

http://www.tweakers.net/gallery/119170/sys

Pagina: 1


Nintendo Switch (OLED model) Apple iPhone 13 LG G1 Google Pixel 6 Call of Duty: Vanguard Samsung Galaxy S21 5G Apple iPad Pro (2021) 11" Wi-Fi, 8GB ram Nintendo Switch Lite

Tweakers vormt samen met Hardware Info, AutoTrack, Gaspedaal.nl, Nationale Vacaturebank, Intermediair en Independer DPG Online Services B.V.
Alle rechten voorbehouden © 1998 - 2021 Hosting door True

Tweakers maakt gebruik van cookies

Bij het bezoeken van het forum plaatst Tweakers alleen functionele en analytische cookies voor optimalisatie en analyse om de website-ervaring te verbeteren. Op het forum worden geen trackingcookies geplaatst. Voor het bekijken van video's en grafieken van derden vragen we je toestemming, we gebruiken daarvoor externe tooling die mogelijk cookies kunnen plaatsen.

Meer informatie vind je in ons cookiebeleid.

Sluiten

Forum cookie-instellingen

Bekijk de onderstaande instellingen en maak je keuze. Meer informatie vind je in ons cookiebeleid.

Functionele en analytische cookies

Deze cookies helpen de website zijn functies uit te voeren en zijn verplicht. Meer details

janee

    Cookies van derden

    Deze cookies kunnen geplaatst worden door derde partijen via ingesloten content en om de gebruikerservaring van de website te verbeteren. Meer details

    janee