|
I have also found this helpful[^] article.
|
|
|
|
|
I am creating a networkstream and trying to send a bitmap.. ie.
NetworkStream DataWriter = m_ClientSocket.GetStream();
DataWriter.WriteLine(m_TestImage); //where m_TestImage is a Bitmap;
Is this incorrect or should i some how break it up into peices before i send it...
My problem is I don't know how to recieve it...
I have a thread that checks for DataStream.DataAvailable so I know when the stream starts. But I know it doesn't all come at once...
Could someone explain to me how to do this... I think it has something to do with NetworkStream.BeginRead();
If someone could help me that would be amazing....
Thanks for your time,
Steve Nelson
|
|
|
|
|
I'm looking for opinions here, so if the subject interests you, please reply. In the following post, runtime compilation is used to mean simple-to-use, on-the-fly access to the compiler, beyond eval statements, extending to the ability to compile full methods, classes, and assemblies.
1) Is runtime compilation worth the overhead (both in actual runtime cost and in time to implement/use)?
2) Is the ability to unload a previously loaded Assembly (possibly automatically, integrated into the garbage collector) important?
3) WARNING, Long Question: I'm building a .NET library (in C#) which gives full, optionally automated, simple, on-the-fly access to the compiler. The actual compiler access is done... However, building the complicated Remoting/AppDomain infrastructure is taking a while. Without this, there is no way to unload a runtime-compiled assembly before the main application ends. Is this final feature desirable and/or necessary for a good runtime compilation library?
Thank you for your time,
Eric Astor
|
|
|
|
|
It is now months since you posted this message. I hope you read this. Answers: 1) yes 2) not usually 3) no, not necessary. An interpreter you describe is very useful for testing. If that is the main purpose, memory leakage is not so important. Far more important is the user interface -- the command-line, or GUI.
Regards,
Frank Hileman
|
|
|
|
|
I appreciate your answers to my questions. I had actually conceived of this library as a tool for self-modifying code or code read in from a database and then executed, as opposed to a testing tool (which would seem redundant, as access to this library merely gives access to the .NET compilers, already present when the .NET framework is installed). In such an environment, I believe that memory leakage would be likely to become an issue. I would appreciate if you would possibly re-answer the third question as below, taking this into account.
3) I'm building a .NET library (in C#) which gives full, optionally automated, simple, on-the-fly access to the compiler. The actual compiler access is done... However, building the complicated Remoting/AppDomain infrastructure is taking a while. Without this, there is no way to unload a runtime-compiled assembly before the main application ends. Is this final feature desirable and/or necessary for a good runtime compilation library?
Thanks,
Eric Astor
|
|
|
|
|
The answer to 3) really depends on the usage of the solution. Your state the scenario, but there are not enough details in that scenario to answer the question. Why put the source in the DB? Why not compile and store the binary at the same time? What will the binaries be used for? Will the process using the binaries be long or short-lived (the most important question)? How often does the source change?
If you just throw away the process then there is no need for an appdomain infrastructure. Even if you build one, you may still see memory growing. I believe even unloading an assembly still may cause memory leakage -- I seem to remember a problem in the vsa newsgroup, anyway. Perhaps it is the string cache (interned strings). If the only sure-fire way is to use a temp process, your solution is simplified -- you only need remoting.
So you can look at the appdomain stuff as an optimization, and it may be you are optimizing something which does not need to be optimized. As I said, there is not enough info in your scenario to say exactly what is important.
For myself, I was thinking of a .net interpreter. Mainly for testing. It is very useful to have an incrementaly constructed environment for testing. Sometimes you don't want to write a whole program to test one function. You want to type something on a command line or use a gui and have the function tested. NUnit etc. are nice, but they are really for automated testing. To test interactively you need an interpreter, that can create typed variables, and can pass the values of those vars to functions, using a commmand line or a gui.
An interpreter, as I envision, would have to be able to do some run-time compiling, at least of expressions and functions. Command-line or gui variable assignments can be done with reflection, but expression evaluation must be very rich, as rich as a .net language, so you need a full-blown compile. If nobody does it I will do it someday. As I said, it is a time saver.
In such an environment memory will be wasted (all the little dlls created each time a change is made to an expression). But it does not really matter.
Regards,
Frank Hileman
|
|
|
|
|
Thank you for your points... I hadn't even thought of my runtime compilation component as a part of a logic-testing environment, and the features of a testing environment that you point out make the problem of memory leakage mostly irrelevant. Unfortunately, the points that you've made may not hold for my situation. The process (although not the thread) that requires code compilation in my solution should be rather long-lived, as it is a server in a centralized client-server architecture. However, thanks to your arguments, I've realized that an effective way to solve my problem is just to precompile each piece of code at startup of the server, then to access the compiled types. Although this may be expensive in terms of memory, it's much more efficient in terms of programming time required. I intend to polish my design of my existing Runtime Compiler interfaces slightly, then I'll use that. Once the entire server is finished, I'll probably write a CodeProject article on it... As this will be my first significant networking effort, aside from basic tests, the lessons that I learn may be useful to others working on other networking projects.
Thank you for your points,
Eric Astor
|
|
|
|
|
Just curious about the "expensive in terms of memory" comment. In one of our apps, we are generating code dynamically and compiling it, at either design-time or run-time, according to the user's requirements. Noticing that the codedom compiler was simpler than vsa, and allows C#, we used that. I noticed that compilation occurs out-of-process, except for jscript.net, even if you specify in-memory. If you force the compile into another process (in the case of jscript) the overhead seems to be entirely in time and not memory. Unless I am missing something.
We had to allow run-time code generation because the user's object hierarchy might be built at run-time. Normally, however, the hierarchy is built, code is generated and compiled, all at design-time. If you are curious, the app provides a way to graphically connect objects to realtime data sources, for process control and similar purposes. The compilation is needed for expression evaluation, and to avoid boxing during data transfer.
Regards,
Frank Hileman
|
|
|
|
|
True, compilation appears to work out-of-process... Except that once compilation is done, the CompilerResults object returned contains an Assembly object. The instant that the Assembly object is loaded into the process's memory (which can happen indirectly by loading the CompilerResults return value), the assembly (with all accompanying code and metainformation) is apparently irrevocably loaded into the process's AppDomain. This consumes memory. If I'm mistaken, please let me know.
|
|
|
|
|
I thought you were using the compiled types anyway, so I did not understand.
|
|
|
|
|
I have a client connecting to a server using sockets but when my client goes to send something to the server I don't know what event to use on the server side to see if it is there yet. Could someone help me... Oh and I need it to be asynchronous.
Thanks very much...
Steve
|
|
|
|
|
Hi
I'll try to describe as much as possible.
I have my main app running in the default appdomain. I load a plugin manager class in a new AppDomain(plugin). I pass an instance(Connection class) from my main appdomain to the "plugin" appdomain by ObjectHandle. My plugin manager class then loads the plugin assemblies. These assemblies in turn registers to some events from the Connection reference in the "plugin" appdomain. Everything (loading/unloading/events/methods/etc) functions as it should except, when registering the events in my plugin , the plugin's assembly gets loaded in the main appdomain.
The question is how can i "subscribe" to these events without the main appdomian havin to load the plugin assembly? I have thought perhaps "chaining" the events to a new class in the plugin manager assembly and let my plugin subscribe to those. Seems like a lot of work (and the possiblitlity of creating duplicate/error-prone code).
Damn its seems a language is sometimes too type-safe for your liking.
Any input would be appreciated. I can mail you the code as well. A bit much too post. 
WebBoxes - Yet another collapsable control, but it relies on a "graphics server" for dynamic pretty rounded corners, cool arrows and unlimited font support.
|
|
|
|
|
I think the recommended solution is to create a small assembly containing the portions of code to be shared between te main app and the plugins. In your case it would include the delegate definitions as well as anything else that both sides need to use.
The idea is to keep this assembly small so you don't incur a large penalty for loading it twice.
James
"It is self repeating, of unknown pattern"
Data - Star Trek: The Next Generation
|
|
|
|
|
James T. Johnson wrote:
I think the recommended solution is to create a small assembly containing the portions of code to be shared between te main app and the plugins. In your case it would include the delegate definitions as well as anything else that both sides need to use.
I ended up makin a "proxy" class for the object that fires these events. Basically:
con.Listener.OnPublic += new PublicMessageEventHandler(OnPublicMessage);
public void OnPublicMessage(UserInfo ui, string channel, string message)
{
if (Public != null)
Public(ui, channel, message);
}
public event Sharkbite.Irc.PublicMessageEventHandler Public;
Now this work nicely, but I will be a pain in the $#% for all the events about 50, as I can see no way of get parameters for a delegate via reflection. I think i can add/remove the delegates once I have all my event raising methods in place. Maybe I can do some filtering...but there seems no way I can do the raising method programatically.
The single event I have implementented works as should, and the main appdomain does NOT load the plugin's type. Thus the file is deletable once the appdomain is unloaded and it even allows me to debug, and invoke the plugin.
Another idea I had was perhaps make an abstract base class that already has all the consumer methods in place that will act as a template for the plugin the pass a downcasted instance of the plugin. But again I wasnt sure ifthe main appdomain would load it.
Yet another (but I have now clue on this) is to make my own implement ation of a RealProxy object. Everything seems to point to that...
Anyways thanks for the help
Cheers
WebBoxes - Yet another collapsable control, but it relies on a "graphics server" for dynamic pretty rounded corners, cool arrows and unlimited font support.
|
|
|
|
|
leppie wrote:
Another idea I had was perhaps make an abstract base class that already has all the consumer methods in place that will act as a template for the plugin the pass a downcasted instance of the plugin. But again I wasnt sure ifthe main appdomain would load it.
Just make sure that you actually do the cast instead of letting inheritance take its course. Nish and I found out while he was working on remoting that if you don't do the cast, the appdomain on the other side will try to load the assembly containing the derived class.
ex
class BaseClass
{
public abstract BaseClass GetInstance();
}
class DerivedClass : BaseClass
{
public override BaseClass GetInstance()
{
return (BaseClass) this;
}
}if you don't perform the cast then it returns a reference to the type DerivedClass which the original appdomain doesn't know about, so it tries to load that assembly into its appdomain.
In a remoting scenario where that assembly doesn't exist on the client side this results in an AssemblyNotFoundException (or whatever that exception is really called). In your plugin scenario it will either do that or it will find it and load it, nullifying the advantage of having a separate appdomain.
James
"It is self repeating, of unknown pattern"
Data - Star Trek: The Next Generation
|
|
|
|
|
|
Did you look into the soapsuds.exe tool? It generates empty proxy classes from your real class libraries.
Gertjan Schuurmans
Amsterdam
|
|
|
|
|
It appears soap require webservices, and that would make it difficult (for me anyways) to incorporate a web service in a single application. If not so, I think I have been re-inventing the wheel here  . I will definately check it out. OK, I just did, and it seems it does (the basic model) what I have done (damn why do they allways come up with MY clever ideas!!!!!). I have a couple more clever reflection tricks though
The only other question I have is how does the object get activated? In my case the object is serverside-activated (in fact the "plugins" consume events from a persisted object). It appears that the object need to be created client side from the generated code.
Thanks
WebBoxes - Yet another collapsable control, but it relies on a "graphics server" for dynamic pretty rounded corners, cool arrows and unlimited font support.
|
|
|
|
|
|
|
Hi there!
Yep, I think you are stuck in a two-way dependency: you need a remotable(serializable) server for to call from within the plugin, and a serializble plugin for callback.
My guess is to try to narrow this dependency down to a minimal IPlugin interface and a remotable server.
hope this helps 
Gertjan Schuurmans
Amsterdam
|
|
|
|
|
Gertjan Schuurmans wrote:
My guess is to try to narrow this dependency down to a minimal IPlugin interface and a remotable server.
I need it even simpler, no server....I just need to "proxy" the event. Thats said I have most of it working as it should, except for on problem (later on that).
The way the it is as such:
I have a PluginManager assembly that contains some classes, interfaces for for the handling and codegen. Then I have a UI app to select all the types required by the plugin. This UI will then do some mean CodeDom (unfortunately only C#, due to a CodeDom bug perhaps???) to generate a proxy class for each selected type and an interface for it, as well as a interface for the plugin and user class for the implementation. From there its a few lines of code to implement it.
The problem however that im having is with AppDomainUnloadedException. I have rechecked my code x 1000 and cant see why this happens...
Thanks for the help
WebBoxes - Yet another collapsable control, but it relies on a "graphics server" for dynamic pretty rounded corners, cool arrows and unlimited font support.
|
|
|
|
|
Does anyone know how to use the SqlClientPermission? I'm having trouble opening up the SQL connection security in a UserControl. The User Control is embedded in Internet Explorer. All I get is access denied.
Shane L. Hatcher
|
|
|
|
|
|
Yes we are using integrated security. But, digging down deeper into the problem, I found that the problem may be caused by the .hta application extension. Our application is using the .hta application extension. Unfortunately, we can't change the extension.
When I run the .NET UserControl in an .htm file, it works fine. I don't get an access denied exception. But when I run the control in an .hta file, I get the access denied error. I have tried to assert the security permissions, with no luck at all. Do you have any suggestions?
Thank you,
Shane L. Hatcher
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
