|
web
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Accessing dlls at runtimeHi
I have a set of classes (application framework) in the form of a dll that I have set to install in [Common Files]\[My Folder] folder by default on the target user's pcs. This path can also be changed by the user when running the setup on their pcs. The problem is how do I tell me main apps (which get installed separately) to find out the location of the dll and use its reference on the target pcs? Thanks Regards To me this appears to be one of those "if it hurts, don't do it" things.
Users typically get to choose only the primary application folder (TARGETDIR in a VS setup) and supporting infrastructure goes where it needs to be to have everything work. I assume you've already given the user a choice for the primary application folder, so does that mean you have another dialog for the location of this Dll? Or is this a separate setup? I really think this is one of those times where you should just put it where it should be, and that's common with supporting infrastructure files. Delete the dialog that offers the choice! -- Show quoteHide quotePhil Wilson [Microsoft MVP-Windows Installer] "John" <John@nospam.infovis.co.uk> wrote in message news:eAcpz3meFHA.3028@TK2MSFTNGP09.phx.gbl... > Hi > > I have a set of classes (application framework) in the form of a dll that > I have set to install in [Common Files]\[My Folder] folder by default on > the target user's pcs. This path can also be changed by the user when > running the setup on their pcs. > > The problem is how do I tell me main apps (which get installed separately) > to find out the location of the dll and use its reference on the target > pcs? > > Thanks > > Regards > Hi Phil
The app framework and actual apps are separate setups. The reason I did that was to keep the apps "clean" and not having to include the framework source in each project. Also people who do not have access to framework source code (sometimes preferable) will also be able to develop around the framework, if this works. I guess one way is to store the framework dll path in a registry key on install. What I don't know is how to reference this in my app at design and runtime. Thanks Regards Show quoteHide quote "Phil Wilson" <pdjwilson@nospam.cox.net> wrote in message news:%23VBSipneFHA.3712@TK2MSFTNGP12.phx.gbl... > To me this appears to be one of those "if it hurts, don't do it" things. > Users typically get to choose only the primary application folder > (TARGETDIR in a VS setup) and supporting infrastructure goes where it > needs to be to have everything work. I assume you've already given the > user a choice for the primary application folder, so does that mean you > have another dialog for the location of this Dll? Or is this a separate > setup? I really think this is one of those times where you should just put > it where it should be, and that's common with supporting infrastructure > files. Delete the dialog that offers the choice! > -- > Phil Wilson > [Microsoft MVP-Windows Installer] > "John" <John@nospam.infovis.co.uk> wrote in message > news:eAcpz3meFHA.3028@TK2MSFTNGP09.phx.gbl... >> Hi >> >> I have a set of classes (application framework) in the form of a dll that >> I have set to install in [Common Files]\[My Folder] folder by default on >> the target user's pcs. This path can also be changed by the user when >> running the setup on their pcs. >> >> The problem is how do I tell me main apps (which get installed >> separately) to find out the location of the dll and use its reference on >> the target pcs? >> >> Thanks >> >> Regards >> > > why not install it to the GAC? the Runtime looks there first when it
attempts to bind. Hmmm...this sounds interesting. Where can I get more info on how to do
this?? Thanks Regards Show quoteHide quote "stand__sure" <stand__s***@hotmail.com> wrote in message news:1119854467.156876.218560@g44g2000cwa.googlegroups.com... > why not install it to the GAC? the Runtime looks there first when it > attempts to bind. > OK, installed it in gac. Now how do I access it in my other apps?
Thanks Regards Show quoteHide quote "stand__sure" <stand__s***@hotmail.com> wrote in message news:1119854467.156876.218560@g44g2000cwa.googlegroups.com... > why not install it to the GAC? the Runtime looks there first when it > attempts to bind. > Well if "access" means "link to when the programs run", it will just work
because the GAC is the the first place default location where the runtime will look for a dependent assembly. Of course the assembly must match the client requirements for assemblyversion, strong name etc. There are some gotchas with updating files installed by MSI into the GAC, so I'd ensure you figure out how to replace it with a new version before committing to using the GAC. The fixed common location will be easier to update than the GAC. -- Show quoteHide quotePhil Wilson [Microsoft MVP-Windows Installer] Definitive Guide to Windows Installer http://apress.com/book/bookDisplay.html?bID=280 "John" <John@nospam.infovis.co.uk> wrote in message news:%23FExvD3eFHA.1136@TK2MSFTNGP12.phx.gbl... > OK, installed it in gac. Now how do I access it in my other apps? > > Thanks > > Regards > > "stand__sure" <stand__s***@hotmail.com> wrote in message > news:1119854467.156876.218560@g44g2000cwa.googlegroups.com... >> why not install it to the GAC? the Runtime looks there first when it >> attempts to bind. >> > > So if the dll is installed in the [Prorgam files]\[Common Files]\[My Class]
folder then how can I access the dll regardless of which drive the [Prorgam files]\[Common Files]\[My Class] folder is on? Thanks Regards Show quoteHide quote "Phil Wilson" <pdjwilson@nospam.cox.net> wrote in message news:O3ZQbl$eFHA.1036@tk2msftngp13.phx.gbl... > Well if "access" means "link to when the programs run", it will just work > because the GAC is the the first place default location where the runtime > will look for a dependent assembly. Of course the assembly must match the > client requirements for assemblyversion, strong name etc. > > There are some gotchas with updating files installed by MSI into the GAC, > so I'd ensure you figure out how to replace it with a new version before > committing to using the GAC. The fixed common location will be easier to > update than the GAC. > -- > Phil Wilson > [Microsoft MVP-Windows Installer] > Definitive Guide to Windows Installer > http://apress.com/book/bookDisplay.html?bID=280 > > "John" <John@nospam.infovis.co.uk> wrote in message > news:%23FExvD3eFHA.1136@TK2MSFTNGP12.phx.gbl... >> OK, installed it in gac. Now how do I access it in my other apps? >> >> Thanks >> >> Regards >> >> "stand__sure" <stand__s***@hotmail.com> wrote in message >> news:1119854467.156876.218560@g44g2000cwa.googlegroups.com... >>> why not install it to the GAC? the Runtime looks there first when it >>> attempts to bind. >>> >> >> > > Well your main problem is that the best place for dependent assemblies to be
installed is right next to the app that uses it. You've got an unusual deployment model where an assembly which is required for one or more apps is likely to be installed in some completely random folder, and that's not the usual deployment model that people use, and that's why someone suggested the GAC. If client programs want to cleanly instantiate objects from your assembly with the deployment model you're using, you don't have any reasonable choice except the GAC. Dependent assemblies pretty much need to be in the same directory as the client app, or in a subfolder via redirection, or in the GAC. If you want some other fixed location, you can tell your clients that they need to do some kind of assembly load from somewhere in Environment.GetFolderPath (Environment.SpecialFolder.CommonApplicationData) and instantiate objects that way, but that isn't the usual way. -- Show quoteHide quotePhil Wilson [MVP Windows Installer] ---- "John" <John@nospam.infovis.co.uk> wrote in message news:%23qkulAAfFHA.3836@tk2msftngp13.phx.gbl... > So if the dll is installed in the [Prorgam files]\[Common Files]\[My > Class] folder then how can I access the dll regardless of which drive the > [Prorgam files]\[Common Files]\[My Class] folder is on? > > Thanks > > Regards > > > "Phil Wilson" <pdjwilson@nospam.cox.net> wrote in message > news:O3ZQbl$eFHA.1036@tk2msftngp13.phx.gbl... >> Well if "access" means "link to when the programs run", it will just work >> because the GAC is the the first place default location where the runtime >> will look for a dependent assembly. Of course the assembly must match the >> client requirements for assemblyversion, strong name etc. >> >> There are some gotchas with updating files installed by MSI into the GAC, >> so I'd ensure you figure out how to replace it with a new version before >> committing to using the GAC. The fixed common location will be easier to >> update than the GAC. >> -- >> Phil Wilson >> [Microsoft MVP-Windows Installer] >> Definitive Guide to Windows Installer >> http://apress.com/book/bookDisplay.html?bID=280 >> >> "John" <John@nospam.infovis.co.uk> wrote in message >> news:%23FExvD3eFHA.1136@TK2MSFTNGP12.phx.gbl... >>> OK, installed it in gac. Now how do I access it in my other apps? >>> >>> Thanks >>> >>> Regards >>> >>> "stand__sure" <stand__s***@hotmail.com> wrote in message >>> news:1119854467.156876.218560@g44g2000cwa.googlegroups.com... >>>> why not install it to the GAC? the Runtime looks there first when it >>>> attempts to bind. >>>> >>> >>> >> >> > > 
Other interesting topics
C# to VB crossover questions
hide control based on SQLS2K column level permission Update Element in ArrayList Structure GetType and ApplicationClass About MessageQueue Problem Large fonts setting (120DPI) Add record to Access Databases Q: Status Bar Vanishes Public vs Shared Using JPG stills to make a "Video" file |
|||||||||||||||||||||||
