 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / .NET Framework / Setup / June 2005Accessing dlls at runtime
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 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!  SignaturePhil Wilson [Microsoft MVP-Windows Installer] > Hi > [quoted text clipped - 10 lines] > > 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 > 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 [quoted text clipped - 19 lines] >> >> 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 > 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 > 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. SignaturePhil Wilson [Microsoft MVP-Windows Installer] Definitive Guide to Windows Installer http://apress.com/book/bookDisplay.html?bID=280 > OK, installed it in gac. Now how do I access it in my other apps? > [quoted text clipped - 4 lines] >> 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 > 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 [quoted text clipped - 13 lines] >>> 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. SignaturePhil Wilson [MVP Windows Installer] ---- > 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 [quoted text clipped - 21 lines] >>>> why not install it to the GAC? the Runtime looks there first when it >>>> attempts to bind. Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.