|
Just like the MFC source code
I'm amumu, and you?
|
|
|
|
|
Yes, you need to use Anakrino
You can download in here
htpp://www.saurik.com
|
|
|
|
|
Rama Krishna wrote:
Yes, you need to use Anakrino
What does Anakrino do?
Disassemble?
Nish
Regards,
Nish
Native CPian.
Born and brought up on CP.
With the CP blood in him.
|
|
|
|
|
Nish - Native CPian wrote:
What does Anakrino do?
Disassemble?
Use it and see
I use it so often that I don't see MSDN docs anymore. I can't survive without it.
|
|
|
|
|
Rama Krishna wrote:
Use it and see
I use it so often that I don't see MSDN docs anymore. I can't survive without it.
Hello Rama
It is an interesting tool indeed. But I really don;t undersyand why you say that it is a replacement for MSDN 
Nish
p.s. pardon the typo errors please. I cant be bothered correcting them 
Regards,
Nish
Native CPian.
Born and brought up on CP.
With the CP blood in him.
|
|
|
|
|
Nish - Native CPian wrote:
But I really don;t undersyand why you say that it is a replacement for MSDN
I only rarely look at docs for a description of what a class/method/property does anymore. I just see Anakrino. This was the way i did with MFC and esp. ATL.
|
|
|
|
|
If you want to get real down and dirty; you can look at the source to Rotor which is the Shared Source version of .NET meant for FreeBSD.
The source for .NET on Windows machines IS different; though differences aren't pointed out.
James
Simplicity Rules!
|
|
|
|
|
hello,
to get information from the dll ie. the methods,types, parameters i use Reflection. at certain times i have to delete this dll which is usually not a problem. the problem is once i've reloaded a dll and performed some reflection on it, that when i go to delete the dll using FileInfo.Delete() i get an Access is Denied exception. so its as if the dll is still being used or a thread that's still alive or.... this one's got me stumped. maybe there's a better way of reflecting the information from the dll or something.
here's the code starting with the Reflection: pretty straight forward. so i get the dll pass it into an Assembly and there you go. for what i need to do i think its about the easiest least overhead way.
string tempPath = Path.GetTempPath();//Gets the path to the MS tempdir
string strMSTempPath = tempPath.Replace(@"\", @"\\");
string strTempName = strNameSpace + ".dll";
Assembly ass = Assembly.LoadFrom(strMSTempPath + strTempName);
string strObject = strNameSpace + "." + strServiceName;
Type typeDynProxy = ass.GetType(strObject);
MethodInfo[] methodArray = typeDynProxy.GetMethods(BindingFlags.Public|BindingFlags.Instance);
this is how i delete the dll from the directory. nothing fancy.
string tempPath = Path.GetTempPath();
string strTempName = tempDeleteDLL + ".dll";
FileInfo fileInfo = new FileInfo(tempPath + strTempName);
fileInfo.Delete();
throws the Exeption as soon as it executes Delete():
"Access to the Path C:\..\..\ is denied."
normally i can delete the dll. just not after i run the Reflection code above.
any ideas or help would be great.
thanks
Orion
|
|
|
|
|
The problem is that once an assembly is loaded into an AppDomain the assembly isn't unloaded until the AppDomain is unloaded.
An AppDomain is a basic unit of execution; its similar to a process in Win32; but in .NET a single process can host multiple AppDomains.
So what you need to do is create a new AppDomain, then load the assembly into that; the tricky part is you can't have any reference of that assembly in your current AppDomain, otherwise the assembly gets loaded into it too.
I don't have any code laying around for that; but it is something I plan on looking into when I get back from my little vacation
James
Simplicity Rules!
|
|
|
|
|
Thanks James, you guys and this site rules..!!
i figured it was a deeper problem. so bear with me i just need to get this straight before i dive in here. its the reference part that's got me. of course  )) if i get this figured out i'll send you the code.
outside of the dll issue, where does the one AppDomain start and end? if i understand it right an application running is made up of many AppDomains (ie. WinForms, Projects..), but the AppDomains are referencing each other within a singular process. OR, is an Application all being combined into a singular AppDomain regardless of whether i create a New AppDomain or not?
the way i have it right now i've got a Windows.Form which is referencing a separate class which obviously is doing all the work, and that's all part of the main App running. so, and correct me if i'm wrong, by your explanation, that class and everything it does gets added to the "Calling" AppDomain (WinForm), and by that logic all WinForms/Components what ever, ends up being combined into a singular AppDomain. Do i have that right?? Or do they remain separate at least to some degree.
so i'm wondering to what degree i need to keep this New AppDomain "isolated".
in the problem i'm having i'm not instantiating the dll or invoking methods, classes or anything like that. i purely need some info from it (it will be later but by that pt i won't have to worry about deleting it).
hope i made sense here.. ))
Thanks.
Orion
|
|
|
|
|
Check out my latest column on AppDomains and dynamic loading:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dncscol/html/csharp05162002.asp
|
|
|
|
|
Thanks Eric, I will..
Orion
|
|
|
|
|
How to add image besides each item in ComboBox?
And how to load 2 columns from a table (id and name for example) as one item in ComboBox? (id will not show,Name shows there, but after select, pass id as parameter)
Thanks.
|
|
|
|
|
Hi,
I've seen a few Server/Client programs here. Many of the server programs that can handle many connections at the same use asynchronous calls. I just can't figure out why this approach is popular in C#. Why most people use it instead of threads? Any advantages? If I want to write a ftp server that
can take control of each connection(e.g. D/L speed control, kill connection on user's demand), are asynchronous calls recommended in this case?
Is the underlying mechanism of asychronous calls also use threading things?
Thanks in advance
A beginner
|
|
|
|
|
When there are too many connections, there are too many threads and if each connection requires moderate to heavy processing, you'll bring the machine down in no time
Nish
Regards,
Nish
Native CPian.
Born and brought up on CP.
With the CP blood in him.
|
|
|
|
|
The "NT family" of Windows (ie NT, Win2K, WinXP) supports a feature known as "I/O completion ports". In this feature, the O/S calls back to the user code when an I/O operation completes. In .NET, the built-in async functions use this support.
That means you can be waiting for 100 different read operations to finish using completion ports without a lot of overhead, where if you used threads, you'd need to have 100 of them running at the same time, and that takes a lot more resources.
|
|
|
|
|
Eric Gunnerson (msft) wrote:
In .NET, the built-in async functions use this support.
Wow! That's cool info Eric Gunnerson. Thanks for that. It amazes me also to see you spot just the right threads here on CP.
Thanks, once again,
Nish
Regards,
Nish
Native CPian.
Born and brought up on CP.
With the CP blood in him.
|
|
|
|
|
|
Thank you
but when to use threads? I mean what situations are better for creating threads, or in what cases, using asynchronous calls would be better? Now, I see that creating threads is more costly than using asynchronous calls. It seems that I cannot control the number of "threads" using asynchronous call. Then, if I'm writing a ftp server that only take 5 connections in maximum, it looks useless to me, is it?
|
|
|
|
|
One reason to use async over threads would be in the case of file transfers. You would need to have the thread spinning and polling for completion. With an async call you would be notified when the operation completed. I would say a thread would be better used for a things like background operations, like refreshing a directory listing. It can be launched while the use is doing something else without interfering.
|
|
|
|
|
If there's built-in support using completion ports (ie there are BeginXXX() and EndXXX() calls on the class), I think that's always the preferred choice, since it doesn't take any threads at all.
It is true that for small numbers of concurrent processes, it can be a lot easier to write them as separate threads, because you can write the code all at once as part of a method, while with the async case, you may have to write your code in several chunks as part of the callback routines.
|
|
|
|
|
If there's built-in support for async (ie the class has BeginXXX() and EndXXX() methods), then you would normally use that if you care about scaling.
If you're writing something small, then writing the threaded version is generally easier, because you write your code in one chunk rather than having to write several callback functions.
|
|
|
|
|
Eric Gunnerson (msft) wrote:
The "NT family" of Windows (ie NT, Win2K, WinXP) supports a feature known as "I/O completion ports". In this feature, the O/S calls back to the user code when an I/O operation completes. In .NET, the built-in async functions use this support.
What happens on 98/ME (*shudder*)?
James
Simplicity Rules!
|
|
|
|
|
On the 98 series, the runtime emulates the feature using threads.
|
|
|
|
|
Thanks Eric
James
Simplicity Rules!
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
