Problems using a winforms control as an object in Internet Explorer

Discussion in 'ASP .Net' started by John Boghossian, Jan 14, 2004.

  1. I know this isn´t spot on for this group, but the problem relates to an
    asp.net project i am working on.

    I am trying to develop an windows forms control to be used in IE in an
    intranet solution. The
    control lists documents attached to an specific item. The control supports
    drag/drop and automatically uploads and downloads via an web service to an
    SQL server database.

    The control works fine when run on my develop machine. But if i try to
    request the page on my develop machine from another computer i can´t get it
    to work.

    I know from when using ActiveX you have to enter a "Codebase" to point to
    the Active X controls CAB that should download and install the ActiveX
    control.
    How do i fix this with an windows forms Control?

    All clients have .Net Framework installed.

    Here is a my Object Tag

    <OBJECT id="oFile1"
    classid="http:FileUpload.dll#FileUpload.FileUploadControl" VIEWASTEXT>
    </OBJECT>


    Best regards
    John Boghossian
     
    John Boghossian, Jan 14, 2004
    #1
    1. Advertisements

  2. John Boghossian

    Alvin Bruney Guest

    You'd actually need to host the windows control in the browser. I'm not sure
    how you said the application is working. I'd have to see some code. In the
    meantime, google for jeff prosise and hosting. He has an excellent article
    which teaches how to host a windows control in a browser. There is a lot of
    COM etc so it is a bit on the advance side. I believe the code base
    attribute is depricated and IE is smart enough to know what is needed once
    the assembly is in the bin folder - ! 100% sure.
     
    Alvin Bruney, Jan 14, 2004
    #2
    1. Advertisements

  3. Hi John,


    Thank you for using MSDN Newsgroup! My name is Steven, and I'll be
    assisting you on this issue.
    From your description, you've made an Winform control and used it in a web
    page displayed in IE. Also, it worked well at the develop machine. However,
    when you access the page from other machine, you found the control didn't
    work.
    If there is anything I misunderstood, please feel free to let me know.

    Since you've provided the code period :
    <OBJECT id="oFile1"
    classid="http:FileUpload.dll#FileUpload.FileUploadControl" VIEWASTEXT>
    </OBJECT>

    that specify the assembly's path as the same place with the page, and the
    control can be displayed well from local machine. So I don't think the
    problem is caused by the path of the assembly. Also, I'd like to confirm
    something on this issue:
    1. All the test machines are intranet based enviroment, yes? All have the
    same version of dotnet framework installed?
    (At least, have the same highest version?)

    2. The FileUpload.dll is put in the same directoy with the page which
    contains it? If so, there won't have problem with the assembly's location.

    3. When request the certain page from other client machine, what does the
    page display for the control since it can work. If it is a large rectangle
    with a small rectangle(on the left top corner) and also a "X" in the small
    rectangle, that indicates the control's assembly can't be correctly
    located. Else, if in the small rectangle, there are some mini colorful
    shapes , that indicates the control's assembly has been successfully
    located, but can't be executed correctly in client CLR.
    Then, the problem is likely due to a security issue(assembly's access
    permission).

    Is the control you made strong-named? If so, Have you applied the
    "AllowPartiallyTrustedCallersAttribute" to your
    assembly? If not, you need to do it with your strong named control:
    add [assembly:AllowPartiallyTrustedCallers()] in the AssemblyInfo file.
    Then rebuild the control's assembly and replace the old one and test the
    page again.

    For detailed description on the "AllowPartiallyTrustedCallers" attribute,
    you can view the following link in MSDN:
    http://msdn.microsoft.com/library/en-us/cpref/html/frlrfsystemsecurityallowp
    artiallytrustedcallersattributeclasstopic.asp?frame=true


    Also, sometimes, there will be some certain code still unable to execute
    well on client machine. Then we need to manully
    adjust the "Zone Security" via the ".net Configuration tool" on the client
    machine. You can find the ".net Configuration tool" through the Control
    Panel---->Administrative Tools--->.net Configuration tool. Start it and
    select the "Runtime security policy" node in the left treeview. Then in the
    right main view, click the "Adjust Zone Security" link, choose "make change
    to this computer" ( default option) and then click next, you'll found some
    big icons options on the top , select the "Local Intranet" and move the
    slide bar below and adjust it to "Full Trust"(give the maximum trust).
    Thus,we've up the trust leve of the assemblies from local intranet area.
    After that, click next and close it. Try visiting the page which contains
    the winform control again to see whether the problem remains.

    If you want more detailed information on the security for rich client
    situatoin, you may visit the following tech article in MSDN:
    #Code Access Security and Distribution Features in .NET Enhance Client-Side
    Apps
    http://msdn.microsoft.com/msdnmag/issues/02/06/rich/default.aspx

    Please try out the preceding suggestions to see whether they help. If you
    have any questions on them, please feel free to post here.


    Regards,

    Steven Cheng
    Microsoft Online Support

    Get Secure! www.microsoft.com/security
    (This posting is provided "AS IS", with no warranties, and confers no
    rights.)
     
    Steven Cheng[MSFT], Jan 15, 2004
    #3
  4. Hi John,

    Thanks for your response. I've viewed the pictures you provided. Yes, the
    "NoWorking.gif" has indicated that the problem is likely due to the code
    access security issue rather than the "codebase" issue. So we could make
    effort on the code security.

    As I've mentioned in the last reply. Since your control is strong-named, we
    could first try adding the "assembly:AllowPartiallyTrustedCallers"
    attribute for your strong-named control assembly, are you using VS.NET to
    develop it? If so , add such a line into the "AssemblyInfo.cs" and rebuild
    the control assembly.
    [assembly: AllowPartiallyTrustedCallers()]

    After that, try using the new assembly in the page and do the test to see
    whether this works.


    Also, there maybe some certain codes may still unable to be executed
    correctly in other client enviroment by the default security setting. I
    notice that you said "you have tried changing the security settings in IE
    to allow all and every bit and byte."
    But have you changed any code access security setting via the ".Net
    Configuration tool" on the client machine?. As I mentioned in the last
    reply, you can open it in the "Control Panel" through such path :
    Control Panel---->Administrative Tools--->.net Configuration tool
    Then try changing the "Zone Security" follow steps in my last reply:

    -----------------------------------------------
    select the "Runtime security policy" node in the left treeview. Then in the
    right main view, click the "Adjust Zone Security" link, choose "make change
    to this computer" ( default option) and then click next, you'll found some
    big icons options on the top , select the "Local Intranet" and move the
    slide bar below and adjust it to "Full Trust"(give the maximum trust).
    Thus,we've up the trust leve of the assemblies from local intranet area.
    After that, click next and close it.
    ------------------------------------------------
    If you're not familiar with the ".net configuration tool", you may view the
    following tutorial in MSDN:
    #.NET Framework Configuration Tool (Mscorcfg.msc)
    http://msdn.microsoft.com/library/en-us/cptools/html/cpconnetframeworkadmini
    strationtoolmscorcfgmsc.asp?frame=true

    Also, I still think I maybe helpful if you'd like to have a overview on the
    following article, it provided detailed situation description for
    distribute rich client .net component:
    #Code Access Security and Distribution Features in .NET Enhance Client-Side
    Apps
    http://msdn.microsoft.com/msdnmag/issues/02/06/rich/default.aspx

    Please have a further check on the above items. Also feel free to post here
    if you need any help.


    Regards,

    Steven Cheng
    Microsoft Online Support

    Get Secure! www.microsoft.com/security
    (This posting is provided "AS IS", with no warranties, and confers no
    rights.)
     
    Steven Cheng[MSFT], Jan 16, 2004
    #4
  5. I will absolutely try AllowPartiallyTrustedCallers to see if it works.
    I haven´t had the time to work on this issue the last days, but i will
    surely try this out this week. If this won´t solve the matter i will get
    back to this newsgroup.

    By the way, i have found that the fileupload.dll actually downloads to the
    clients that don´t se the control. it ends up in assembly/download under the
    windows catalog.

    Thanks for all your help so far.

    Regards
    John Boghossian



     
    John Boghossian, Jan 19, 2004
    #5
  6. Hi John,

    Thanks for your response. I'll hold on this issue to wait for your test
    result. Also, you may also try the changing the client machine's .net code
    access setting via the ".net configuration tool" sueggestion I mentioned.
    In the meantime, if you have any new finding, please feel free to let me
    know.


    Regards,

    Steven Cheng
    Microsoft Online Support

    Get Secure! www.microsoft.com/security
    (This posting is provided "AS IS", with no warranties, and confers no
    rights.)
     
    Steven Cheng[MSFT], Jan 20, 2004
    #6
  7. Wolfgang, i couldn´t open your attachment. Could you send it via e-mail
    directly to me or write the link in clear text.

    Regards
    John Boghossian
     
    John Boghossian, Jan 22, 2004
    #7
  8. Let me know if that link will work for you:

    Regards,
    Wolfgang
     
    Wolfgang Kaml, Jan 22, 2004
    #8
  9. Hi John,


    Thanks for the followup. I've viewed the trust.jpg you provided. You added
    the certain url into the trusted assemblies and still with no success. Yes,
    I've also met such situation on my side. And I think you can try anther
    means as I metioned ago, change the "Zone Security", it's different from
    trust a certain assemby via url, that'll adjust the code access level for
    all the assemblies from a certain zone. I suggest you try adjusting the
    "Local Intranet" zone, and change its trust level to Full Trust. Also, to
    make the steps clearly , I've attached some images on the detailed steps.
    You may check them if you have any questions on the steps I described in
    the last reply. If you have any other questions, please also feel free to
    let me know. Thanks.




    Regards,

    Steven Cheng
    Microsoft Online Support

    Get Secure! www.microsoft.com/security
    (This posting is provided "AS IS", with no warranties, and confers no
    rights.)
     
    Steven Cheng[MSFT], Jan 23, 2004
    #9
  10. Way to go Steven,

    this works. Is there a way to distinguish what actually causes it to work
    under full trust compared to medium trust?

    regards
    John
     
    John Boghossian, Jan 23, 2004
    #10
  11. Hi John,


    Have you had a chance to try my suggestion or have your problem been
    resolved. Please feel free to let me know if you need any help.


    Regards,

    Steven Cheng
    Microsoft Online Support

    Get Secure! www.microsoft.com/security
    (This posting is provided "AS IS", with no warranties, and confers no
    rights.)
     
    Steven Cheng[MSFT], Jan 26, 2004
    #11
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.