[VB.Net] Compile Extra References

[apronk]

Eigenlijk een simpele vraag maar ik heb nogal wat references in mijn project zitten zoals bijv. InterOp.ADODB.dll enz. Nu als ik mijn Solution build zet hij ze los bij m'n tot executable gecompileerde code. Ik zou dat graag IN mijn gecompileerde code willen zien i.p.v. losse DLL's die ik er bij moet zetten.
Kan iemand mij daarmee op weg helpen ?

[RobIII]

Dan wil ik eigenlijk eerst eens weten waarom je dat zou willen? Kun je niet beter een setupje maken zodat alles in 1 file zit (voor downloads e.d.) maar dat het na installatie gewoon op de plek staat waar 't hoort?

[Bjornski]

Check even deze website over ILMerge.exe.

Is trouwens ook prima te googelen hoor. Succes!

[apronk]

RobIII schreef op woensdag 08 juli 2009 @ 14:03:
Dan wil ik eigenlijk eerst eens weten waarom je dat zou willen? Kun je niet beter een setupje maken zodat alles in 1 file zit (voor downloads e.d.) maar dat het na installatie gewoon op de plek staat waar 't hoort?

Hoi, Normaal gesproken wel. Tis meer omdat ik het graag wil.
Ben een project aan t maken die veel van ADO gebruik maakt en wil bij mn executable geen 5-tal externe DLL's hebben.
Wil t allemaal netjes in 1 executable. Ik houd gewoon niet van externe dependencies :-)

[Haan]

Als je de executable alleen op je eigen pc runt, zet je ze gewoon in de GAC

[apronk]

Haan schreef op woensdag 08 juli 2009 @ 14:17:
Als je de executable alleen op je eigen pc runt, zet je ze gewoon in de GAC

Uiteindelijk komt t op meerdere PC's...

[Remus]

apronk schreef op woensdag 08 juli 2009 @ 14:14:
[...]


Hoi, Normaal gesproken wel. Tis meer omdat ik het graag wil.
Ben een project aan t maken die veel van ADO gebruik maakt en wil bij mn executable geen 5-tal externe DLL's hebben.
Wil t allemaal netjes in 1 executable. Ik houd gewoon niet van externe dependencies :-)

Het is simpeler en over het algemeen beter om de DLLs los te laten zitten (afhankelijk van de exacte werking kan je een DLL dan nog vervangen door een nieuwere versie of een debugversie). Ik begrijp niet helemaal waarom mensen altijd alles in één grote file willen proppen.

Sterker nog, als een DLL geïnstalleerd wordt/is in het OS kan het nog bepaalde voordelen opleveren omdat DLLs in zo'n situatie gedeeld worden en dus - indien in gebruik door meerdere applicaties - veelal maar één keer ingeladen hoeven te worden.

[apronk]

Remus schreef op woensdag 08 juli 2009 @ 14:42:
[...]

Het is simpeler en over het algemeen beter om de DLLs los te laten zitten (afhankelijk van de exacte werking kan je een DLL dan nog vervangen door een nieuwere versie of een debugversie). Ik begrijp niet helemaal waarom mensen altijd alles in één grote file willen proppen.

Sterker nog, als een DLL geïnstalleerd wordt/is in het OS kan het nog bepaalde voordelen opleveren omdat DLLs in zo'n situatie gedeeld worden en dus - indien in gebruik door meerdere applicaties - veelal maar één keer ingeladen hoeven te worden.

Over het algemeen ben ik het met je eens. Maar mijn Applicatie is zo klein en gebruikt alleen maar ADODB.RecordSet en ADODB.Connection dus om daar nou een hele DLL voor de laden is eigenlijk zónde.
Gebruikt ook nog een specifieke DLL voor het managen van BITS.
Nu zou ik het ook via CreateObject() kunnen doen, maar dan ben je afhankelijk van welke versie er is geinstalleerd op de betreffende PC.

[eek]

Waarom wil je het perse in een bestand? Omdat je het dan makkelijker aan je gebruikers kan geven? Misschien is ClockOnce iets voor jou

[RobIII]

ADODB.RecordSet en ADODB.Connection zitten toch sowieso al in de GAC? Waarom zou je die als losse DLL danwel "in je executable" willen opnemen

eek schreef op woensdag 08 juli 2009 @ 23:00:
Waarom wil je het perse in een bestand? Omdat je het dan makkelijker aan je gebruikers kan geven? Misschien is ClockOnce iets voor jou

ClickOnce; en je kunt natuurlijk ook een "gewone" setup maken vanuit VS en anders kun je nog kijken naar Inno Setup die ik persoonlijk wel fijn vind of 1 van de andere 1001 alternatieven

[ Voor 75% gewijzigd door RobIII op 08-07-2009 23:06 ]

[apronk]

RobIII schreef op woensdag 08 juli 2009 @ 23:04:
ADODB.RecordSet en ADODB.Connection zitten toch sowieso al in de GAC? Waarom zou je die als losse DLL danwel "in je executable" willen opnemen

[...]

ClickOnce; en je kunt natuurlijk ook een "gewone" setup maken vanuit VS en anders kun je nog kijken naar Inno Setup die ik persoonlijk wel fijn vind of 1 van de andere 1001 alternatieven

Omdat zodra ik ADODB toevoeg het als InterOp.ADODB.dll los toegevoegd word aan mijn project.
Daarbij heb ik al uitgelegd dat ik zo weinig gebruik maak van die toevoegingen en mijn programmatje zo klein mogelijk probeer te houden. Ik stel jullie meningen erg op prijs, maar ik vraag alleen om een manier om ze IN mijn executable te compilen, en niet om een setup te maken, dat kan ik zelf ook wel verzinnen.

Ik wil eigenlijk meer zoals met C++ een #include hebben i.p.v. een DLL nodig te hebben.
Zou mooier zijn als VB .Net alleen de info die ik nodig heb uit het .Net object er uit haalde en importeert in mijn project...

[Haan]

apronk schreef op donderdag 09 juli 2009 @ 09:18:
[...]


Omdat zodra ik ADODB toevoeg het als InterOp.ADODB.dll los toegevoegd word aan mijn project.
Daarbij heb ik al uitgelegd dat ik zo weinig gebruik maak van die toevoegingen en mijn programmatje zo klein mogelijk probeer te houden. Ik stel jullie meningen erg op prijs, maar ik vraag alleen om een manier om ze IN mijn executable te compilen, en niet om een setup te maken, dat kan ik zelf ook wel verzinnen.

Hamvraag: runt je programma niet toevallig ook zonder dat die dll bij de executable staat? Die interop assemblies worden als het goed is inderdaad aan de GAC toegevoegd als je Office installeert.

[Dricus]

Het lijkt erop dat je gebruik maakt van het "oude" ADO, dat je via COM benadert. Op het moment dat je COM DLL's referenced in je .NET project wordt er een soort "wrapper" assembly gegenereerd (Interop.COMDLL.dll). Als je in plaats van ADO gebruik maakt van ADO.NET heb je dit probleem niet omdat dit een native .NET API is.

[apronk]

Dricus schreef op donderdag 09 juli 2009 @ 10:37:
Het lijkt erop dat je gebruik maakt van het "oude" ADO, dat je via COM benadert. Op het moment dat je COM DLL's referenced in je .NET project wordt er een soort "wrapper" assembly gegenereerd (Interop.COMDLL.dll). Als je in plaats van ADO gebruik maakt van ADO.NET heb je dit probleem niet omdat dit een native .NET API is.

Het probleem ligt ook niet zo zeer bij ADO maar meer bij BITS.
Voor BITS is er geen Native .Net assembly maar een soort wrapper die door de jongens van MSDN gemaakt is. BackgroundCopyManager in C++ is er wel een header genaamd bits.h helaas is hier geen .Net assembly voor

De BackgroundCopyManager.DLL maak ik dus gebruik van. En word dus bij het bouwen van het project als Aparte DLL erbij gezet. Omdat het een 3rd Party dll is in feite. Tenzij iemand een Native manier wet om van BITS gebruik te maken wil ik deze graag IN mijn executable hebben.