|
I was not sure if the error is related to Visual Studio, or .NET Framework, or Managed C++. Anyways, the problem is resolved now. Thanks. 
ARSALAN MALIK
|
|
|
|
|
Even just a nudge in the right direction would be much appreciated...
I'm trying to use events with remoting over a tcp channel (writing in C#, mostly), and I'm getting this Security Exception thrown:
"System.Security.SecurityException: Type System.DelegateSerializationHolder and the types derived from it (such as System.DelegateSerializationHolder) are not permitted to be deserialized at this level."
I'm running this under an administrative account, and so far all the code is running locally on the machine. From what I've learned so far about security, I thought that all local code was defaulted full-trust permissions, so I'm not sure what the problem is. I've looked at several articles in various places, but most seem like just a general introduction to .net security.
Any help would be greatly appreciated.
|
|
|
|
|
bwilhite wrote: Even just a nudge in the right direction would be much appreciated...
I just wouldn't do it, period. The idea of an event is nothing more than an async message sent by the server to the client, i.e., not in direct response to a request, but in response to an event on the remote host side of the client server architecture. However the complications added by network protocols and security by attempting to use something as integrated as .NET events just seems like a bad idea. It is possible you have chosen an inappropriate approach given your requirements.
Eventing is reliable in case of named pipe scenarios on same machine but not over network. So if underlying sockets close connection eventing won’t try to establish it for you. Using events over network is not recommended. But if you still want to use it, this post takes us over a simple client server example
No mention of security issues but it might help somehow:
http://blogs.msdn.com/dotnetremoting/archive/2006/04/07/571020.aspx[^]
led mike
|
|
|
|
|
Thanks that gets me going in the right direction.
As far as not doing it at all...this is experimental at this stage, but the only other real option would be our own full-fledged remote proxy. The concept of an event is the right one here... From what I can tell, we'd be duplicating *a lot* of the work done already by .net remoting...but like I said still experimental, and not sure which way we might go anyway.
Incidentally, using a callback mechanism caused a similar security problem.
|
|
|
|
|
|
hi there,
i had the same problem once, my solution:
first, you have to supply some sinkproviders to your tcpchannel before marshalling your remoting object:
<br />
BinaryServerFormatterSinkProvider serverprovider = new BinaryServerFormatterSinkProvider();<br />
BinaryClientFormatterSinkProvider clientprovider = new BinaryClientFormatterSinkProvider();<br />
<br />
serverprovider.TypeFilterLevel = TypeFilterLevel.Full;<br />
<br />
IDictionary properties = new Hashtable();<br />
properties["port"] = 9876;
<br />
TcpChannel chan = new TcpChannel(properties, clientprovider, serverprovider);<br />
<br />
<br />
then you have to add some stuff to your shared assembly (where you share intefaces between server & clients)
add your event to the interface
<br />
public interface IMyServiceInterface {<br />
event System.EventHandler<customeventargs> MyEvent;<br />
}<br />
</customeventargs>
i also added a CustomEventArgs class to my shared assembly (System.EventArgs wasn't sufficient for my application, but you could just use EventArgs if you don't need to supply some custom information to your Eventhandler)
then (maybe the most important thing) add an eventwrapper to your shared assembly:
<br />
[Serializable]<br />
public class MyEventWrapper: MarshalByRefObject<br />
{<br />
public event EventHandler<customeventargs> OnWrapperMessage;<br />
public void WrapperMessagehandler(object sender,CustomEventArgs e)<br />
{<br />
if(OnWrapperMessage!=null)<br />
{<br />
OnWrapperMessage(sender, e);<br />
}<br />
}<br />
public override object InitializeLifetimeService()<br />
{<br />
return null;
}<br />
}<br />
</customeventargs>
now you can use the event in your client the following way:
<br />
IMyServiceInterface service =
MyEventWrapper w = new MyEventWrapper();<br />
<br />
service.OnLogData += w.WrapperMessagehandler;<br />
w.OnWrapperMessage += handler_formyevent;<br />
<br />
...<br />
<br />
<br />
void handler_formyevent(object sender, CustomEventArgs e)<br />
{<br />
}<br />
maybe it looks a little bit complicating but that was how i managed the problem that you cannot use events in a normal way over remoting channels.
i hope this helps
|
|
|
|
|
Thanks. That seems to be pretty much what I ended up doing. The article I was going off of called it an event shim. One thing that isn't really clear to me is why the wrapper/shim works. In other words, you can't just do
<br />
service.OnLogData += handler_formyevent;
You have to give it to the wrapper, which can subscribe (why, I'm not entirely sure), and then subscribe to the events that it raises.
<br />
MyEventWrapper w = new MyEventWrapper();<br />
<br />
service.OnLogData += w.WrapperMessagehandler;<br />
w.OnWrapperMessage += handler_formyevent;
hmmm...is it because the wrapper is known to both assemblies that it works, whereas doing it the other way, the service isn't really aware of the subscriber? So in the scenario where it doesn't really know about the subscriber it can't grab a remote reference to it, so that it can marshal the events over?
I hope that makes sense...is it correct?
BW
|
|
|
|
|
Hi all,
I have two questions to ask:
1.I am writing a web service that gets some information and ...
And I want to save this information to an XML file ...
In other words I want to Create,Edit,Delete and save an XML file over the internet and I thought by using a web service I can handle that...
But XmlWriter doesn't support URI format...please help me...
2.How to use an Object (like datagridview) in a thread?
I mean cross-thread operations...I tried to use CheckForIllegalCrossThreadCalls=false
but as MSDN says it is unsafe and also it dosn't run well...
Please help with any of issues...
thanks...
Every new thing you learn,Gives you a new personality.
|
|
|
|
|
I see points made, is there a specific question in there?
"I guess it's what separates the professionals from the drag and drop, girly wirly, namby pamby, wishy washy, can't code for crap types." - Pete O'Hanlon
|
|
|
|
|
Why would you want to do either of these things? They both sound like terrible ideas.
Paul Marfleet
"No, his mind is not for rent
To any God or government"
Tom Sawyer - Rush
|
|
|
|
|
As for #2...
Have you tried using a SynchronizationContext object to marshal the call to the correct thread?
In the UI thread set your myContext = SynchronizationContext.Current;
Then when you need to make that cross-thread call you do
myContext.Post();
Inside the Post you have to give it a callback method (I can't remember the name...I let intellisense remember for me :P ), along with an object which is sent to the callback method
in the callback method is where you actually change your UI object...
This works nicely for me.
The other two options are the one you tried, and using an AsyncOperationManager object, I like this one though.
|
|
|
|
|
This isn't about the database side of it - it's about the code that was generated.
In a web site, another developer used the table adapter wizard to create some queries. Here's one of the generated blocks of code (he's using a stored procedure in Scalar mode):
public virtual object InsertMyThing(string MyThing)
{
System.Data.SqlClient.SqlCommand command = this.CommandCollection[1];
if ((MyThing == null))
{
command.Parameters[1].Value = System.DBNull.Value;
}
else
{
command.Parameters[1].Value = ((string)(MyThing));
}
System.Data.ConnectionState previousConnectionState = command.Connection.State;
if (((command.Connection.State & System.Data.ConnectionState.Open) != System.Data.ConnectionState.Open))
{
command.Connection.Open();
}
object returnValue;
try
{
returnValue = command.ExecuteScalar();
}
finally
{
if ((previousConnectionState == System.Data.ConnectionState.Closed))
{
command.Connection.Close();
}
}
if (((returnValue == null) || (returnValue.GetType() == typeof(System.DBNull))))
{
return null;
}
else
{
return ((object)(returnValue));
}
}
I recently added the same thing to a project I'm working on. Here's my code:
public virtual System.Nullable<int> InsertMyThing(string MyThing)
{
System.Data.SqlClient.SqlCommand command = this.CommandCollection[1];
if ((MyThing == null))
{
command.Parameters[1].Value = System.DBNull.Value;
}
else
{
command.Parameters[1].Value = ((string)(MyThing));
}
System.Data.ConnectionState previousConnectionState = command.Connection.State;
if (((command.Connection.State & System.Data.ConnectionState.Open) != System.Data.ConnectionState.Open))
{
command.Connection.Open();
}
object returnValue;
try
{
returnValue = command.ExecuteScalar();
}
finally
{
if ((previousConnectionState == System.Data.ConnectionState.Closed))
{
command.Connection.Close();
}
}
if (((returnValue == null) || (returnValue.GetType() == typeof(System.DBNull))))
{
return new System.Nullable<int>();
}
else
{
return new System.Nullable<int>(((int)(returnValue)));
}
}
</int></int></int>
When he calls his adapter function, he uses the following:
int id = Convert.ToInt32(adapter.InsertMyThing(MyThing));
When I try that with MY adapter function, I get an Invalid Cast exception.
If you haven't already noticed, the return type is different in my version of the function, yet we both used the adapter wizard to create the queries, and we're using the same database/stored procedures.
What's going on here?
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
Can you even cast a System.Nullable to an Int32?
---modified
I tried something similar and the compiler barks at me that I cannot return a static type System.Nullable 
"I guess it's what separates the professionals from the drag and drop, girly wirly, namby pamby, wishy washy, can't code for crap types." - Pete O'Hanlon
|
|
|
|
|
My real question is why does the same wizard output different code? The return types are the only difference.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
Strange. Got me on that one 
"I guess it's what separates the professionals from the drag and drop, girly wirly, namby pamby, wishy washy, can't code for crap types." - Pete O'Hanlon
|
|
|
|
|
John Simmons / outlaw programmer wrote: What's going on here?
Different drivers?
Different IDE (Wizard) versions?
John Simmons / outlaw programmer wrote: and we're using the same database/stored procedures.
The same instance or copy?
Something somewhere must be different yes?
led mike
|
|
|
|
|
I have a class lib - let's call it Lib1.
I have a class lib that uses Lib1 - let's call it Lib2.
I have an app that references Lib1.dll and Lib2.dll in their respective bin/debug folders - lets call it App1.
When I make a change in Lib1 or Lib2, I have to remove all references to the changed lib, and do a build all - let's call that bullshit.
Someone please tell me I'm missing some elegant aspect of .Net that makes sharing code between projects easier.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
I've not experienced any problems with my Common library.
When i make changes to it, i place the new copy in a shared Release folder that is referenced too by all using apps, and the new functionality shows up in my application without any need to do a re-build.
Are you referencing the projects directly from their respective bin folder or including them as existing projects?
Tris
-------------------------------
Carrier Bags - 21st Century Tumbleweed.
|
|
|
|
|
I'm referencing them from the bin folders.
The primary problem appears to be that when you do that, a copy of the DLL is put into your project's bin folder, but apparently only if it doesn't already exist there.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
From what i know, CopyLocal copies it to your output directory, which you have to do if it isn't loaded in the GAC.
I don't know why its working for me.
Could this be a WTF?
T
-------------------------------
Carrier Bags - 21st Century Tumbleweed.
|
|
|
|
|
Perhaps not a .NET thing but a VS one. I think there are many approaches. One that I like to use frequently is to add the project to the solution rather than just referencing the binary from a folder. There may be drawbacks to that you don't like but at least try it to see if it works for you.
led mike
|
|
|
|
|
putting all related projects in a single solution must solve it for sure.
However in my experience (it has been discussed on one of the forums too) in VS2005 it typically
causes too much rebuild activity when something got changed. I'm not sure that got fixed in VS2008.
Luc Pattyn [Forum Guidelines] [My Articles]
This month's tips:
- before you ask a question here, search CodeProject, then Google;
- the quality and detail of your question reflects on the effectiveness of the help you are likely to get;
- use PRE tags to preserve formatting when showing multi-line code snippets.
|
|
|
|
|
Luc Pattyn wrote: it typically
causes too much rebuild activity when something got changed.
Depends on your definition of "too much" I suppose. One could also choose to just have some cheese with their whine right? 
led mike
|
|
|
|
|
You can change the build output path of the class library projects to output to the bin folder...and not into debug or release folders under the bin folder. This way, you can reference that ONE build of the class library and not have to rereference all the time. That's as long as you don't need both the debug/release versions stored there.
Hope this helps.
|
|
|
|
|
That's fine until you go to use the same class library in another project. Then you have to play musical directories for the new solution, thus breaking the previosu solution that also uses the class library.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
