|
In which project's AssemblyInfo.cs file did you add that assembly-level declarative security attribute? The client or the server? If the code even runs at all, it's not a code access security problem. When the CLR loads your assembly it will demand for that permission set. If the demand fails, the assembly is not loaded. It'll never even get to your remoting code. To grant this permission set you'll need to run the client off your local machine (by default, local code runs with FullTrust permissions) or create a code group to grant your code (via whatever evidence seems suitable) the FullTrust permission set.
So, have you tried debugging your code to make sure it's even loading?
This posting is provided "AS IS" with no warranties, and confers no rights.
Software Design Engineer
Developer Division Sustained Engineering
Microsoft
[My Articles] [My Blog]
|
|
|
|
|
Hi Heath, thanks for the reply.
Both Client and Server run on my machine and for sake of simplicity for the time being both assemblies and two other dlls (remote objects and general tools) are all linked to the same AssemblyInfo file so they all have the same set of permissions.
My ContextData object is included in the 'general tools' dll.
Code worked perfectly, and if I remove all CallContext code (the setter in the client app and getter in the remoteobject called method) everyting works perfectly again. The error seems to be when the remote call is made and before anything starts visibly 'moving' on the server side. A breakpoint in my remote object constructor (its a singlecall obj) is never reached.
P.D. Both server and client app startup perfectly so the 'FullTrust' permission set is granted for both apps.
|
|
|
|
|
Skynyrd wrote:
are all linked to the same AssemblyInfo file so they all have the same set of permissions.
I'm sure you know this, but just in case and for future readers I note that using the same file won't grant any permissions. That happens at runtime. This approach just means they'll demand (or whatever action is appropriate) the same permissions.
Could you post your remoting configuration (or, if programmatically, include the important details like the channel and connection string, the formatter you're using, etc.)? What hosts the remoting singleton? A Windows service, IIS, or just some app that blocks until you quit (like all those console examples in the remoting books)?
This posting is provided "AS IS" with no warranties, and confers no rights.
Software Design Engineer
Developer Division Sustained Engineering
Microsoft
[My Articles] [My Blog]
|
|
|
|
|
The server app is for debugging purposes a Console App at the moment. The remoting is done through an interface:
relevant server code:
...
TcpServerChannel myChannel=new TcpServerChannel(8086);
ChannelServices.RegisterChannel(myChannel);
RemotingConfiguration.RegisterWellKnownServiceType(typeof(DataLayerTool),"DataLayerTool.rem",WellKnownObjectMode.SingleCall);
...
relevant client side app:
...
private object GetProxy()
{
return Activator.GetObject(myType,myUrl);
}
public object RunMethod(string methodName, object[] arguments)
{
CallContextData cookie=new CallContextData();
cookie.Data=myUser.EncryptedUserName;
CallContext.SetData("myUser",cookie);
object proxy=GetProxy();
TypeDelegator delegator=new TypeDelegator(myType);
return delegator.GetMethod(methodName).Invoke(proxy,arguments);
}
...
Client remoting config file:
<configuration>
<system.runtime.remoting>
<application>
<channels>
<channel ref="tcp" port="0">
<clientProviders>
<formatter
ref="binary"
/>
</clientProviders>
</channel>
</channels>
<client>
<wellknown type="IDataLayerTool, Vigila Objects"
url="tcp://localhost:8086/DataLayerTool.rem" />
</client>
</application>
</system.runtime.remoting>
</configuration>
|
|
|
|
|
Duh...figured it out...
kinda stupid of me 
I was strong naming my assemblies (thought the code in the assemblyinfo file was commented out...) and I was getting the security exception possibly because I wasnt fully qualifying my assemblies in the client remoting configuration file.
Commented out the strong naming and everything works fine.
|
|
|
|
|
I wouldn't comment-out strong name attributes. Strong naming is your friend. Not only does it help you (and your clients) secure their machines and allow your code individually to have its own permissions, but it also helps you version and allows you to install into the GAC.
If you get tired of the ever-changing version numbers, then don't use automatic versioning (I always use explicit versions, especially in multi-project solutions). Instead of using a version string like "1.0.*", be explicit with all 4 segments (from 0-65535; each segment is an unsigned short). This gives you control over versions.
How does it help with versioning? Read about Publisher Policies[^].
This posting is provided "AS IS" with no warranties, and confers no rights.
Software Design Engineer
Developer Division Sustained Engineering
Microsoft
[My Articles] [My Blog]
|
|
|
|
|
Thanks Heath.
Yes I normally always use StrongNaming but I think that the early stage at which my project is right now, I can do without it. Anyhow, explicit versioning would solve the problem. Will try it out.
|
|
|
|
|
I've tried out explicit versioning but I still get the same exception: These are the remoting config files I'm using:
Server side:
<configuration>
<system.runtime.remoting>
<application>
<service>
<wellknown
type="Vigila.Remoting.DataLayerTool, Vigila.Remoting, Version=0.0.1.0, Culture=neutral, PublicKeyToken=caa4a15766f8ec1a"
objectUri="DataLayerTool.rem"
mode="SingleCall"
/>
</service>
<channels>
<channel
ref="tcp"
port="8086"
/>
</channels>
</application>
</system.runtime.remoting>
</configuration>
Client Side:
<configuration>
<system.runtime.remoting>
<application name = "Vigila client">
<client>
<wellknown
type = "Vigila.Objects.IDataLayerTool, Vigila.Objects"
url = "tcp://localhost:8086/DataLayerTool.rem" />
</client>
<channels>
<channel
ref="tcp"
port="0"
/>
</channels>
</application>
</system.runtime.remoting>
</configuration>
If I try to include Version, culture and public key info of the Vigila.Objects assembly in the client config file:
"Vigila.Objects.IDataLayerTool, Vigila.Objects, Version=0.0.1.0, Culture=neutral, PublicKeyToken=caa4a15766f8ec1a"
, I get the follwoing RemotingException telling me that Client WellKnow entries dont admit full names (version, culture and key)
!? dont know if this is normal. If u need details of exception I'll post them, but wont do it now because its too long.
Anyhow, when I run the app, I'm getting exactly the same exception I posted in the first message: SecurityExpection due to the CallContexData object I'm using (see my first post please). Am I supposed to include info of this object in the client and server remoting config files somehow? and if so, how? Or what am I missing?..all examples I see of CallContext are without strongnaming, and I know my code works perfectly in that case, but I cant find any examples where StrnongNaming is used with CallContext.
|
|
|
|
|
Interesting. I've never actually had this problem and have always used strong naming. You might try this, though.
Continue using the partial names (fully-qualified class name, followed by the assembly name) but define the following in your .config file:
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<qualifyAssembly partialName="Vigila.Objects"
fullName="Vigila.Objects, Version=0.0.1.0, Culture=neutral, PublicKeyToken=caa4a15766f8ec1a" />
</assemblyBinding>
</runtime>
</configuration>Of course, do this for each assembly that needs qualifying.
Without knowing more about your problem, it's possible that if you don't update your server and client versions (you might consider not changing the version every time you compile - figure out a scheme that works for you) at the same time and they use a separate copy of a shared assembly - and you don't update both copies at the same time, leading to different versions - you could end up with a serialization error since the types won't match (even if they're only off by a version number, they're still different types). I'm just speculating, however.
In a typically deployment scenario, you can get around versioning problems (rather, so you can update some assemblies without updating others) with publisher policies (see the .NET Framework SDK for more details). To get around the incompatibilities in the serialization, you can use a SerializationBinder and overriding BindToType (you can actually write generic code to handle any type thrown at it; it should be obvious but if you want, click "Search comments" to search for "BindToType" for a previous example I posted).
This posting is provided "AS IS" with no warranties, and confers no rights.
Software Design Engineer
Developer Division Sustained Engineering
Microsoft
[My Articles] [My Blog]
|
|
|
|
|
Thnks for the advice. I tried the new config u posted but its not working either.
Anyhow, I've been looking around in the net and I'm not the only one who's come up with this problem. It's apparently a Net v1.1 issue due to new security features in remoting not implemented in v1.0. After searching for a while I've come up with two solutions:
First one isn't any good: its using the Assembly AllowPartiallyTrustedCallers attribute in my Objects.dll where the DataCallContext object is. The code works this way but it shouldnt be the solution to my problem unless there is absolutely nothing else I could do.
Second one is most probably the correct way to solve the problem: explictly change the server formatter's FilterLevel to 'Full'. (defualts to 'Low').
...so, in case anybody else has this problem and stumbles upon this post while searching the forum, the problem will be fixed if they configure the server remoting config file similar to the following:
<configuration>
<system.runtime.remoting>
<application>
<service>
<wellknown
type="Vigila.Remoting.DataLayerTool, Vigila.Remoting, Version=0.0.1.0, Culture=neutral, PublicKeyToken=caa4a15766f8ec1a"
objectUri="DataLayerTool.rem"
mode="SingleCall"
/>
</service>
<channels>
<channel ref="tcp" port="8086">
<serverProviders>
<formatter ref="binary" typeFilterLevel="Full" />
</serverProviders>
</channel>
</channels>
</application>
</system.runtime.remoting>
</configuration>
Thanks for all the help.
|
|
|
|
|
I want to display the version information in the About screen of my application. What I thought was the way to do this did not work:
System.Reflection.AssemblyName myAssName = new System.Reflection.AssemblyName();
MessageBox.Show("Major:"+myAssName.Version.Major.ToString()+"\nMinor:"+myAssName.Version.Minor.ToString()+"\nBuild:"+myAssName.Version.Build.ToString()+"\nRev:"+myAssName.Version.Revision.ToString());
but this does not work.
The other way works:
System.Diagnostics.FileVersionInfo myFVI = System.Diagnostics.FileVersionInfo.GetVersionInfo("SBoxCollect.exe");
MessageBox.Show("Major:"+myFVI.FileMajorPart.ToString()+"\nMinor:"+myFVI.FileMinorPart.ToString()+"\nBuild:"+myFVI.FileBuildPart.ToString());
But it seems like a lot of work to have to specify the (path and) name of the exe file.
Any comments regarding this would be great or maybe show me a better way to do this.
I noticed that FileVersionInfo can not be used in Windows CE. How can I do this in Windows CE?
Thanks,
Einar
|
|
|
|
|
I do not know about WinCE, but you can try to get assembly name of your file. In your first example you're creating new AssemblyName object, but not taking your currently running assemly info. You can use something like this:
System.Reflection.AssemblyName myAssName = System.Reflection.Assembly.GetExecutingAssembly().GetName();
This will give you AssemblyName of your file and you'll get your version bumbers without errors in normal windows. As I've mentioned above - I don't know about CE...
Hope it'll help...
Robin Panther
|
|
|
|
|
Of course it won't work - you must get an AssemblyName for the assembly that you want to display information about. If you simply initialize it, it would be empty.
A simple way to get the AssemblyName is like so:
AssemblyName asmName = this.GetType().Assembly.GetName(); Note, however, that the assembly version (AssemblyVersionAttribute) and file version AssemblyFileVersionAttribute) may be different. Most third-party assemblies don't differ, but some do and we do here at Microsoft (so that third-party libraries and applications that depends on our assemblies (the base class library, or BCL) don't have to use a publisher policy to redirect version binding).
Also, a word about performance: store the Version as a local varaible and don't keep referencing the AssemblyName to get to it. This results in about 2 less instructions per access and makes for much more readable code.
This posting is provided "AS IS" with no warranties, and confers no rights.
Software Design Engineer
Developer Division Sustained Engineering
Microsoft
[My Articles] [My Blog]
|
|
|
|
|
Hey
I've made a sort of compiler in c# and it works generally. I'm stuck because when I try to add a directx reference it spews out an error:
"Compilation failed:
error CS0006: Metadata file 'Microsoft.DirectX.Direct3D.dll' could not be found"
Thanks
|
|
|
|
|
First make sure you've installed Managed DirectX 9.0c (autumn 2004).
Once that is installed, you should be able to find a DirectX folder in C:\WINDOWS\Microsoft.NET\DirectX, which should contain your DirectX dlls. If not, you're going to have to extract them from the GAC, which is a pain, but you can get at them from the command line (i.e. won't work in windows explorer).
Any remotely useful information on my blog will be removed immediately. There are 10 kinds of people in the world. Those who have heard of the ubiquitous, overused, worn-out-like-an-old-shoe binary "joke" and those who haven't.
Judah Himango
|
|
|
|
|
Thanks a lot for that!
I changed the path for the dll to and it worked:
C:\WINNT\Microsoft.NET\Managed DirectX\v4.09.00.0900\Microsoft.DirectX.Direct3D.dll
Is the best idea to try to find a path similar to this on the user's system?
Thanks again
|
|
|
|
|
I'm pretty new to c# and I've managed to quickly write some code that works on my system to find the dir:
try<br />
{<br />
string curdir = Environment.GetEnvironmentVariable("windir") + "\\Microsoft.NET";<br />
<br />
DirectoryInfo dir = new DirectoryInfo(curdir);<br />
if (Directory.Exists(curdir))<br />
{<br />
System.IO.DirectoryInfo[] dirs = dir.GetDirectories();<br />
foreach (System.IO.DirectoryInfo fli in dirs)<br />
{<br />
if (fli.Name == "Managed DirectX")<br />
{<br />
curdir += "\\" + fli;<br />
break;<br />
}<br />
}<br />
dir = new DirectoryInfo(curdir);<br />
dirs = dir.GetDirectories();<br />
foreach (System.IO.DirectoryInfo fli in dirs)<br />
{<br />
if (fli.Name.StartsWith("v"))<br />
{<br />
curdir += "\\" + fli;<br />
break;<br />
}<br />
}<br />
MessageBox.Show(curdir);<br />
}<br />
}<br />
catch<br />
{<br />
MessageBox.Show("Error finding directory");<br />
}
How can this be improved?
Thanks
|
|
|
|
|
I am accessing a web site in C# using HTTPWebRequest. The site uses frames. I POST a request but the response is only a thousand bytes that lists the frames to be included in the page. How do I use the response from my HTTPWebRequest to access the second frame that contains the data I am interested in retrieving?
Here is the response I get from my POST:
<title>MSU Schedule Of Courses
To view this page, your browser must support
frames.
|
|
|
|
|
The same way that browsers do - you need to parse the text and find the frames. Make sure you keep a reference to the page's URL so that you can resolve relative URLs like so:
Uri newUrl = new Uri(oldUrl, "HeadingBlank.asp"); If you want a handy class to help parse HTML (a grammar defined by SGML), download and reference the SgmlReader[^] on GotDotNet.
This posting is provided "AS IS" with no warranties, and confers no rights.
Software Design Engineer
Developer Division Sustained Engineering
Microsoft
[My Articles] [My Blog]
|
|
|
|
|
Heath, I think you lost me on that one. All I get back from my C# HTTPWebRequest is 1k bytes. If I use IE for the same POST and use proxy sniffer to monitor it, I get 40k back. Obviously my browser is doing something more than my C# is doing.
You suggest I parse the text, but the text is 1k and no longer. Here is the C# that gets the response:
// read response stream and dump to string
Stream streamResponse = webResponse.GetResponseStream();
StreamReader streamRead = new StreamReader(streamResponse);
output = streamRead.ReadToEnd();
streamRead.Close();
streamResponse.Close();
Should I just leave the stream reader open and try to read from it again? I have to think that the web server is sending all the frames in one response with some kind of delimiter between frames. Does my ReadToEnd just stop prematurely? The 1K I actually get tells me what frames are coming, there are four. Should I just try ReadToEnd four times?
|
|
|
|
|
First of all - never use ReadToEnd if you don't know what to expect. 40K may not be a big buffer, but lets say you get back a 1 or 2MB buffer, or even more. You'll read that all into memory? I would hope not.
A stream is just that - a stream. Read-in the stream in blocks as it comes to you.
As far as the problem, it's hard to say if you don't post the HTML (which I thought was the frames page). When you're browser reads a file with frames in it, it parses the location of each frame then requests those files. The same is true for images, script, and other links. Everything you see in your browser - from pages to images to scripts - are separate requests and separate downloads. This is a basic principal of HTTP. You request one file, you get one file.
So, once again you parse that file with the frames to get the other document locations, then make a request for those.
If you're not getting the whole frameset content, then something else is wrong. It's possible that the service is using a browser capacity (browsercap) file and not sending you frames because you don't have a user-agent (an HTTP header that identifies the browser). To get around that and look like Internet Explorer, before you make your request set your HttpWebRequest.UserAgent property to the follow (IE6 on WinXP):
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;) To the server, you look like Internet Explorer and it would give you a frameset page instead of something else. That's assuming that's what's happening.
This posting is provided "AS IS" with no warranties, and confers no rights.
Software Design Engineer
Developer Division Sustained Engineering
Microsoft
[My Articles] [My Blog]
|
|
|
|
|
Well, that 1k I'm getting IS the frameset page. I showed it on my first post, but here it is again:
<title>MSU Schedule Of Courses
To view this page, your browser must support
frames.
Here is the request header:
1 POST /ScheduleBook/schedule.asp HTTP/1.1
2 Content-Type: application/x-www-form-urlencoded
3 Connection: close
4 Accept-Language: en-us,en;q=0.5
5 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
6 Referer: http://ntweb8.ais.msu.edu/ScheduleBook/selection.asp
7 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910
8 Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,image/jpeg,image/gif;q=0.2,*/*;q=0.1
9 Content-Length: 248
10 Expect: 100-continue
11 Host: ntweb8.ais.msu.edu
Here is the response header:
1 HTTP/1.1 200 OK
2 Server: Microsoft-IIS/5.0
3 Date: Fri, 10 Dec 2004 17:34:28 GMT
4 X-Powered-By: ASP.NET
5 Connection: close
6 Content-Length: 1043
7 Content-Type: text/html
8 Set-Cookie: ASPSESSIONIDQCQCQDBS=OEFOLADCEDMDCKNNFEEJJBOJ; path=/
9 Cache-control: private
As you can see, I am setting the user agent to "Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910."
I see from your comments that if the length is large I should pay attention to the content-length and don't use ReadToEnd. So for this particular application, where I expect to get about 40k each request, I could check the length and halt if the length is over say, 100k. This would not require me to learn how to use something other than ReadToEnd, since I am comfortable with that and don't have the lead time to learn more new tricks than necessary right now.
I am only interested in the frame named "Courses." This application is very specific, I will always only want the frame named "Courses," so I don't even need to parse the frames page unless the name of the "Courses" frame changes.
In your first post to my question, you said "...you can resolve relative URLs like so: Uri newUrl = new Uri(oldUrl, 'HeadingBlank.asp')..." My HTTPWebRequest POSTS is constructed using this statement based on UriBuilder:
uBuild2.Path = "ScheduleBook/schedule.asp";
Uri location = uBuild2.Uri;
So can I infer that on my POST for the "Courses" frame, I should simply reconstruct my Uri using this statement?:
uBuild2.Path = "ScheduleBook/intro.asp";
If so, how does the server know what page to return? From the cookie? From the postData?
If these assumptions are correct, then my process would be two-step: request frames page and cookie, then request "Courses" page (intro.asp). Can I short-circuit this process and just repeatedly request subsequent courses pages?
BTW, I am using Proxy Sniffer from David Fisher ( http://www.d-fischer.com) to compare my browser requests with my C# requests. It doesn't show that my browser is making multiple requests to get these frames, although it does show my browser making multiple requests to get other things like images.
|
|
|
|
|
JeromeKJerome wrote:
uBuild2.Path = "ScheduleBook/intro.asp";
If so, how does the server know what page to return? From the cookie? From the postData?
You just told it which page to return! Like Heath said, one file requested, one file returned. It's up to your code to parse out the filenames of the pages that make up the frameset. The first request will get back the 1K HTML you've been getting. Your code must then search through that returned data and find the <frame> tags, pull out the filename from the SRC parameter of the tag, then generate a new request using that filename. Do this for each frame tag... That's how a web browser does it.
JeromeKJerome wrote:
Can I short-circuit this process and just repeatedly request subsequent courses pages?
Yes! The intro.asp file is just it's own seperate HTML page. You can request just that page and it'll get returned to you just as if the browser requested it.
JeromeKJerome wrote:
BTW, I am using Proxy Sniffer from David Fisher ( http://www.d-fischer.com) to compare my browser requests with my C# requests. It doesn't show that my browser is making multiple requests to get these frames, although it does show my browser making multiple requests to get other things like images.
Your browser IS making seperate requests to get the pages specified in the frameset. It's the ONLY way it's going to get them. The Proxy Sniffer is either missing them, or you're misinterpreting what it's showing you, or it's entirely possible that the page requests aren't being generated because the browser is getting the content from it's cache.
Think of it this way... in your case, web servers are stupid. They only know how to return the file that was requested. They DON'T look into the contents of the file and pick out other files to return along with the requested file. They won't send any images, data, CSS sheets, or javascript files back with the requested page. It's up to the browser to interpret the page then make additional requests for each image, each CSS page, each script file, everything.
When you click on a <reply> link here at Code Project, your browser can make upwards of 35 requests to get all of the content that you see in this simple page!
RageInTheMachine9532
"...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
|
|
|
|
|
Yes, and as I said the first time you need to parse the frameset page and get the frame's src attribute, then create a new Uri using the frameset page's URL plus the src attribute to create an absolute URL. This is what your browser does. It does not fetch the entire page that you see in one request: it requests the page you requested (the frameset page), then requests the pages that it references, plus all the images, scripts, and other links that those pages reference. That's how HTTP works. That 40K of data is over several requests if you look carefully.
I showed you how to construct an absolute URL in my first reply. You must make a request using the absolute URL including the scheme and host, otherwise the request doesn't know what server to connect to. This is why you use the frameset page's URL and use the <frame src/> attribute to construct an absolute URL (so "http://www.domain.com/default.htm" as the frameset, plus a src attribute within that page of "pages/main.htm" would resolve as "http://www.domain.com/pages/main.htm"). If you use the Uri structure correctly (read the .NET Framework SDK for details) it will do this for you.
Again, this is exactly what your browser does in order to display all the frames and their images and other linked files - each made with a separate request.
This posting is provided "AS IS" with no warranties, and confers no rights.
Software Design Engineer
Developer Division Sustained Engineering
Microsoft
[My Articles] [My Blog]
|
|
|
|
|
Thanks, Heath. The problem is solved and I learned a lot about how to set up a structure to handles frames in my C# application. Your postings are top-notch!
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
