|
IrvTheSwirv wrote:
I'd describe that as thrashing rather than leaking
There have been some instances where gc does leak memory, check James post below, I was actually more thinking about the scenario and possiblity of such occurance.Imagine having a real-time app. which reads tons of data and displays them in a chart in several windows, this requires frequent memory allocations and is also processor intensive.
Cheers,
Kannan 
|
|
|
|
|
Kannan, (my neighbour got same name )
I ran across this info on FogCreek site.
Monitor memory leakage[^]
Hope this info helps.
"I think anybody who doesn't think I'm smart enough to handle the job is underestimating." George W. Bush
--U.S. News and World Report, April 3, 2000
This signature was created by "Code Project Quoter".
|
|
|
|
|
Thanks Kant, I will have a look into this.
Cheers,
Kannan
|
|
|
|
|
There is also a bug in .NET 1.0 where the GC would fail to free memory more than 8MB was allocated. Typically you'd see this when you have a large struct and create a large array of them.
I'm not wording that description correctly, but it isn't a problem you'd often see unless you were doing long [] arr = new long[int.MaxValue] or something like that.
Gah, I just can't find the right words 
[edit]Forgot to mention that this is supposed to be fixed in .NET 1.1[/edit]
James
"I despise the city and much prefer being where a traffic jam means a line-up at McDonald's"
Me when telling a friend why I wouldn't want to live with him
|
|
|
|
|
Kannan Kalyanaraman wrote:
Daniel, I read somewhere in the net about a memory leak caused by processor intensive applications.
For ex. in an app, if there are some processor intensive operations along with some non-trivial memory allocations, tehre is a chance that because of the processor intesive nature, the GC might not have a chance to deallocate, 'cause GC runs as a low priority thread. Is there any truth to this.
What you say have some logic, but I doubt it occurs in real world code. Sure, if you set a thread's priority as "real time", then Windows won't switch from that thread and you may have the mentioned behavior. But, in any other circumstances, GC should be able to run and fulfill memory requests.
Kant wrote:
Actually she replied back to me "You shouldn't fix the bug. You should kill it"
|
|
|
|
|
I think making the thread's priority "real-time" is not recommended, as it affects the OS performance. Anyway, thanks for the clarification
<edit>
Another possible solution to getaway from this scenario (if one exists) is by calling GC's collect method, at predetermined intervals during an apps' life-cycle.
I'm not thinking about using this for normal apps, but for special case apps which use more processor + memory (for ex. a server, or a real-time app. which plots graph from huge data).
</edit>
- Kannan
|
|
|
|
|
Daniel Turini wrote:
Notice the "virtual" word, it means that it can use up to 1MB of stack space, but it could be (and probably is) using even under 1Kb of this space.
Learned to something new.. Thank you.
More you deliberate, more the chances of error.
This signature was created by "Code Project Quoter".
|
|
|
|
|
I have an application that relies on assembilies. The application has an interface defined and when an assembly is loaded checks to see if the class loaded implements the interface. The problem is that the interface is defined in one folder and the assembly is defined in another folder (the assembly folder is not a sub-folder of the first, however I might make it a sub-folder later on. Would that make a difference??). I am little unsure on how to do this. Implementing the interface is where I get stuck:
dir A:
public interface Drivers{}
public class DriverManager{
//verifies that the assembly loaded implements interface Drivers
}
dir B (contains the Assembly):
public class Driver1 : Drivers (how do i reference the interface here???)
{}
The problem is that I cannot get the class Driver1 to compile because it cannot find the interface Drivers due to the fact that Drivers resides in a different directory.
|
|
|
|
|
It has nothing to do with the directory.
namespaces is the key. If you were going to implement the
IDisposable interface how would you be able to do that if that
were the case?
If it is in a different namespace then add the using MyInterfaceNamespace
or use the full namespace and interface name were you declare the interface.
Bo Hunter
|
|
|
|
|
I did include the the namespace with using. When I include all the files in the same directory. I am able to get it to compile. Is there a path I need to set like in Java?
|
|
|
|
|
I can see how you might not be able to get it to RUN but I'm not sure about the compile part...
Quick checklist for ya!!
1) 3 projects (Interfaces, Implementer of interfaces, User of interfaces)
2) All projects loaded in a single solution
3) Implementer and User have project based references to Interfaces.
The load methods of assembly generally require the path to be specified or that the loaded assembly be "relative" to the callers assembly!
More Info!
|
|
|
|
|
I added the two projects to the same solution and referenced one to the other. I use the Loadform method and pass the entire path of the dll. In fact, the interface is in the same namespace as the class that trys to implement that interface. But the that class is part of an dll that depends on the host application (where the interface resides) and is in a different directory. Even when using Microsoft Intellisense, it is not able to detect that the interface and class are in the same namespace (I do include using statement in class definition). I am not sure if its because the two files are in separate dir or in different projects.
I just gave the Interface and the implementer of the interface different namespaces and I get an error when trying to compile complaining that the other namespace does not exist. Here's the error message:
"The type or namespace name 'IDrivers' could not be found (are you missing a using directive or an assembly reference?)"
I would apprecitate any help provided as I am new to C# and am completely stuck on this. Thanks
|
|
|
|
|
No probs with the helping... we'll get this one cracked!!
If I can try to explain how I think you want to implement what I think your trying to do and you can scream at me and tell me I'm stupid 
* You have a forms app
* You have an assembly dll with interface definitions
* You have another assembly with an implementation of said interfaces.
You want to Have your app know about only the interfaces and dynamically at run time look into a dll assembly and instantiate a class which implements the interface...
This is how you do it...
* In a solution add the three projects.
* In your Main app in solution explorer you go to "references" and then right click and select "Add Reference". When the dialog comes up select the "Project References" tab and select the project which defines the interfaces.
* In the "plug-in" (the assembly which IMPLEMENTS the interface) do the same thing, Add Reference->Project References->Select the assembly which defines the interfaces.
To explain this bit. The compiler needs to know where these Dlls are for the linking stage so what happens when you add a project based reference is that Visual Studio will make sure an up-to-date copy of the appropriate assemblies are in your bin folder. If you use a non-project based reference you can get into trouble.
If you follow the above points, assuming your "usings" are correct too your app will build and assuming the path to the dynamically loading assembly is correct the whole thing will work. (Don't forget to test for a "FileNotFoundException")...
Hope that's a bit more help... 
I __AM__ going to write an article about this issue!
Cheers
Shaun
|
|
|
|
|
Thanks for the reply Shaun.
The way my app is set up right now is that I have a forms app where the interface definitions are part of the form app. Meaning that the interface definitions will be part of the app exe. The interface def are not part of their own assembly. The implmentation of the interfaces are indeed in another assebly. I have already referenced the assembly to main app but this does not solve the problem. Originally I did not have this set up, but then I referenced the dll to the host app, but nevertheless the assembly cannot find the interface definition. I am unclear as to what further steps I can take to solve this problem.
|
|
|
|
|
Ahhhh! Now I'm with you!!
You can't do it that way. You need to put your interfaces in a separate assembly so that they can be shared and accessed by both EXE and DLL without the EXE needing to know anything about the DLL.
You can't make the assembly reference the EXE project, that just won't work.
Before .NET you could possibly have included another copy of the .cs file that defined the interface in the DLL but because types are best accessed as fully-qualified-names you won't really get away with that.
So, to recap.
The standard (if indeed, THE correct) way to do what you need to do is to mave your interface definitions from the EXE into a separate dll then reference that project in both the EXE and DLL project.
Shaun
|
|
|
|
|
Yep that did the trick!! Thanks so much for your help!! It is really appreciated.
But I don't understand why the interface needs to be in a separate assembly. I figured that by putting the interface in the same namespace as the user of the interface they would be able to reference each other. What is the concept behind putting the interface in a separate assembly. Or can you give me a brief explanation of why this is the correct architecture.
Thanks again for your help.
|
|
|
|
|
No Probs...
In terms of Interfaces and namespaces I'll try to explain...
Just because you put a bunch of types in different assemblies into the same namespaces doesn't mean that those types are merged together into one namespace.
When you add a reference to another assembly or project the namespaces of that assembly of project becomes accessible to the exe or dll making the reference. The thing is, if you're typing code and using intellisense the IDE merges the namespaces for you but if you look in object browser I don't think they are. Basically the key to accessing code in another assembly is in the references not the namespaces. (That probably makes no sense at all  )
As far as the separate dll for Interfaces I'll try to chuck some words down...
There are two reasons: one is architectural good practice, the other is a physical considerations.
Architectural- Good code design dicatates separating 'interface' from 'implementation' everywhere possible, from 'GUI' and 'Business code', to 'class definitions' and 'implementation'... With interfaces (as in public interface foo{}) you might specify a bunch of them for your application and insist that any part of the system that uses other parts of the system do so using interfaces. The advantage of this is that you can make your code modular and extensible without much effort.
For example you could have a text editor which has a bunch of import filters which all have to support ITextFilter... in future you might want to add new ones which is no problem so long as the new filters support ITextFilter.
Physical- the physical reasons are to do with the old references. If you have a set of assemblies with intefaces and code together then you want to create new code that implements those interfaces too (say on a remote machine for example) you would have to copy all of the dlls with code onto the other machine in order to provide the inteface definition. This is BAD... the best way is to have a small assembly which defines interfaces and have clients and servers reference that. It's also a convenient place to store them too for maintenence.
The other limitation in your case was that your interface was defined in your exe which under .NET is a bit of a no-no, as project references only work with .dll type assemblies.
Sorry if that was patronising (or wrong ) I was kinda in the zone!!
Shaun
|
|
|
|
|
Thanks for that Shaun. Its a little clearer now.
|
|
|
|
|
IrvTheSwirv wrote:
If you follow the above points, assuming your "usings" are correct too your app will build and assuming the path to the dynamically loading assembly is correct the whole thing will work. (Don't forget to test for a "FileNotFoundException")...
I got a question on this issue. Say my EXE looking for the DLL's. They are properly referenced in the project, what if the DLL's (assemblies) are missing physically at runtime. What's the order of searching for this assemblies? ex: search in local directory, if not search in the GAC....
"FYIFV"
Pin made and worn by many Microsoft employees after the company went public. It means, "F*ck You I'm Fully Vested"
This signature was created by "Code Project Quoter".
|
|
|
|
|
Here's the answer to that one... from the .NET SDK
You can make a dynamic reference to an assembly by providing the calling method with only partial information about the assembly, such as specifying only the assembly name. In this case, only the application directory is searched for the assembly, and no other checking occurs. You make a partial reference using any of the various methods for loading assemblies such as System.Reflection.Assembly.Load or AppDomain.Load. If you want the runtime to check the global assembly cache as well as the application directory for a referenced assembly, you can specify a partial reference using the System.Reflection.Assembly.LoadWithPartialName method.
So as usual, it depends!
Cheers
Shaun
|
|
|
|
|
Thx Shaun.
If I want to check for the assemblies in my code, where I have to keep the code?
If the assemblies are missing, I want the app to end gracefully instead of crash. BTW, Any code snippet for this?
I want to do like this:
Retrieve all the assemblies the EXE requires.
Find the assemblies in local directory.
If they are not there, then show a error and end the app.
Never take a problem to your boss unless you have a solution.
This signature was created by "Code Project Quoter".
|
|
|
|
|
IMHO i think a better approach would be to just handle the FileNotFoundException when you dynamically load the assemblies... but obviously you might know of a good reason to implement what you are describing!
|
|
|
|
|
IrvTheSwirv wrote:
i think a better approach would be to just handle the FileNotFoundException when you dynamically load the assemblies...
Thx Shaun.
Let me ask the question again..
I don't want to dynamically load the assemblies.
When the EXE tries to load the private assemblies (the DLL's EXE requires), if that assembly is not found it will throw the "FileNotFoundException" (Just-In-Time dialog) to the user.
Instead of that dialog, I want to catch that exception and display my version of error message and end the application gracefully.
Now where should I catch that exception?
Never take a problem to your boss unless you have a solution.
This signature was created by "Code Project Quoter".
|
|
|
|
|
Many Many Apologies Kant...
I was getting tied up with the other issues in this thread as there seems to be a double stream to it... now that I've re-read I can answer your quezzie!!
The exception will be thrown the first time the type in the DLL is requested by the EXE as the runtime will attempt to load the assembly and create the object.
What I would do is either find the point in the execution where the types are first loaded and wrap that in the old try catches
OR
do a quick instantiation of a known class, wrapping it in a try catch for each of the DLLs..
OR
create a simple class in each assembly (maybe with a simple static call) and try to call it...
OR if none of those are suitable...
You could add entries into your App.Config file which lists the dlls you require to exist in your app folder and just do a DirectorySearch...
I Dunno... it's tricky!!
Shaun
|
|
|
|
|
IrvTheSwirv wrote:
What I would do is either find the point in the execution where the types are first loaded and wrap that in the old try catches
That happens at this point.
Application.Run(new Form1()) in Main().
Thanks Shaun, those were excellent suggestions.
Never take a problem to your boss unless you have a solution.
This signature was created by "Code Project Quoter".
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
