Could not find a part of the path - User control from within IE

[Leslie]

I have developed a usercontrol which is downloaded from a web site and
executes in Internet Explorer. This control writes files to the user's temp
directory on the local workstation.
The control has worked fine during development but fails when executed from
a web server that is not localhost. The message below is returned.
Could not find a part of the path
'C:\Documents~and~Settings\masonlf\Local~Settings\Temp\SRP\~ST000001~CMD.ico'.
Is this a security settings problem? If so, how do I set dotnet
configuration to allow this to run from other servers?

I have tried to sign the control with a strong name, but that has failed
since the control references other interop assemblies.

Thanks,

Leslie

 

[Steven Cheng[MSFT]]

Hi Leslie,

Welcome to the MSDN newsgroup.

From your description, I understand you've developed an .NET winform
control which is hosted in a web page(IE hosted), the control will access
files in the client computer's user profile local temp dir. However, you
find that the client runtime will always report "Could not find a part of
the path ......" exception, correct? If anything I missed, please feel free
to let me know.

Based on my experience, for IE hosted .net winform control, the most
important thing is configuring the client-side .NET runtime's CAS
permission if our control will access any particular sensitive or protected
resource on the client machine. And based on the error info you provided, I
don't think it is likely a permission issue but like the path is not a
valid one so that the System.IO api can not find the correct path. so I
suggest you try accessing a uplevel folder to see whether the control can
access it(make sure the path is valid). e.g:

=========================
private void btnTest_Click(object sender, System.EventArgs e)
{

string path = @"C:\Documents and Settings\username\Local
Settings\Temp";
DirectoryInfo di = new DirectoryInfo(path);

FileInfo[] files = di.GetFiles();


MessageBox.Show( files.Length.ToString());
}
============================
'
In addition, if you want to check whether the problem is related to CAS
permission setting, you can try using the "caspol.exe" tool to turn off the
client machine's .NET CAS checking temporarily and test it to see whether
the problem remains( if remains, it is not due to CAS setting):

#Code Access Security Policy Tool (Caspol.exe)
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cptools/htm
l/cpgrfcodeaccesssecuritypolicyutilitycaspolexe.asp

BTW, since the IE hosted winform control will always be hosted in the
latest framework installed on the client machine, you should use the caspol
under the framework of correct version's folder.

Hope this helps. If there is anything else we can help, please feel free to
post here.

Regards,

Steven Cheng
Microsoft Online Community Support


==================================================

When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.

==================================================


This posting is provided "AS IS" with no warranties, and confers no rights.



Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

 

[Steven Cheng[MSFT]]

Hi Leslie,

How are you doing on this issue? Have you got any progress or did my last
reply helps a little? If there's anything else we can help, please feel
free to post here.

Regards,

Steven Cheng
Microsoft Online Community Support


==================================================

When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.

==================================================


This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Leslie]

Steven,

I have resolved the path issue. You were correct, it was a problem with the
path. The "Documents and Settings" folder was listed as "Documents
~and~Settings", which does not exist. The problem appeared when I ran the
1.1 code against a 2.0 runtime.

When calling Path.GetTempPath() from the 1.1 runtime the short path name is
returned. when calling Path.GetTempPath() from the 2.0 runtime the long path
name is returned.

I wanted to ensure that the fully qualified path and file name contained no
imbedded spaces so I replaced all embedded spaces with '~'. This worked great
using the 1.1 runtime. However when I ran my 1.1 code against the 2.0 runtime
the path problem occurred.

Thanks for pointing me down the right "path". ;-)

I am still having some security related problems.

I can get the code to execute (using 1.1 or 2.0) when I set cas to all code
to run from a url such as: http://localhost/*. However, when I set cas to
allow the dll to run based upon strong name, the code will not execute.

Can you think of other things I might be missing that would prevent
StrongName code from executing? I have used the sn.exe to to verify that my
dll and the two interop dlls that my code calls all are signed with the same
strong name. In addition, when configuring CAS, I import the public key
directly from my dll.

Thanks,

Leslie

 

[Steven Cheng[MSFT]]

Thanks for your followup Leslie,

I'm very glad that the former sugggestion is of assistance .

As for the further CAS issue you mentioned, I'd like to confirm the
following things:

1. When granting the CAS permission through strong-named codegroup, do you
grant "Full Trust" permission?

2. Are you sure whether all the assemblies used in your usercontrol(main
assembly or other assemblies referenced directly or indirectly by your main
assembly) are of the same strong-named. If there exists some other
assemblies which are referenced, you need to make sure they will also be
evaluated as "Full Trust" permission at the client-side's .net CAS...

If there have many referenced dependeny assemblies and you feel it hard to
point out which is likely the cause, you can try create a reproduce
usercontrol which use them reference and use them one by one and test it to
rule out the problem one.(For test, just grant "Full Trust" to make it
simplified).

In addition, for IE host .net control, we can enable a client-side IEHOST
log file which may provide some information when there occuring some
exceptions(inlucde CAS specific exceptions):

#HOW TO: Use the IEHost Log to Debug .NET Object Hosting in Internet
Explorer
http://support.microsoft.com/kb/313892/en-us

Hope this also helps.

Regards,

Steven Cheng
Microsoft Online Community Support


==================================================

When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.

==================================================


This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Leslie]

Steven,

Please see answers below.

1. When granting the CAS permission through strong-named codegroup, do you
grant "Full Trust" permission?

Yes I am granting FullTrust permission.

2. Are you sure whether all the assemblies used in your usercontrol(main
assembly or other assemblies referenced directly or indirectly by your main
assembly) are of the same strong-named. If there exists some other
assemblies which are referenced, you need to make sure they will also be
evaluated as "Full Trust" permission at the client-side's .net CAS...

My code references two interop dlls. I have strongname signed them with the
same strong name but so far that has not succeeded.

 

[Steven Cheng[MSFT]]

Thanks for the further response Leslie,

Seems the permission with your two strong-named assemblies are ok. So far I
can't get any definite clues from this. Have you tried the IE host log I
mentioned in the previous thread to see whether it can catch any useful
info?

Regards,

Steven Cheng
Microsoft Online Community Support


==================================================

When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.

==================================================


This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Leslie]

I tried the IE host log and saw the message that said:

"That assembly does not allow partially trusted callers".

I then added [assembly:AllowPartiallyTrustedCallers] to my assembly. In
addtion I added new PermissionSet(PermissionState.Unrestricted).Assert(); to
my main function and everything seems to be working now.

Thanks,

Leslie

 

[Steven Cheng[MSFT]]

That's great Leslie,

Glad that you've got it working now. Also, if you meet any further problem
or anything we can help, please feel free to post here.

Best Regards,

Steven Cheng
Microsoft Online Community Support


==================================================

When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.

==================================================


This posting is provided "AS IS" with no warranties, and confers no rights.



Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)