• Visitors can check out the Forum FAQ by clicking this link. You have to register before you can post: click the REGISTER link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. View our Forum Privacy Policy.
  • Want to receive the latest contracting news and advice straight to your inbox? Sign up to the ContractorUK newsletter here. Every sign up will also be entered into a draw to WIN £100 Amazon vouchers!

.net automation or maybe com interface?

Collapse
X
  •  
  • Filter
  • Time
  • Show
Clear All
new posts

    .net automation or maybe com interface?

    I have written a sizeable form application, which displays various information for clientco.

    Id now like another form application to be able to start this application if its not started, or if it is already running to take control of it and make it change which record its showing.

    So i added a Com Class to the application, made sure that make assembly visible was checked, created a few public methods.

    But Im blown if I can make another application be able to instantiate an object pointing to it, its late binding Im trying. If I do make a reference to the exe, I can see the object and public methods.

    I spent a lot of time searching google, none of the examples seem to apply, and Im not sure if its now called something completely different that Im searching for the wrong words.

    Any tips or even names of techniques would be greatly appreciated.

    #2
    Can you clarify, is this a 'COM noob' question or something more specific I've missed? If the former you have to get class IDs registered and such crud.

    Are both EXEs always on the same physical machine?

    If you're working in .NET, you might consider looking at WCF which essentially is 'new COM' - COM is just ugly and unfriendly.
    Originally posted by MaryPoppins
    I'd still not breastfeed a nazi
    Originally posted by vetran
    Urine is quite nourishing

    Comment


      #3
      Originally posted by d000hg View Post
      Can you clarify, is this a 'COM noob' question or something more specific I've missed? If the former you have to get class IDs registered and such crud.

      Are both EXEs always on the same physical machine?

      If you're working in .NET, you might consider looking at WCF which essentially is 'new COM' - COM is just ugly and unfriendly.
      It might be a noob problem, in the past I have written web hosted DLLs for other projects which just seem to work. I have added a new Com Class which has automatically created all the class IDs.

      Both EXEs live in the same directory on the server.

      I looked at WCF and thought I didnt want to learn another way of doing what I already can do with less functionality than I already have for no benefit. I tend to find this with most Microsoft new ideas, must be getting old and jaded.

      I have found an example that describes exactly what i want to do, so hopefully can work out what Im missing from that.

      .NET Appications Automation - CodeProject

      Comment


        #4
        Its no good, I cant do it. About 8 hours spent on this so far.

        Comment


          #5
          I invoke d000hg's law: "the longer it takes to track down a software bug, the more embarrassingly simple it is"
          Originally posted by MaryPoppins
          I'd still not breastfeed a nazi
          Originally posted by vetran
          Urine is quite nourishing

          Comment


            #6
            Originally posted by escapeUK View Post
            Its no good, I cant do it. About 8 hours spent on this so far.
            If you're just trying to kick off an EXE from a separate .Net application, here's how you do that:

            Code:
            
            
            using System.Diagnostics;
            
            namespace ScribbleFormsApp
            {
                public static class SpawnAProcess
                {
                    private void Start()
                    {
                        Process.Start(@"C:\MyPath\MyExecutable.exe");
                    }
                }
            }
            If you want to make sure only one instance of your application runs at any one time, make sure the EXE contains a Singleton.

            Comment


              #7
              Originally posted by Gentile View Post
              If you're just trying to kick off an EXE from a separate .Net application, here's how you do that:

              Code:
              
              
              using System.Diagnostics;
              
              namespace ScribbleFormsApp
              {
                  public static class SpawnAProcess
                  {
                      private void Start()
                      {
                          Process.Start(@"C:\MyPath\MyExecutable.exe");
                      }
                  }
              }
              If you want to make sure only one instance of your application runs at any one time, make sure the EXE contains a Singleton.
              I imagine if you want to make sure that only one instance of your application runs at any one time you employ a named windows mutex rather than a singleton because a singleton (or a static member) is only unique to a process yet shared amoungst the threads belonging to that process.

              Not that it's what being asked. It seems like a registration issue with the COM object. It's been too long for me to remember exactly what needs to be done here. I think you use the command line util regsvr32 to register your .exe with windows and then you should be able to make the CreateObject call for late binding.

              edit: For the .NET exe it seems like you need regasm rather than regsvr32 : http://msdn.microsoft.com/en-us/libr...=vs.90%29.aspx
              Last edited by Jaws; 20 September 2012, 20:06.

              Comment


                #8
                Originally posted by Jaws View Post
                I imagine if you want to make sure that only one instance of your application runs at any one time you employ a named windows mutex rather than a singleton because a singleton (or a static member) is only unique to a process yet shared amoungst the threads belonging to that process.

                Not that it's what being asked. It seems like a registration issue with the COM object. It's been too long for me to remember exactly what needs to be done here. I think you use the command line util regsvr32 to register your .exe with windows and then you should be able to make the CreateObject call for late binding.

                edit: For the .NET exe it seems like you need regasm rather than regsvr32 : Assembly Registration Tool (Regasm.exe)
                You are correct in that Im already starting the application, at the moment I am passing the record I want it to open simply via a command line parameter. So at the moment I am creating another instance of the application with each click, I want the already called application to just move its record.

                Im not familiar with regasm, which I will try tomorrow, but from what I read I should just have to tick the "Make assembly com visible" which I have.

                If it doesnt click soon, Ill just end up using a very low tech filesystemwatcher to monitor a temporary directory somewhere and change record based on that.
                Last edited by escapeUK; 20 September 2012, 20:53.

                Comment


                  #9
                  Originally posted by escapeUK View Post
                  You are correct in that Im already starting the application, at the moment I am passing the record I want it to open simply via a command line parameter. So at the moment I am creating another instance of the application with each click, I want the already called application to just move its record.

                  Im not familiar with regasm, which I will try tomorrow, but from what I read I should just have to tick the "Make assembly com visible" which I have.

                  If it doesnt click soon, Ill just end up using a very low tech filesystemwatcher to monitor a temporary directory somewhere and change record based on that.
                  I do think dooohg has a point with WCF if you're using two .NET apps.

                  This tutorial: WCF Tutorial - Basic Interprocess Communication | Switch on the Code could probably be adapted to do what you want which I gather is calling a method on your running process.

                  Comment


                    #10
                    Originally posted by Jaws View Post
                    I do think dooohg has a point with WCF if you're using two .NET apps.

                    This tutorial: WCF Tutorial - Basic Interprocess Communication | Switch on the Code could probably be adapted to do what you want which I gather is calling a method on your running process.
                    I read his post as WFP, the peril of acronyms! Just reading your link now, thanks

                    You know how in code its really easy to open Excel, create a spreadsheet, etc etc. Thats what I imagined making my app be able to be controlled like Excel is.

                    Comment

                    Working...
                    X