System-wide limitation of objects, methods, etc.
I have a very theoretical question: is there a way to prevent the use of some methods, objects, etc. inside my app / project map in C #,. Net and / or Visual Studio?
To be more specific: I am developing a DMS system where it will never be possible to delete files from the archive. Archived files are just files in the Windows folder structure.
So, whenever someone tries to execute System.IO.File.Delete () it should be prohibited. Instead, I'm forced to use my own FileDelete () method, which always ensures that the file being deleted is not an archived file. (This shouldn't happen automatically. It's okay to have an error / exception that informs the developer of a forbidden method call.)
Another way to implement this could be to look at all calls to System.IO.File.Delete () at runtime, catch them, and execute my own FileDelete () method.
Of course, these are really theoretical questions, but I just know if there might be a way to implement this.
PS: I am using C # with Visual Studio 2005. So it doesn't matter if I can implement this through my programming language or Visual Studio (or in some other way I forgot).
a source to share
The closest I can come to a solution is to write my own System.IO.File class and store it in the exe project. So you will get an ambiguity compilation error which can be resolved by providing you with a custom implementation in an alias (using File = System.IO.File, Version = [version], cultuer = [correct culture], publicKey = [public key]) ... If you don't know what to write, make a breakpoint and write something like: typeof (System.IO.File) .AssemblyQualifiedName in the immediate window.
It's not bulletproof, but at least it will make the developer wake up to the decision and you could (I personally wouldn't) change the default class template to include a using directive for each class
a source to share
you can define methods and decorate them with declarative security attributes http://msdn.microsoft.com/en-us/library/dswfd229.aspx
NTN
a source to share
Not for existing library functions.
For your own code, you can apply code protection to methods, but code running as "full trust" will break through; so to test for abuse through reflection, you may have to manually test the caller ( Assembly.GetCallingAssembly
) - which is painful and still not 100% reliable ...
There are certain permissions for files / IO, but again full trust will ignore it.
I think no is the safer answer.
a source to share
One way to do this is to create a dedicated user account and grant only that account the permissions it needs to delete files. Just keep in mind that the user is in control of their computer (if they have administrative privileges;) and while you may impose some obstacles in your path, there really is nothing you can do about it (and it should be).
a source to share