Application-wide Restriction of objects, methods etc

Question

I have a very theoretical question: Is there a way to ban the use of some methods, objects etc. inside of my application/project map in C#, .Net and/or Visual Studio?

To be more specific: I'm developing a DMS System where it should never be possible to delete files from an archive. The archived files are just files inside a Windows folder structure.

So, whenever someone tries to perform a System.IO.File.Delete() this should be forbidden. Instead I would force to use a custom-made FileDelete()-method which always ensures that the file to delete is not a file from inside an archive. (This doesn't have to happen automatically. It's ok when there is an error/exception that informs the developer of a banned method-call.)

Another way to implement this could be to observe all calls of System.IO.File.Delete() at runtime, catch them and execute my own FileDelete()-method.

Of course these are a really theoretical questions but I would just know if there could be a way to implement this.

PS: I'm using C# with Visual Studio 2005. So it doesn't matter if I can realize this through my programming language or by Visual Studio (or by any other way I forgot).

Answer 1

控制对归档文件的删除权限不是更简单吗？

Answer 2

you can define methods and adorn them with declarative security attributes http://msdn.microsoft.com/en-us/library/dswfd229.aspx

HTH

Answer 3

Not for existing library functions.

For your own code, you could apply code-access-security on methods, but code running as "full trust" will breeze past this; so to check for abuse via reflection you would probably have to check the caller manually ( Assembly.GetCallingAssembly ) - which is painful and still not 100% robust...

There is specific file/IO permissions, but again full trust will ignore it.

I think "no" is a safer answer.

Answer 4

One way you could go about doing this is to create a special user account and only grant that account the permissions necessary to remove the files. Just keep in mind that the user is in control of his computer (if he has administrative privileges ;) and while you can put some obstacles in his way there really is nothing you can do about it (and that's the way it should be).

Answer 5

What about writing your own FxCop rule for that case?

With such a rule it will be impossible to compile if you treat warnings as errors.

Answer 6

The closest I can come to a solution is to write you own System.IO.File class and keeping that in exe project. That way you'll get a ambiguity compile error that can be resolved with giving you own implementation in an alias (using File=System.IO.File, Version=[version], cultuer=[correct culture], publicKey=[public key]). If you're unsure about what to write make a break point and write something like ?typeof(System.IO.File).AssemblyQualifiedName in the immediate window.

It's not bullet proof but at least it will enforce the developer to be concious about the decision and you could even (tho I personally wouldn't do it) change the default class template to include the using directive for every class