This is a loaded question! How good of a programmer are you? Do you truly understand the .NET Framework or just think that C# is a special language? Do you understand the C/C++ native types very well? There are so many questions that require answering that such a question cannot be answered, at least not by anyone but yourself.
Also, the Quake2 port is not written in managed code: it was merely compiled using the MS C/C++ compiler with the /clr switch turned on. This produces a mixed-mode assembly, which most often contains more native instructions than not. Therefore, not only is this assembly not verifiable it is also not cross-platform. Managed code is used where possible but the CLR cannot manage all memory as well (if at all) in a mixed-mode assembly. The article mentions something to this effect as well.
If you want to learn more about this switch and the code that's produced, what the "Enter the Programmer" segment of MSDN TV for the episode, Managed Code[^].
I have a abstract class and several decendants. These decendants hold some functions and variables witch are used by a basic user control. The point is that I need to change between the currently used decendant at runtime (by user choice). The user control updates itself during that (using events). But when I switch to a new decendant, the old one won't get deallocated ?
Witch means the more I switch to new decendants the more I consume memory ?
It would be logical if the old decendant gets freed and then a new one is initialized, but I'm not sure if that's so ?
desmond5 wrote: But when I switch to a new decendant, the old one won't get deallocated ?
Assuming that nothing else holds a reference to the old control, it will get deallocated at some point when the GC next runs. You can try forcing it to run with System.GC.Collect(), but suggested practice is to let it do it's thing.
Another thing to keep in mind. As I understand it, when your user control gets first loaded, there is some memory used as it gets JIT'd and loaded into the application. This memory can never be deallocated until the application (actually it's appdomain) shuts down.
I don't think it is a very large overhead, though. Where I work, we load hundreds of user controls dynamically without any significant leakage.
But, if you have stored the first object away in another reference variable, collection, array, or whatever for later use then as far as the garbage collector is concerned it is still in use. In fact, there must be at least one reference to the object if you are able to reuse it at a later time. Does that make sense?
As far as I know, the function name that you use to construct the Threadstart must return void and take no parameters.
The work-around I've used (and please tell me if this is bad!!!) is to create a class, stuff the "parameters" into properties on the class and then call a method on the class to do the work...for example:
I'm sure I've made a mistake or two above...but you get the idea: stuff your parameters into properties on a class you define and then call a method on the class the conforms to that requirements of ThreadStart()
That usage is not supported. See http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconcreatingthreads.asp for an example of the suggested way to pass data to and from threads.
In addition to Bill's recommendation (a good one), you can also use a worker thread, part of a thread pool so that the threads in your application don't get wildly out of the control (a thread pool has a max number of threads that can run concurrently, along with some other advantages). For more information, see the documentation for the ThreadPool class in the .NET Framework SDK, specifically the ThreadPool.QueueUserWorkItem. You can pass an object (which can be anything, including an array of other objects) to the delegate.
The method Bill mentions gives you a little more OO control, though, since you can set up and use such an object in a separate step, although the advantages of a ThreadPool can be nice, too. Just depends on what you need.
Thanks for all the advice guys; I gave it a lot of thought I came up with a slightly different solution; since all the threads do the same task, just on different keys in the hashtable - I've set it so each thread has a number and from that number the thread figures out which keys its supposed to be handling.
When i want to reference one com object in my project i can see 3 or 4 object with the same name and version but different path, ( it 's for tlb file) is there any way i can clean my registry content up for those library, for example is there any method like this RemoveRegistry(GUID ClassGUID) then it removes all of the registry content for that library.
The reason you see multiple typelib references is because they are using different GUIDs, so even if such a function existed (which it doesn't, but it isn't hard to create) it would be effective because each typelib is registering with a different GUID (otherwise you wouldn't see multiple references).
Remove them manually by searching for your typelib using regedit.exe.
The thing to do is eliminate the problem. You MUST use hard-coded GUIDs using the GuidAttribute for all classes and interfaces that are exposed as COM objects and interfaces. The GUID on the interface should NEVER change. If you need a new interface, implement the previous version of the interface and create a new one (like IMyInterface2), giving it a new GUID. The class GUID should typically not change.
To solve your immediately problem, you should also use an assembly-level GuidAttribute for your assembly, which is used as the typelib ID when a typelib is generated:
We have a legacy java application that changes the time/date stamp on a file to let our main application know that it needs to be updated. Unfortunately, Java seems to be locking the file down because I cant get the file watcher event to fire off. Now I know the file watcher is working correctly because we also have a vb6, and a c# application that changes the time/date stamp on the same file, and for those changes the file watcher event is firing. I was wondering if anyone had any suggestions on what I could possibly do. Checking the Java code, its seems that there arent any streams that arent getting closed, its just a simple File.setLastModified() method call.
I am trying to call a web service which accepts the following paramaters (string, string, byte). The web service then connects to an MS Sql DB to store the byte along with other information, after performing some user validation using the two strings supplied.
I am not sure if this is the right place to post this...sorry in advance if it should be elsewhere:
I need a little help...here's the problem:
I am writing a windows service that runs under the localsystem account. In it's startup code it impersonates a domain user in order to gain access to files on another machine in the domain. All that works fine.
Trouble is: I try to create a set of FileSystemWatcher objects to monitor the directories on the remote machine and they fail, saying that the path is invalid. When I run the service under a domain account (not localsystem) the FileSystemWatchers work fine.
So I suspect (maybe) that the FileSystemWatchers are living in a seperate thread(s) that are running under the same login as the process started under, not the impersonated one.
Does this sound (un)reasonable to anyone? Anyone know how to get the FileSystemWatcher object to run under an impersonated identity?
Maybe a different way of asking the question is in order. If you were to successfully implement the impersonation, how would you (or your client) specify the user name and password for the user to impersonate? Likely, the answer would involve adding to or createing a configurtion UI and encrypting passwords to store in files or registry keys, etc. Since that would only get you to the same place that you already reached by specifying a proper login for the service itself -- are there any reasons you should not require that the service run under a domain account?
"You said a whole sentence with no words in it, and I understood you!" -- my wife as she cries about slowly becoming a geek.
Thanks for the advice. Actually, I have been considering that option too. As I understand it, I need to grant whatever domain user I select the "act as part of the operating system" privilege on the machine running the service, yes? I need to discuss with our network admins. if they have a domain level policy preventing this...don't know yet.
Definitely a good option...but I am not sure it's going to fly in the present setting.
Besides, at this point, I'd REALLY like to know how to make it work the way I am trying it...
The FileSystemWatcher runs in another thread, yes. How do you think you can set Enabled to true and continue your code?
Before you do set Enabled, you should get the impersonated IIdentity, wrap that in an IPrincipal implementation (such as WindowsPrincipal) and pass that to AppDomain.SetThreadPrincipal in order to set the principal for new threads created in this AppDomain.
Another idea to solve this problem is to - if possible - create an account in your domain specifically for this service, much like many database admins do for SQL Server. Then you can grant this user permission to whatever directories you need watched and exclude it from those that don't (just be sure to handle exceptions properly when access is denied).