none
Finding a non-executing application RRS feed

  • General discussion

  • I am designing a plugin system for a managed host and managed plugins for it. I want to design a way for the plugin installer to register itself with the host. One possibilty I have thought of is a class library. I can develop a plugin manager as a class library that both the host and the plugin could use. The plugin installer could call the manager to register the existance of the plugin. I assume that a msi setup can call a managed class library somehow. Should this work?

    Is there a better way to do what I need to do? The critical requirement is that the plugin installer needs to be able to find the host, whether the host is executing or not.



    Sam Hobbs
    SimpleSamples.Info

    • Changed type Simple Samples Saturday, December 29, 2012 8:29 AM No one has anything useful to add
    Thursday, December 27, 2012 3:32 AM

All replies

  • You can create a folder like 'plugins'. Put all your plugin DLLs in this folder. Then when the host launches, it will load all DLLs in 'plugins' folder and invoke members using reflection.

    I hope this makes sense.


    Please mark this post as answer if it solved your problem. Happy Programming!

    Thursday, December 27, 2012 7:46 AM
  • Of course that makes sense. It is the typical way that plugins are done. I don't need help figuring that out. It either requires the user to know where the plugins folder is at or it requires the user to install the host in a certain location. I am designing something more flexible and convenient for the user.


    Sam Hobbs
    SimpleSamples.Info

    Thursday, December 27, 2012 11:07 AM
  • Hi Sam,

    Thank you for your contribution on this forum.

    How about the registry way? I mean: 

    Write your add-in location in the registry key of the application;

    Or write your add-in location in a registry key which the application will check it when it starts.

    I hope this will be helpful.


    Mike Feng
    MSDN Community Support | Feedback to us
    Develop and promote your apps in Windows Store
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Friday, December 28, 2012 5:59 AM
    Moderator
  • The question is, how do I find the application? After finding the application, I could use the registry or the app.config file or many other possibilities. I am asking what I can provide the plugin developer that will enable the plugin installer to find the host application.


    Sam Hobbs
    SimpleSamples.Info

    Friday, December 28, 2012 6:18 AM
  • So, you are saying that a type in your plugin should register itself to the host  rather than host searching for plugins - right?

    If yes then I don't think you can do it. Because, to register itself with the host, the plugin code must already be running so that you can pass an instance of plugin to host. But, plugin being DLL, which can't run on it's own, cannot do that. Isn't it?

    On the other hand if you say the plugin installer should register the plugin with host application, the that is also not possible because of the same above reason.

    Please let me know if I am getting it wrong.


    Please mark this post as answer if it solved your problem. Happy Programming!

    Friday, December 28, 2012 7:16 AM
  • "The question is, how do I find the application?"

    Tipically your application installer writes the installation path of the application somewhere in registry, say HKLM\Software\CompanyName\AppName\InstallationPath.

    The plugin installer can retrieve the path from registry and do whatever it needs to register the plugin.

    Friday, December 28, 2012 7:29 AM
    Moderator
  • So, you are saying that a type in your plugin should register itself to the host  rather than host searching for plugins - right?

    If yes then I don't think you can do it. Because, to register itself with the host, the plugin code must already be running so that you can pass an instance of plugin to host. But, plugin being DLL, which can't run on it's own, cannot do that. Isn't it?

    No I did not suggest that. I understood what you are saying before beginning this discussion.

    On the other hand if you say the plugin installer should register the plugin with host application, the that is also not possible because of the same above reason.

    I do not understand why not. The installer would be running so the previous explanation does not apply. Note that if I said "register itself" then that is a little misleading. I meant that the installer would register the plugin.



    Sam Hobbs
    SimpleSamples.Info


    Friday, December 28, 2012 5:31 PM
  • Tipically your application installer writes the installation path of the application somewhere in registry, say HKLM\Software\CompanyName\AppName\InstallationPath.

    The plugin installer can retrieve the path from registry and do whatever it needs to register the plugin.

    I know. But how does it find the application? I am hoping to get guidance from someone with experience.

    I know I can use the Win32_Product class of WMI to find an application. I also know I can use the MSI API (such as MsiGetProductInfo and MsiEnumProducts) to find applications. If someone is experienced with those then it would help to get guidance about them. For one thing, use of the product code to find an application seems very reliable but I am not sure it would support multiple versions and that might result in a big design flaw in the future.

    I think however that a class library plugin manager is more flexible. Does anyone know of a reason that would not work or something better for some reason?



    Sam Hobbs
    SimpleSamples.Info

    Friday, December 28, 2012 5:47 PM
  • On the other hand if you say the plugin installer should register the plugin with host application, the that is also not possible because of the same above reason.

    See Walkthrough: Creating a Custom Action. I think that shows creation of a custom action that is managed code. I hope it shows how I can call a class library from a setup. Hopefully I can call the same class library from the setup as the host does and the class library can use its install directory or something like that for the "registry". In this context, the registry is not the system registry; it could be just a list of paths with filenames of the plugin DLLs.

    Does anyone see a problem with doing that?



    Sam Hobbs
    SimpleSamples.Info

    Saturday, December 29, 2012 2:09 AM
  • "But how does it find the application?"

    You mean how does it find if the application is installed? Simple, if the registry key exists then the application is installed.

    "I know I can use the Win32_Product class of WMI to find an application. I also know I can use the MSI API ..."

    Yes, you could do that too. But IMO it is more complicated than it's worth.

    "I think however that a class library plugin manager is more flexible."

    What exactly do you mean by "flexibile" in this case?

    "Does anyone know of a reason that would not work or something better for some reason?"

    It should work but it's more complicated than simply dropping the dll in a "plugins" folder. Since it's more complicated you'd better have a good reason to do this. This "flexible" thing is too vague.

    Saturday, December 29, 2012 7:44 AM
    Moderator
  • You mean how does it find if the application is installed? Simple, if the registry key exists then the application is installed.

    What registry key? I already understood what you are saying here. I do not know the details. Where is the documentation of what to use as the registry key? If you do not know then that is okay, but I already understood the general concept of the registry.

    Yes, you could do that too. But IMO it is more complicated than it's worth.

    In other words, you do not know an elegant solution. That is okay; you can say that.

    What exactly do you mean by "flexibile" in this case?

    Extensible and requiring as little maintenance as possible; the common developer's definition of flexible.

    It should work but it's more complicated than simply dropping the dll in a "plugins" folder. Since it's more complicated you'd better have a good reason to do this. This "flexible" thing is too vague.

    Complicated for who? Microsoft and other developers often do complicated things to make software easier to use. For example, Linux often requires users to be more technical. Windows is more popular because Microsoft does more to make Windows easier to use.


    Sam Hobbs
    SimpleSamples.Info



    Saturday, December 29, 2012 8:25 AM
  • "I do not know the details. Where is the documentation of what to use as the registry key?"

    It's your app, you define the registry key.

    "In other words, you do not know an elegant solution. That is okay; you can say that."

    No, I don't know "elegant" solutions. I only know solutions that work, are simple, are reliable etc. And ultimately there aren't that many solutions and they all revolve around having a known piece of information that helps finding the installed app:

    • known registry key
    • known installation path (less usual, it would have to be relative to some known OS path like Program Files, Common Files)
    • other information that indirectly relies on one of the above: COM CLSID, MSI product code, .NET assembly strong name (with assembly in GAC)

    You can decide which solution is elegant for yourself.

    "Complicated for who?"

    Well, I assumed that you are talking about plugin developers. End users will probably only see the application installer and plugin installer, they don't know or care how the plugin installer finds the application.

    Saturday, December 29, 2012 9:21 AM
    Moderator
  • Mike, let's just agree to disagree. Your design philosophy is different from mine. I won't be judgemental of yours if you won't be judgemental of mine. You seem to want to me judgemental and that does not help. I have attempted to explain my design philosophy. One difference is that, in my experience, some designs are better than others. Since we disagree on that critical point, we must agree to disagree.


    Sam Hobbs
    SimpleSamples.Info

    Saturday, December 29, 2012 9:48 AM
  • It's not necessarily that I disagree, it's just that I don't see a good reason for doing things the way you describe. But maybe you have your own reasons beyond vague stuff like "flexible" and ultimately it's your choice.

    In any case, no matter what you do you'll need one of the mentioned ways to locate the application/plugin manager etc.

    Saturday, December 29, 2012 10:01 AM
    Moderator
  • See List Products, Properties, Features, and Components (Windows). That describes a script that lists the data relevant to this discussion. If someone had said that the installer has a product id, publisher and product name that can be used to locate installed software, then I would have known that they can help me. No one mentioned that; instead they were vague, saying things like the application's whatever. I am hoping for some guidance from someone familiar with the installer data. Instead, people tend to blame me for being vague. If you do not have answers, I understand, but don't blame me if you do not.

    The installer has data that is clearly designed for things like this. I want help finding the data that has been provided for the purpose I need it for. I do not want to be a hacker that does what works; I want to use documented solutions.

    Yes, there is installer data in the registry for "components". What is the documented way to use it? If the answer is in the Windows Installer SDK documentation clearly enough to find then I will find it; I don't need help with that now. If someone had provided experienced guidance in that direction sooner then that would have helped.



    Sam Hobbs
    SimpleSamples.Info

    Sunday, December 30, 2012 2:18 AM
  • "No one mentioned that; instead they were vague, saying things like the application's whatever."

    So what's you are asking in fact is MSI related and you're asking that in a forum that has nothing to do with MSI. And now you're complaining that you don't get good answers. Makes sense...

    Sunday, December 30, 2012 7:31 AM
    Moderator
  • Again, you can't help so you criticize. You are someone that must have the last post, yet the only thing you can say is a criticism. Go ahead and make the final post, I will avoid replying unless you have something useful to say.


    Sam Hobbs
    SimpleSamples.Info

    Tuesday, January 1, 2013 6:53 PM
  • you're asking that in a forum that has nothing to do with MSI.

    I intentionally did not want to limit the solution  to the Windows Installer. If the answer is msi then I can create a new question in an appropriate forum. Note that this forum is used for many installation questions, such as the following. Note that in "Create a registry key using Installer class and add in custom actions (Custom installation in .net C#)" Rudedog2 moved the question to this forum. Phil Wilson says that question should be in the other forum, but the important thing is that for a question that is not entirely an installer question, I think I made a good decision. Since I will likely use the Windows Installer for most of the solution, I will ask about that in the "ClickOnce and Setup&Deployment projects" forum.




    Sam Hobbs
    SimpleSamples.Info

    Tuesday, January 1, 2013 7:52 PM