Problems using a winforms control as an object in Internet Explorer

[John Boghossian]

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.FileUpload Control" VIEWASTEXT>
</OBJECT>
Best regards
John Boghossian

[Alvin Bruney]

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.

--
Regards,
Alvin Bruney
Got tidbits? Get it here...
http://tinyurl.com/3he3b
"John Boghossian" <jo*************@investorab.com> wrote in message
news:uG**************@TK2MSFTNGP12.phx.gbl...

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.FileUpload Control" VIEWASTEXT>
</OBJECT>
Best regards
John Boghossian

[Steven Cheng[MSFT]]

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.FileUpload Control" 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...securityallowp
artiallytrustedcallersattributeclasstopic.asp?fram e=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/is...h/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]]

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.FileUpload Control" 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...securityallowp
artiallytrustedcallersattributeclasstopic.asp?fram e=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/is...h/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]]

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...rameworkadmini
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/is...h/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.)

[John Boghossian]

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

"Steven Cheng[MSFT]" <v-******@online.microsoft.com> wrote in message
news:6j**************@cpmsftngxa08.phx.gbl...

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...rameworkadmini 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/is...h/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]]

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.)

[John Boghossian]

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

"Wolfgang Kaml" <[e-mail]> wrote in message
news:ut**************@TK2MSFTNGP10.phx.gbl...

John,

Maybe the solution to the problem I had with the GAC might be a solution for you as well.

Check out the posting under the attached link.

Hope that this might help.
Wolfgang

"John Boghossian" <jo*************@investorab.com> wrote in message
news:O2****************@TK2MSFTNGP12.phx.gbl...

Well it seems I can´t get it to work anyway.
I have created a strong key and added the following to my assemblyinfo.vb:

<Assembly: AssemblyKeyFileAttribute("keypair.snk")>

<Assembly: AllowPartiallyTrustedCallers()>

I have also tried the "trust an assembly" by entering the full url-to

where

the dll is located. After that selecting Full Trust.

Still no luck.
"Steven Cheng[MSFT]" <v-******@online.microsoft.com> wrote in message
news:Fg**************@cpmsftngxa07.phx.gbl...

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.)

[Wolfgang Kaml]

Let me know if that link will work for you:
news:u7**************@tk2msftngp13.phx.gbl

Regards,
Wolfgang

"John Boghossian" <jo*************@investorab.com> wrote in message
news:Op****************@TK2MSFTNGP11.phx.gbl...

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

"Wolfgang Kaml" <[e-mail]> wrote in message
news:ut**************@TK2MSFTNGP10.phx.gbl...

John,

Maybe the solution to the problem I had with the GAC might be a solution for

you as well.

Check out the posting under the attached link.

Hope that this might help.
Wolfgang

"John Boghossian" <jo*************@investorab.com> wrote in message
news:O2****************@TK2MSFTNGP12.phx.gbl...

Well it seems I can´t get it to work anyway.
I have created a strong key and added the following to my assemblyinfo.vb: <Assembly: AssemblyKeyFileAttribute("keypair.snk")>

<Assembly: AllowPartiallyTrustedCallers()>

I have also tried the "trust an assembly" by entering the full url-to

where

the dll is located. After that selecting Full Trust.

Still no luck.
"Steven Cheng[MSFT]" <v-******@online.microsoft.com> wrote in message
news:Fg**************@cpmsftngxa07.phx.gbl...
> 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]]

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.)

[John Boghossian]

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
"Steven Cheng[MSFT]" <v-******@online.microsoft.com> wrote in message
news:j7*************@cpmsftngxa07.phx.gbl...

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]]

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.)