Announcement

Collapse
No announcement yet.

Has anyone had .NET success?

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

    Has anyone had .NET success?

    I appologize for cross-posting.

    I would really appreciate some advice on getting HS working in my .NET web pages. I'm getting some sort of permissions issue while trying to instantiate my HS object from the code-behind.

    I'll even buy you a beer!

    Thanks,

    Doug

    #2
    I had success with setting permissions on Homeseer.exe.

    Allow IUSR_computername and/or ASPNET read access to homeseer.exe. I think there is an IWEB_computername user as well.

    One or more of these must be set up in order for IIS to connect to homeseer.exe.

    I ended up setting all three of the above, but it might not be necessary. Try different combinations until it works...

    Comment


      #3
      firtha,

      Thanks, but I'm still 'no-go'. Could you tell me a little about your machine, development software, setup, other processes, etc?

      I'm using WinXP Pro SP1. HomeSeer, SQL Server, Norton AV, etc. is running on the same box. I've set permissions to "C:\Program Files\HomeSeer\HomeSeer.exe" as you suggested. I'm programming with VB.NET 2003. I have a simple Web project with the following code:
      -------
      Private HS As HomeSeer.Application

      Private Sub Page_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
      'Put user code to initialize the page here
      HS = New HomeSeer.Application
      End Sub
      ------------------------------------------------------

      The first line actually starts the HS application, but as soon as I get to the "HS = New..." line in the Form_Load, it bombs with the error:
      -----------------------------------------------------------
      Server Error in '/HomeSeer Web Test1' Application.

      Access is denied.
      Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.

      Exception Details: System.UnauthorizedAccessException: Access is denied.

      ASP.NET is not authorized to access the requested resource. Consider granting access rights to the resource to the ASP.NET request identity. ASP.NET has a base process identity (typically {MACHINE}\ASPNET on IIS 5 or Network Service on IIS 6) that is used if the application is not impersonating. If the application is impersonating via <identity impersonate="true"/>, the identity will be the anonymous user (typically IUSR_MACHINENAME) or the authenticated request user.

      To grant ASP.NET write access to a file, right-click the file in Explorer, choose "Properties" and select the Security tab. Click "Add" to add the appropriate user or group. Highlight the ASP.NET account, and check the boxes for the desired access.

      Source Error:

      Line 27: Private Sub Page_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
      Line 28: 'Put user code to initialize the page here
      Line 29: HS = New HomeSeer.Application
      Line 30: End Sub
      Line 31:

      Source File: c:\inetpub\wwwroot\HomeSeer Web Test1\WebForm1.aspx.vb Line: 29

      Stack Trace:

      [UnauthorizedAccessException: Access is denied.]
      HomeSeer_Web_Test1.WebForm1.Page_Load(Object sender, EventArgs e) in c:\inetpub\wwwroot\HomeSeer Web Test1\WebForm1.aspx.vb:29
      System.Web.UI.Control.OnLoad(EventArgs e) +67
      System.Web.UI.Control.LoadRecursive() +35
      System.Web.UI.Page.ProcessRequestMain() +731
      -----------------------------------------------------

      Is there anything that you changed in the Web.config file? Mine looks like this:
      ---------------------------------------------------------------------
      <?xml version="1.0" encoding="utf-8" ?>
      <configuration>

      <system.web>

      <!-- DYNAMIC DEBUG COMPILATION
      Set compilation debug="true" to insert debugging symbols (.pdb information)
      into the compiled page. Because this creates a larger file that executes
      more slowly, you should set this value to true only when debugging and to
      false at all other times. For more information, refer to the documentation about
      debugging ASP.NET files.
      -->
      <compilation defaultLanguage="vb" debug="true" />

      <!-- CUSTOM ERROR MESSAGES
      Set customErrors mode="On" or "RemoteOnly" to enable custom error messages, "Off" to disable.
      Add <error> tags for each of the errors you want to handle.

      "On" Always display custom (friendly) messages.
      "Off" Always display detailed ASP.NET error information.
      "RemoteOnly" Display custom (friendly) messages only to users not running
      on the local Web server. This setting is recommended for security purposes, so
      that you do not display application detail information to remote clients.
      -->
      <customErrors mode="RemoteOnly" />

      <!-- AUTHENTICATION
      This section sets the authentication policies of the application. Possible modes are "Windows",
      "Forms", "Passport" and "None"

      "None" No authentication is performed.
      "Windows" IIS performs authentication (Basic, Digest, or Integrated Windows) according to
      its settings for the application. Anonymous access must be disabled in IIS.
      "Forms" You provide a custom form (Web page) for users to enter their credentials, and then
      you authenticate them in your application. A user credential token is stored in a cookie.
      "Passport" Authentication is performed via a centralized authentication service provided
      by Microsoft that offers a single logon and core profile services for member sites.
      -->
      <authentication mode="Windows" />


      <!-- AUTHORIZATION
      This section sets the authorization policies of the application. You can allow or deny access
      to application resources by user or role. Wildcards: "*" mean everyone, "?" means anonymous
      (unauthenticated) users.
      -->
      <authorization>
      <allow users="*" /> <!-- Allow all users -->

      <!-- <allow users="[comma separated list of users]"
      roles="[comma separated list of roles]"/>
      <deny users="[comma separated list of users]"
      roles="[comma separated list of roles]"/>
      -->
      </authorization>

      <!-- APPLICATION-LEVEL TRACE LOGGING
      Application-level tracing enables trace log output for every page within an application.
      Set trace enabled="true" to enable application trace logging. If pageOutput="true", the
      trace information will be displayed at the bottom of each page. Otherwise, you can view the
      application trace log by browsing the "trace.axd" page from your web application
      root.
      -->
      <trace enabled="false" requestLimit="10" pageOutput="false" traceMode="SortByTime" localOnly="true" />


      <!-- SESSION STATE SETTINGS
      By default ASP.NET uses cookies to identify which requests belong to a particular session.
      If cookies are not available, a session can be tracked by adding a session identifier to the URL.
      To disable cookies, set sessionState cookieless="true".
      -->
      <sessionState
      mode="InProc"
      stateConnectionString="tcpip=127.0.0.1:42424"
      sqlConnectionString="data source=127.0.0.1;Trusted_Connection=yes"
      cookieless="false"
      timeout="20"
      />

      <!-- GLOBALIZATION
      This section sets the globalization settings of the application.
      -->
      <globalization requestEncoding="utf-8" responseEncoding="utf-8" />

      </system.web>

      </configuration>
      ---------------------------------------------------------------------------

      Trust me - You'll get that beer!!!! I just want to get this sucker working.

      Doug

      Comment


        #4
        I'll have a look at my setup this weekend. I'm not home at the moment...

        Comment


          #5
          Thanks. I look forward to any insite you can provide.

          Doug

          Comment


            #6
            Sigh

            Well, I was feeling pretty good about being able to help someone out... this weekend I was looking at my IIS settings and file permissions to see what indeed I had done to get .NET working with hs.methods, and LO!, it doesn't work any more. I've been pecking away off and on this weekend to get it working, but I haven't had any luck yet.

            At any rate, here's what I have... it USED to work, honest...

            I put the connection to hs in globl.asmx.vb, thus:

            Public Shared HomeSeer As HomeSeer.Application

            #Region " Component Designer Generated Code "
            ... deleted... no changes here
            #End Region

            Sub Session_Start(ByVal sender As Object, ByVal e As EventArgs)
            ' Fires when the session is started
            If HomeSeer Is Nothing Then
            HomeSeer = GetObject("", "HomeSeer.Application")
            End If
            End Sub

            The web code (ie: "Service1.asmx") looks thus:

            <WebMethod()> Public Function DeviceStringbyName(ByVal strDeviceName As String) As String
            DeviceStringbyName = Global.HomeSeer.DeviceStringByName(strDeviceName)
            End Function


            "Homeseer.Application" has been added to the "references" tab in solution explorer.

            When I run the program (via F5), I DO get the test web page with all the "services" (ie methods) listed, but when I attempt to test them, I get 500 Internal Server Error from internet explorer.

            Comment


              #7
              I GOT IT WORKING!

              I spent over 4 hours talking to three experts at Microsoft. We went over just about everything, but it turned out the be something pretty simple.
              1. In the IIS control panel, expand to find your web application. Right-click and select Properties. Select the Directory Security tab and select Edit in the "Anonymous access..." box. This will show Authentication Methods screen. Be sure "Anonymous access", "Allow IIS to control password" and "Integrated Windows authentication" are checked, and other checkboxes unchecked.

              You must create an IUSR_machinename (replace 'machinename' with your machine name) and be sure that it apprears in the 'User Name' field as 'machinename\IUSR_machinename'. Enter the password.

              Click OK & OK again. Then close IIS.

              2. In your application, open your web.config file and set <authentication mode="Windows"/>. Add a line below (if necessary) to read <identity impersonate="true"/>.

              3. Just to be on the safe side, open a system command window, and reset your IIS server by entering "IISRESET". That will stop and restart IIS.

              Give it a whirl. That works for me. Hope this helps someone else!

              Doug

              Comment


                #8
                Wow!

                What do you mean by 'enter the password'? Does the password have to be anything special or can you make up anything?

                My IUSR_MACHINENAME was always there... why did you have to create it?

                Comment


                  #9
                  Hmmm,

                  I tried unchecking the "Allow IIS to cotrol password" and resetting the password to some random value, and it still works. Hmmm. Guess it's not really needed.

                  Hey, I'm (obviously) not a security expert!

                  I should have said "You must create an IUSR_machinename (assuming it doesn't already exist)..."

                  During my lengthy phone call to MS, we did a whole bunch of stuff, so there may have been something else we tried that actually gets this working.

                  I recall that we (me & MS) setup something in (I think) DCOM configuration, but I gave the MS folks control of my machine, so everything was happening very quickly - I lost track.

                  If it doesn't work for you, sorry. I still have this MS Case open for the next 30 days, so I might be able to reach out to them again and find out exactly what they did, if I ask nicely.

                  Let me know if this works for you. Just be sure to do the IISRESET each time after making changes. That seemed important to them.

                  Doug

                  Comment


                    #10
                    Hey Doug, thanks for the help!

                    Talk about reversal - you started out looking for help, and ended up giving it.

                    I did a lot of fiddling, and got it working again. Looks like it was a DCOM problem - I've had lots of trouble with dcomcnfg; it tends to not remember settings, and crash a lot. I had to put in custom access permissions (Everyone, IUSR_xxx, IWAM_xxx, SYSTEM) for HomeSeer.clsString.

                    I have HS running as a service under my login username, since if I run it as a service under the system account, it forgets its registration key and wipes out my 'myhouse.xml' file.

                    I think the permissions allow the IUSR_xxx username for IIS to connect to hs running under another (administrator) account.

                    I also did a 'homeseer.exe unregsvr' and a 'homeseer.exe regsvr' (not sure of my spelling...)

                    In other words, once again I muddled around blindly till it worked...

                    At one point I had IIS launching hs under username IUSR_xxx... it would freeze up and cause the webpages to time out. Something I did under DCOM fixed that.

                    Comment


                      #11
                      All,

                      I now know exactly how to fix this stuff. Yes - It's an issue with how HS uses DCOM. Not a bad thing, just something you need to setup and be aware of.

                      In need? Ask.

                      Doug

                      Comment


                        #12
                        I'm asking!

                        The only way I've found to get things working after an upgrade of HS is:

                        1) For Windows forms, recompile.
                        2) For .Net webmethods, create an entirely new project, and copy the source code from the old one, pasting into the appropriate .asmx modules.

                        Is there an easier way?

                        Comment


                          #13
                          Yes,
                          The upgrade alters the object permission information for DCOM since the executeable needs to have the dcom permissions reassociated. Make sure homeseer is not running, enter dcomcnfg, go select one of the permission tabs under the hs object and then close dcomcnfg. For some reason the object does not automatically realign and dcomcnfg will reassociate the permissions on closing. I've been using DCOM for better part of a year and at every upgrade, my code stops working until dcomcnfg is run. Once run, HS accepts dcom permissions without a problem.

                          Comment


                            #14
                            Warcorp,
                            We and others have this exact same problem. Fixing it is easy enough but my question is why do we have to "reset" the DCOM permissions every time we download a new hs.exe?
                            💁‍♂️ Support & Customer Service 🙋‍♂️ Sales Questions 🛒 Shop HomeSeer Products

                            Comment


                              #15
                              Rupp, etal,

                              From my very limited experience with insalling only one update, this does seem to be the case.

                              I am copying below a rather lengthy discuusion / summary that the fellow at MS sent once we resolved the issue(s).
                              ------------------------------
                              Action

                              Customer has an ASP.NET Web Application which is trying to communicate with a 3rd party DCOM server which communicates with hardware over RS232 port.



                              Result

                              When executed in ASP.NET web form, the calls to the component succeed but have no affect – no error messages reports.



                              Cause

                              Based on the research that we performed the following was determined.



                              The DCOM application is written in Visual Basic 6.0 and it has a built in UI. In normal cases Visual Basic uses MSCOMM control to communicate with hardware connected to the RS232 port. If the application was executed in the UI everything worked as expected, but as a user tried to access the component, the execution did not fail – but was not able to communicate with the hardware successfully when configured to run as ‘Launching User’. This will cause a new instance of the server to be started each time a new user tries to communicate with the application.



                              From a debug session, it was determined that the DCOM server does throw an error with HRESULT c000008f - STATUS_FLOAT_INEXACT_RESULT. This is actually a typical value throw by the Visual Basic runtime to indicate a failure – but does not map to the correct Visual Basic specific error number. But, it was determined that the error that was thrown is rather 8005 in Visual Basic, which is the error returned by MSCOMM control stating that the port has already been opened by some other instance or application. This explains the failure to communicate with the device when calling from ASP.NET web application.



                              Also, as customer launches the HomeSeer application, a pop up windows is displayed that requires user interaction and confirmation of the software. When this is run in server environment, and under the identity of the launching user there is no interaction to this windows causing the process to appear hanging – not responsive to the commands received from web applications or other server products.



                              Resolution

                              To resolve this issue we are required at this time to configure the DCOM server to be executing as ‘Interactive User’ – Default value after installation is ‘Launching User’.



                              This will then allow the customer to interact with the confirmation message required for the application to execute. But, in NORMAL scenarios the ‘Interactive User’ setting should be ONLY used during testing and debugging as it requires a current log on session on the machine (allows access to interactive desktop heap). If there is not current user logged on to the machine, the activation WILL fail with error message indicating ‘User name or password invalid’. But, by using this setting we can force all applications that are trying to access the component to be communicating with the single instance of the DCOM server and NO additional processes will be launched leading to the error.
                              ------------------------------------
                              I sincerely hope this helps other folks. I spent well over 6 hours on the phone to MS to resolve this. (kudos please) ;-)

                              Doug

                              Comment

                              Working...
                              X