|
I think this post should be posted on the Lounge (there have already been some discussions about WPF/E in the lounge so nobody should complain). You are right about it being badly documented though.
the last thing I want to see is some pasty-faced geek with skin so pale that it's almost translucent trying to bump parts with a partner - John Simmons / outlaw programmer
Deja View - the feeling that you've seen this post before.
|
|
|
|
|
Hi,
I want to prevent code refactoring.
To explain, I do not want to let any one to use tools like .NET Reflector and see the code inside my .NET dll.
Is this possible ? If so , by what means we can achieve this.
Thanks,
Mani
|
|
|
|
|
The term you are looking for is not "refactoring" but "reverse engineering".
It's impossible to completely prevent reverse engineering. If the code can be run, then it can also be read, one way or the other. What you can do is to make it harder to decompile the code.
One way is to use NGen to compile the IL code into native code. It can still be decompiled, but it decompiles into assembly code, not IL code, so it's not at all as easy to reverse engineer into high level code.
---
It's amazing to see how much work some people will go through just to avoid a little bit of work.
|
|
|
|
|
but even if u did an NGen.exe , you would need the IL assembly for initial loading? dont you?
|
|
|
|
|
i think karam is right. ngen file does not possess assembly metadata which will therefore be extracted from IL.
signing an assembly does not fully protect it either. i have heared of Dotfuscator Community Edition but have never used it. it may be helpful.
|
|
|
|
|
gnadeem wrote: Dotfuscator Community Edition
it is good and worthwhile to look at 
You will see a delete button on each of your posts. Press it. - Colin Angus Mackay
|
|
|
|
|
You can use Obfuscators to accomplish this.
|
|
|
|
|
Hi, I have some problem with compiling my solution in VC++.NET 2003. I have 4 projects in my solution. When I build whole solution from the Solution Explorer using right click on solution and clicking on Rebuild option it works fine. But when I click Start button from debug menu it ask me
These projects configuration(s) are out of date:
My project name1
My project name2
My project name3
Would you like to build them?
If I click on yes it tries to build it again and it gives me lots of errors in 2 projects. Errors are like.
error LNK2005: "private: __thiscall type_info::type_info(class type_info const &)" (??0type_info@@AAE@ABV0@@Z) already defined in LIBCMTD.lib(typinfo.obj)
error LNK2005: "public: virtual __thiscall exception::~exception(void)" (??1exception@@UAE@XZ) already defined in LIBCMTD.lib(stdexcpt.obj)
fatal error LNK1169: one or more multiply defined symbols found
Can I know what is the problem with this? Thanks in advance.
Priyank
|
|
|
|
|
We have a Vb.Net 2.0 WinForms app that we force our users to log into using their network credentials (via LDAP and ADS). The app allows access to a lot of sensitive information so want to automatically log the user out after a certain time of being inactive (just like you can do on a web form) and then make them log in again to continue - so my question what is the best method in .Net 2.0 for doing this? I looked in System.Security but I can't find anything obvious there and a google didn't turn up anything useful either. I hoped I could test some sort of Form.IsAuthenticated proeprty as in a web app but this does not appear to be the case. (BTW, we don't want to quit the application when a user times out - rather, we'll just set the entire form to be disabled until they log in again.)
Currently what I've done is added a timer to the form and when the user logs in I set the timer's Interval to the number of milliseconds (from the app.config file) that they are allowed to remain logged in when inactive and then call timer.Start(). The problem with this method is reliably resetting the session (by stopping and re-starting the timer) when they do some action (such as clicking a button or entering text etc) - I tried catching Form events such as MouseDown, MouseClick and a few others but if the user clicks a control (eg: a label, textbox, button etc) and not directly on the form's surface itself these events don't get fired which can lead to users getting logged out even when they're using the app... which is clearly not the desired result!
So can anyone tell me the best way to go about doing this using .Net's security model instead of the above method?
TIA for any help/advice...
Mike
-- modified at 17:40 Tuesday 12th December, 2006
|
|
|
|
|
Use Microsoft UI Application Block which allows to maintian session state in Win Form also and same session can be used for web form.
|
|
|
|
|
Thanks - can you give a little more detail though... how do I go about actually doing this?
|
|
|
|
|
Hi,
I would like to know what does a finalize method does. I have got to know that when a finalizable object is unreachable then garbage collector removes its reference from finalizablr block and puts in freachable block and calls the finalize method and then frees the memory. So what is the essense of having the finalize method and not having it.
Thanks in Advance:
Rakesh
Rakesh
|
|
|
|
|
The finalize method is needed to free unmanaged resources that the object may own (memory,handles, etc.). If these are never feed, there would be a memory leak. Not all objects have unmanaged resources, so many do not need a finalize method.
|
|
|
|
|
Cool answer graham.I am greatful to you. It would be great if you clear me one more thing. What do you mean by unmanaged resource(memory,...)here?
Thanks:
Rakesh
|
|
|
|
|
any resource not allocated by the CLR, and hence not garbage collectible. Some .Net framework classes interface to code written in c or c++ that allocates memory (or file handles, or network connection handles, etc.) outside of that managed by the CLR. All of these implement IDisposable and have finalize methods that insure that memory is released. User written classes that interact with COM objects or system dlls can also have unmanaged memory (received from the non-.Net objects used), and therefore need finalizers and should implement IDisposable to allow early (deterministic) release of those resources. This article[^] has a more detailed explanation of CLR meory management
|
|
|
|
|
Thanks a lot Graham. Please clear me one more general question:
Lets say that I have created an object and did some thing and then the application got crashed. Now will the garbage collector will reclaim the memory of this object and the resources it is pointing to?
Rakesh
|
|
|
|
|
Rob Graham wrote: The finalize method is needed to free unmanaged resources that the object may own (memory,handles, etc.). If these are never feed, there would be a memory leak. Not all objects have unmanaged resources, so many do not need a finalize method.
I'm a bit confused by this stuff at the moment. I read this article[^] and it seemed to suggest that a finaliser is required as a back up in case the person using your class does not call Dispose() when they are finished with the object.
For example, if I have a class A that has a reference to another dot net class B and attaches to events on B in the constructor where do I unattach from the event? If I put it in a Dispose() method and the user of the class does not call Dispose() on it what happens? The article above seemed to suggest that I should implement a Finalizer to handle this case
System.IO.Path.IsPathRooted() does not behave as I would expect
|
|
|
|
|
Josh Gray wrote: I read this article[^] and it seemed to suggest that a finaliser is required as a back up in case the person using your class does not call Dispose() when they are finished with the object.
That is correct. The preferred method of handling objects that uses unmanaged resources is to call the Dispose method. That way the programmer can control when the resources are being freed.
The finalizer is called by the garbage collector when the object is collected, if the Dispose method has not been called. The problem with this is that you can not predict when this will happen, and there isn't even any guarantee that the finalizer will ever be called. If there are a lot of objects in the finalizer queue when the program ends, it's not certain that all of them will be handled before the system decides that it takes too long to finalize all the objects, and just kills off the rest.
Josh Gray wrote: For example, if I have a class A that has a reference to another dot net class B and attaches to events on B in the constructor where do I unattach from the event? If I put it in a Dispose() method and the user of the class does not call Dispose() on it what happens? The article above seemed to suggest that I should implement a Finalizer to handle this case
It's good to have a finalizer as a fallback. That way the object will be disposed eventually (at least in most cases) if the programmer fails to call Dispose properly.
---
It's amazing to see how much work some people will go through just to avoid a little bit of work.
|
|
|
|
|
You can also take a look at this article: http://www.codeproject.com/useritems/idisposable.asp[^]
The scenario you are describing is generally called "weak references" and isn't really supported in .NET. There are some blog posts about it, you can search on Google for them if you are interested.
Keep in mind that when you implement a finalizer, you are incurring extra costs to using your object so you should only implement a finalizer if you have a very good reason. Every object that has a finalizer is put on a finalization queue when it is allocated, even if the finalizer is not run. The finalizer will only be run when your object is garbage collected AND it has not already been disposed.
-----------------------------
In just two days, tomorrow will be yesterday.
|
|
|
|
|
rockyl wrote: I have got to know that when a finalizable object is unreachable then garbage collector removes its reference from finalizablr block and puts in freachable block and calls the finalize method and then frees the memory.
That will not happen. An object is not finalized when it's unreachable, it's just left untouched in memory until the next garbage collection.
If you want to free any resources, the class should implement IDisposable, so that you can call Dispose to tell the object that it won't be used any more.
At the garbage collection, if there is a finalizer in the class and GC.SuppressFinalize has not been called for the object, the object will be placed in the finalizing queue instead of being collected. A background thread is calling the finalizer for the objects in the queue, and after that the objects are up for collection.
---
It's amazing to see how much work some people will go through just to avoid a little bit of work.
|
|
|
|
|
Guffa wrote: At the garbage collection, if there is a finalizer in the class and GC.SuppressFinalize has not been called for the object, the object will be placed in the finalizing queue instead of being collected. A background thread is calling the finalizer for the objects in the queue, and after that the objects are up for collection.
The object is actually placed on the finalization queue when it is allocated. The GC.SupresFinalize call is important to tell the garbage collector that this object has been properly disposed and that it doesn't need to run the finalizer.
-----------------------------
In just two days, tomorrow will be yesterday.
|
|
|
|
|
Scott Dorman wrote: The object is actually placed on the finalization queue when it is allocated.
I checked up on this, and you are correct.
I find it a bit misleading to call the entire list of finalizable objects a queue, though, as it's not really a queue. What do we call the queue in the queue, that contains the objects that actually are going to be finalized?
---
It's amazing to see how much work some people will go through just to avoid a little bit of work.
|
|
|
|
|
|
Scott Dorman wrote: Guffa wrote:
What do we call the queue in the queue, that contains the objects that actually are going to be finalized?
Very good question. I think what you are referring to is the "freachable" queue.
That is right. That is the real finalization queue.
---
It's amazing to see how much work some people will go through just to avoid a little bit of work.
|
|
|
|
|
guys , if my understanding is right , is the following implementation correct for dispose finalise impementation?
public class MyComponent : IDisposable
{
.....
public void dispose()
{
CleanUp();
GC.SupressFinalize(this);
}
public void CleanUp
{
//clean up code here
}
~MyComponent
{
CleanUp();
}
}
Karam C Bose
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
